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] Reference parameters and properties



However, the ref-p's are used on incoming messages and that is a critical difference. Once they appear on incoming messages then they 'virtually' are as if they appeared in the destination's EPR - which means it owned them and its the only one that needs to know about them.  The entire ref-p issue that WSA is discussing is talking about looking at ref-p's on outgoing messages and that's something totally different.
-Doug



Alastair Green <alastair.green@choreology.com>

10/03/2006 07:26 PM

To
Marc Goodner <mgoodner@microsoft.com>
cc
"ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
Subject
Re: [ws-rx] Reference parameters and properties





Clearly, but it does illustrate the natural impulse to use ref-params in a contractually-agreed manner which (above the WS-A layer) is not opaque. I don't object to this "hack". I think it shows what you can do with ref-params between consenting adults.

Alastair

Marc Goodner wrote:

This was a hack added to the RM interop scenarios to trigger specific behavior we were trying to test.
 
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent:
Tuesday, October 03, 2006 3:59 PM
To:
ws-rx@lists.oasis-open.org
Subject:
[ws-rx] Reference parameters and properties

 
The RM interop document referred to by Marc in his "Short History" contains the following paragraph:

Some of the scenarios described in this document require that the service change its behavior depending on the scenario being executed. In order for the service to know the behavior that is expected this document defines a set of WS-Addressing reference properties [my emphasis] that should be included at part of the wsa:To EPR for all client to service messages associated with the scenario:

<rmi:acceptOffer> (true | false) </rmi:acceptoffer>
<rmi:useOffer> (true | false) </rmi:useOffer>
<rmi:useHTTPResponse> (true | false) </rmi:useHTTPResponse>


Isn't this an example of non-opaque, transparent reference parameters?  I presume that in the modern world contractually-agreed ref params are used to effect the communication of these semantics, but otherwise no change?

Alastair



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