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

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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
>>>