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

[Christopher B Ferris <chrisfer@us.ibm.com>]

+1

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

Anish Karmarkar <Anish.Karmarkar@oracle.com>
wrote on 10/05/2006 03:13:53 PM:

> It is a polling mechanism defined by WSRM and we say how it is used
in 
> the context of RM.
> If someone else find it useful then they can use it and answer those
> questions in their context, WSRM doesn't not have to do that.
> 
> I'm pushing back on the notion that any polling mechanism that is
in 
> WSRM *has* to be so tightly coupled to RM that no one can possibly
use it.
> 
> -Anish
> --
> 
> 
> Marc Goodner wrote:
> > It is a bad thing because there is no description of this "generic
> polling" in the specification at all. How is this intended to
be 
> used, much less implemented, independently of RM? How is it to be
> secured? These are not idle questions. If this is indeed intended
to
> be a generic polling specification there is an awful lot left to the
> imagination.
> > 
> > -----Original Message-----
> > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> > Sent: Thursday, October 05, 2006 11:53 AM
> > To: Marc Goodner
> > Cc: Paul Fremantle; tom@coastin.com; wsrx
> > Subject: Re: [ws-rx] Usage of Ref parms for WS-Reliable Messaging
> > 
> > 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
> >>>