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



I disagree.  Reference Parameters, once turned into headers on an outgoing message,
are meant to be used by the final destination - not the sending endpoint.  As I said in a
previous note, if people want them to be read or compared or understood by the sending
endpoint then that would need to be very clearly defined in WSA, or possibly even SOAP,
'cause we have no processing model defined anywhere for how a sending endpoint is
supposed to read/interpret an outgoing message.  This is all new ground and requires
more than a little squinting.  :-)

thanks,
-Doug



Anish Karmarkar <Anish.Karmarkar@oracle.com>

10/05/2006 03:10 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
tom@coastin.com, wsrx <ws-rx@lists.oasis-open.org>
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]