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
- From: Doug Davis <dug@us.ibm.com>
- To: Alastair Green <alastair.green@choreology.com>
- Date: Wed, 4 Oct 2006 02:17:37 -0400
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]