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