Re: TAG requests help with examples of WS-Addressing

I've had a look at WS-AtomicTransaction, and frankly, I find Section 9
("Use of WS-Addressing Headers") fairly puzzling.

As far as I can make out, the main dependency on WSA here is that the
coordinator and participants need to communicate asynchronously.  In
particular, the coordinator will inform the participants of key
transitions (perhaps through a broadcast mechanism, though I don't see
this mentioned), and the participants inform the coordinator of their
progress as it happens.  Both of these involve one-way messages which
don't fit neatly into the request-response paradigm.

In short, a nice use case for asynchronous messaging, and EPRs in
particular.

If I may paraphrase, section 9 basically says

   1. CreateCoordinationContext and Register are bog-standard
      request-response operations.
   2. Commit, Rollback etc. are one-way operations.  (In the text they
      "follow the standard 'one way' pattern as defined in
      WS-Addressing."  But WSA doesn't define any such operation beyond
      saying, non-normatively, that in it "a source sends a message to a
      destination without any further definition of the interaction" and
      asserting, that it is the basic interaction pattern from which all
      others are composed.)
   3. Request-response operations MUST use wsa: headers.
   4. Request-response acts like the WSA core says it does, except that
      the rule for a missing [fault endpoint] is not observed (and
      possibly with other exceptions I missed).
   5. Non-terminal notification messages MUST include a wsa:ReplyTo header.
   6. Endpoint references must not contain the anonymous address.

This is all stated in terms of message headers, and not abstract
properties.  (e.g. wsa:ReplyTo and not [reply endpoint]).

As far as I can tell, items 1 and 2 are unremarkable, the sort of thing
WSDL was meant for.

Item 3 seems mostly harmless, though needlessly restrictive.  Is there
any compelling reason why CreateCoordinationContext should have to
adhere to WSA rules?  As far as I can tell, it's just a
request-response, of the sort which has been working just fine for years
without WSA.  Naturally, if the client wants to do the operation
asynchronously (i.e., direct the [reply endpoint] to a callback
address), it would be well-served to use WSA, and this is a case where
EPRs are getting thrown around anyway.  My point, though, is that there
is no inherent need to refer to WSA in discussing these operations. 
They're request-response and that's all that needs to be said.

Item 4 is a bit unsettling.  Restating the core WSA rules here makes it
unclear whether the WS-AT intends to adhere to WSA or deviate from it. 
As it happens, WS-AT deviates, at least in that it does not follow the
rule that a missing [fault endpoint] defaults to the [reply endpoint]. 
It also seems a bit vague as to /which/ endpoints faulting defaults to
instead.  One subtle point which may or may not actually matter:  in the
WS-AT description, [reply endpoint] MUST be present in requests (but
there's no mention of what happens if it's missing).  In WSA proper, the
server is explicitly unconstrained in such a case.

Item 5 is interesting.  The REQUIRED [reply endpoint] is not to be used
for replies, but to identify the sender in case something goes wrong and
the coordinator wants to get back in touch.  This might be a use case
for the (at risk) [source endpoint] addressing property.  Another
approach would be to define a "retry endpoint" or such.  This would
emphasize that the purpose of the endpoint is peculiar to WS-AT.  The
present treatment feels like overloading to me, though I'm not violently
against it.

Item 6 seems just plain odd.  Read literally, it means that you can't
use anonymous anywhere, not even in a [reply endpoint].  In other words,
you can't do either of the request-response operations synchronously.  I
doubt this is the intent.  The text also uses the term "physical
address", which the WSA group has opted specifically /not/ to define.  I
/think/ what this is really trying to say is that the coordinator's
address and the [reply endpoint] included under item 5 should not be
anonymous.  This seems fine, but it strikes me as a "don't run with
scissors" sort of rule.

WSA now leaves the meaning of anonymous addresses up to the protocol
binding, and the SOAP binding in turn defines anonymous as the response
channel in a request-response MEP, and unconstrained otherwise.  It's
conceivable that, in some particular profile, it would make perfect
sense for a participant to include an anonymous [reply endpoint], and
the coordinator would know what to do with that.

I also note that there is no mention of the "none" address, which
presumably would also be considered a sharp object.

In short, it seems to me that explicitly mentioning WSA MAPs in a
context like this sucks one into consideration of the finer theological
points of WSA, and should only be done with caution and given a clear
need.  I'm not convinced there is very much clear need for the material
in this section (or others like it in other specs).

By contrast, mention of EPRs outside WSA proper is generally normal,
healthy and to be encouraged.


Newcomer, Eric wrote:

>EPRs are also used in the WS-Transactions specifications (under
>standardization at the WS-TX TC in Oasis).   
>
>See: http://www.oasis-open.org/committees/documents.php?wg_abbrev=ws-tx
>
>Several other proposed WS-* specifications depend upon WSA constructs,
>including the EPR.  The point is that even if end users don't see them,
>they are important for use in SOAP headers for various features.
>
>Eric, WS-TX TC co-chair
> 
>+1 781 902 8366
>fax: +1 781 902 8009
>blog: www.iona.com/blogs/newcomer 
>Making Software Work Together (TM)
>
>-----Original Message-----
>From: Cahill, Conor P [mailto:conor.p.cahill@intel.com] 
>Sent: Wednesday, November 30, 2005 8:30 AM
>To: noah_mendelsohn@us.ibm.com; public-ws-addressing@w3.org
>Cc: www-tag@w3.org
>Subject: RE: TAG requests help with examples of WS-Addressing
>
>
> 
>
>The Liberty Alliance is making heavy use of EPRs both in 
>message headers as well as in our Discovery Service 
>responses (used to describe how to invoke web services).
>
>The current draft specifications are available at:
>
>https://www.projectliberty.org/resources/specifications.php#box2
>
>An interesting extension that we have done as well is defined
>a new header for responses (EPRUpdate) to update the EPR that
>was used to invoke the service (such as redirecting the request
>to a different endpoint, adding additional reference parameters,
>etc.)  Details on that usage is within the SOAP Bindings 
>specification.
>
>I believe this is a good example of a complete system 
>making concrete use of the WS-Addressing specifications.
>
>Conor
>
>
>
>
>
>  
>