Re: [ws-rx] Usage of Ref parms for WS-Reliable Messaging

[Doug Davis <dug@us.ibm.com>]

I believe the use-cases the "RManon"
concept solves, like CS flowing, are in scope.
We've been here already and voted -
let's focus on the PR issues at hand.
thanks,
-Doug

Paul Fremantle <paul@wso2.com>

10/06/2006 04:07 AM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	Anish Karmarkar <Anish.Karmarkar@oracle.com>, Marc Goodner <mgoodner@microsoft.com>, "tom@coastin.com" <tom@coastin.com>, wsrx <ws-rx@lists.oasis-open.org>
Subject	Re: [ws-rx] Usage of Ref parms for WS-Reliable Messaging

Doug

So does the addressing concept "RMAnon" have wider applicability?

"The TC will not attempt to define concepts or renderings for functions
that are of wider applicability including but not limited to:
    ...
  * Addressing
    ...

Paul


Doug Davis wrote:
>
> Not trying to speak for Anish, but from my point of view, the URI
> version was designed to
> solve very specific RM use-cases - like the sending of a 
> CreateSequence.  Any other
> solution that was proposed was a hack and, IMO, bastardized the 
> protocol.  That fact that
> the solution we developed for scenarios like CS, /without /any change,
> also works for other
> scenarios is good, not bad.  If we had added a ton of crap to
> MakeConnection for the sole
> purpose of solving those other use-cases then you may have a point,
> but that was just not
> the case.
>
> thanks,
> -Doug
>
>
>
> *Paul Fremantle <paul@wso2.com>*
>
> 10/05/2006 05:55 PM
>
>                  
> To
>                  Anish
Karmarkar <Anish.Karmarkar@oracle.com>
> cc
>                  Marc
Goodner <mgoodner@microsoft.com>, "tom@coastin.com" 
> <tom@coastin.com>, wsrx <ws-rx@lists.oasis-open.org>
> Subject
>                  Re:
[ws-rx] Usage of Ref parms for WS-Reliable Messaging
>
>
>
>                  
>
>
>
>
>
> Anish
>
> Firstly there is a general point, which is that good design is design
> that meets the design brief and no more. We all know that solutions
that
> go well beyond the design brief tend to have problems. I would hazard
a
> guess that at least 50% of security problems come from building in
too
> much richness. Interoperability is another key issue. If you look
at
> what WS-I did with WSDL it was specifically addressing the fact that
> there was too much richness in the original WSDL specification which
led
> to massive non-interop.
>
> When we came up with the "compromise" proposal I was of
your opinion. I
> felt that the composability requirement I was pushing was met by the
> SeqID model (that we could add reliability to an existing two-way
> message exchange without interposing at the WSA level and modifying
WSA
> headers), and that the wider requirements for using anonymous
> backchannels were met by the URI model.
>
> However, with some further time and of course the discussions from
the
> WSA group, I'm beginning to wonder if I was wrong.
>
> I was going to write a note to the TC proposing we redo the URI model
> using reference parameters, but I realize my heart is not in it. I
do
> not believe that option is composable with existing interactions,
and I
> do not believe it is in the remit of this TC to create new mechanisms
> that go beyond *adding* reliability to existing SOAP message flows.
>
> Then I re-read the charter.
>
> In particular this aspect:
>
> "The TC will not attempt to define concepts or renderings for
functions
> that are of wider applicability including but not limited to:
>
>    * Security (Encryption, Integrity and Authentication)
>    * Addressing
>    * Policy languages and frameworks"
>
> I think that *clearly* rules out what you are saying.
>
> Paul
>
>
> Anish Karmarkar wrote:
> > Marc Goodner wrote:
> >> This seems to be a discussion of a generic polling model
with no
> >> connection to RM.
> >
> > What is that a bad thing?
> > Just because RM has this urgent need, does not mean that the
solution
> > *has* to be RM-specific. It can be, but doesn't have to.
> >
> > -Anish
> > --
> >
> >> I think the point on MakeConnection Queue below is important
though.
> >> The RM anon URI absolutely requires establishing a queue
independent
> >> of an RM sequence. I'm increasingly troubled by that. The
two
> >> mechanisms we have for MakeConnection do not seem to be able
to share
> >> the same queue. At least the SeqID form uses an existing
RM sequence
> >> and is clearly about solving RM scenarios.
> >>
> >> -----Original Message-----
> >> From: Paul Fremantle [mailto:paul@wso2.com]
> >> Sent: Friday, September 29, 2006 1:10 AM
> >> To: tom@coastin.com
> >> Cc: wsrx
> >> Subject: Re: [ws-rx] Usage of Ref parms for WS-Reliable Messaging
> >>
> >> Tom
> >>
> >> I agree completely.
> >>
> >> As an aside, the problem with the concept of a resource is
that it is
> >> very wide. Looked at with the right mindset, I believe that
any 
> usage of
> >> reference parameters could be challenged as referring to
a resource. I
> >> personally don't have such a wide "resource view",
with the result that
> >> passing a uuid seems a very reasonable usage of a reference
parameter.
> >> In fact I think that it makes the whole EPR-based polling
model much
> >> better. It seemed to me that we decided against this model
because we
> >> anticipated issues from the WSA WG, and we got that wrong.
> >>
> >> Paul
> >>
> >> Tom Rutt wrote:
> >>> quoted from 9/28 minutes:
> >>>
> >>> "
> >>> Chris: We are not in agreement. I don't want to use reference
params
> >>> because they violate the Web Architecture. WSA WG ignored
TAGs issues.
> >>> Paul: I'm not at all in agreement. The reference parameters
are not
> >>> used to identify a resource, they are used to identify
a particular
> >>> RMD.
> >>> "
> >>>
> >>> I think that using a ref parm to identify a MakeConnection
Queue could
> >>> be considered application level information associated
with a
> >>> particular endpoint address.
> >>>
> >>> I really think, if we wanted to, we could work out a
specification of
> >>> a use of a ref parm, which when added to the generic
wsa:anonymous URI
> >>> in the address
> >>> field of an EPR, identifies the "make connection"
queue which will
> >>> utiize the back channel only when it is appropriate (i.e,
when a make
> >>> connection is received with that queue ID).
> >>>
> >>> What I am trying to say is that only the address is needed
for
> >>> dispatching the message to the appropriate location,
and that the a
> >>> queueID ref parm could indicate when that anonymous back
channel is
> >>> appropriate for use.
> >>>
> >>> Tom Rutt
> >>>
> >>
> >
>