RE: TAG requests help with examples of WS-Addressing

David,

 

I'll provide a more detailed reply later, when I have a bit more time.
However I do want to point out a fundamental misunderstanding.  The MEPs
in WS-AT are not "bog standard" request/reply.  They are correlated
one-ways.  The reason for this is that the transaction protocol cannot
allow messages to be lost, which can happen using the HTTP request/reply
mechanism since it does not support persistent sessions (and for good
reason since the resources consumed would negatively impact WAN
performance).  

 

A communication failure in a 2PC protocol message exchange requires a
transaction rollback - something we debated a long time in the OTS V2
committee by the way since CORBA allows transparent retries.  And
failure includes a lost message.  The transactional resource needs to
know whether or not to maintain its locks during the time the
application is communicating (i.e. while the service request is being
processed).  If the application loses its communication session the
transactional resource needs to be able to roll back as soon as possible
so that the resource can process another transaction.  

 

The underlying assumption in WS-AT (and other variations of the classic
distributed 2PC protocol) is that application level communications are
coordinated with transactional operations on data so that the operations
on data succeed if and only if the communication session succeeds.
Therefore it isn't possible to have ambiguity in the results of MEPs.
If there's any communication failure between parties in a distributed
transaction the transaction must roll back in order to preserve data
integrity.  The coordinator is acting on behalf of the application level
request to ensure the ACID guarantees are preserved in the distributed
case, and (as Don Box and I discovered back in early 2000 when we tried
to map SOAP to TIP) you can't do this with plain HTTP requests since
there's no mechanism for persistent state management (see also
WS-Context).  The correlated one-ways in the transaction protocol MEP is
necessary because of this, as is the use of WSA.  

 

CORBA, J2EE, and proprietary distributed transaction processing
mechanisms don't have this problem since they use session-oriented
protocols and associate transaction context with the session. If the
communication session fails the application level error is therefore
clear with respect to what happens to the related operations on data.
Another thing important to always keep in mind about transactions is
that they are essentially meaningless without operations on data.  The
protocols can't be understood in the abstract, they have to be
understood in relationship to the transactional resources performing the
operations on data, which is what is being coordinated here, and why we
can't depend on plain HTTP. 

 

Eric

 

+1 781 902 8366

fax: +1 781 902 8009

blog: www.iona.com/blogs/newcomer 

Making Software Work Together (TM)

  _____  

From: David Hull [mailto:dmh@tibco.com] 
Sent: Friday, December 02, 2005 6:08 PM
To: Newcomer, Eric
Cc: Cahill, Conor P; noah_mendelsohn@us.ibm.com;
public-ws-addressing@w3.org; www-tag@w3.org
Subject: 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