OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Initially, I thought that it would violate the opacity principle as 
well. But squinting at it a little:

The server has the client's EPR (either through ReplyTo, AcksTo 
whatever) and wants to send a message to it. The client EPR contains ref 
params (say <wsrm:ReceiverId>). When the server sends a message to the 
client EPR, it includes the ref params <wsrm:ReceiverId> as a SOAP 
header block in the message, per WS-Addr spec. This does not require the 
server to know what the ref param <wsrm:ReceiverId> means. Now let us 
say that the sending of that message failed. The server being a sensible 
implementation of the WSRM spec will have stored this message in a 
stable storage. At some point in time, the client sends a MakeConnection 
message to the server. The make connection message contains an element 
<wsrm:ReceiverId> that has the same value as the ref param in the EPR. 
The server now has to look in its stable storage to look for messages 
that have a matching SOAP header: opacity violation.

But what if the wsrm spec defined a SOAP header block called 
wsrm:ReceiverId and said that it's semantics were associated with 
MakeConnection to figure out which message to send. In that case, the 
wsrm:ReceiverId is a SOAP header that is present on messages in the 
server's stable storage with well-defined semantics that are understood 
by the server (since it is a sensible implementation of WSRM).
In that case, we don't have a violation of the opacity rule because, at 
that point it is a well-understood SOAP header that happens to be a ref 
param.

I personally like what we have now. See [1]. But given that the WS-A WG 
has not resolved issue 33Rec, this is worthwhile solution to consider.

-Anish
--

[1] http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0047


Christopher B Ferris wrote:
> 
> Tom,
> 
> This would violate the inherent opacity principle upon which refParams 
> are based because the
> server would have to "understand" that refParam and act accordingly. I 
> would not like to have
> RM set a bad precedent.
> 
> Cheers,
> 
> 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
> 
> Tom Rutt <tom@coastin.com> wrote on 09/29/2006 02:32:55 AM:
> 
>  >
>  > 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
>  >
>  > --
>  > ----------------------------------------------------
>  > Tom Rutt   email: tom@coastin.com; trutt@us.fujitsu.com
>  > Tel: +1 732 801 5744          Fax: +1 732 774 5133
>  >
>  >


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]