- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Tue, 14 Mar 2006 14:14:31 -0500
- To: Alastair Green <alastair.green@choreology.com>
- Cc: public-ws-addressing@w3.org, ws-tx@lists.oasis-open.org
- Message-id: <CA0992B2-28CC-46F1-8C3A-A7EDA9070E7D@Sun.COM>
My 2c inline. On Mar 14, 2006, at 4:57 AM, Alastair Green wrote: > > A question (cluster of questions) has arisen in the OASIS WS-TX TC > re use of WS-Addressing. > > App A sends message "a" to app B, who may send "b" to A at a later > time, in an exchange where "a" and "b" are logically related (form > part of an exchange or conversation) at an application level. > > A possesses, a priori, an EPR for B (B.E) and likewise B possesses > an A.E, and these can be used to target the messages "a" and "b". > > Message "a" contains a non-anon, non-none value for [reply > endpoint] [address], A.E'. > > B chooses to ignore that value and sends "b", not to the new > potential target A.E' but to A.E. The A-B application-level > contract defines "b" not to be a "reply" to "a", but merely a one- > way message that is, if you like, in apposition to "a". > > B can also choose (at its whim, in any given execution of this > exchange) to send "b" to A.E', and not the old target A.E. > > Q.0. Is this a legitimate use of the [reply endpoint] of "a"? > Spiritually? Legally? > From a WS-Addr perspective it looks OK since you state that message b isn't a reply (in the MEP sense) to message a. However it seems odd for WS-TX to promote the kind of non-deterministic behaviour wrt the destination for b (A.E or A.E' at the discretion of B). One might expect WS-TX to lock things down to one or the other unless there's a good reason to leave it open ? > Related questions: > > Q.1. Must message "a", having a [reply endpoint] value, therefore > set a [message id] value, or can this latter property be omitted in > the representation? > I think it would be OK to omit a [message id] from the WS-A perspective but it seems like good practice to include one. This seems like something that WS-TX should define. > Q.2. Closely related to Q.1. Can B ignore this message id even if > it is present, and refuse to express (omit) the [relationship] of > its message "b" to the original "a" message, in the case where it > chooses to target "b" on new reply target A.E'? > Given that message b isn't a reply in the WS-A sense I think that would be OK. However, WS-TX could require that the WS-A semantics are followed and that would IMO be preferable to WS-TX inventing its own correlation mechanism. > Q.3. If message "a" desires no reply, should message A set [reply > endpoint] [address] to the "none" URI? Is the "none" value for this > property the effective definition of a "one way message" (one that > gives no indication of expected future interchanges)? Is the "none" > value the only circumstance in which the [message id] can be omitted? > The "none" addr is (IMO) equivalent to redirecting stdout to /dev/ null in Unix type OSs. > Q.4. Closely related to Q.3. If the [reply endpoint] is instead > omitted in "a" and the property is therefore inferred on receipt by > B to be anonymous, what should B send in the underlying transport > response if it wishes to send no reply at an application level? > Whatever the underlying SOAP protocol binding says to do when there's no SOAP message. In SOAP/HTTP you'd send back a 202 status code with an empty entity body. To answer these questions on a more general level I'd say its the job of WS-TX (and other protocols) to define how WS-Addr properties are used in the longer running exchanges/conversation defined by WS-TX. WS-Addr provides some useful building blocks for these kinds of exchanges but doesn't lock down their exact semantics when used this way. I'd also note that if WS-TX needs an EPR but [reply endpoint] doesn't quite fit the bill then its entirely OK to define a new EPR typed property that does. Marc. --- Marc Hadley <marc.hadley at sun.com> Business Alliances, CTO Office, Sun Microsystems.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 14 March 2006 19:14:46 UTC