RE: TAG requests help with examples of WS-Addressing

HI David,

 

I agree we need to be careful, and I apologize in advance since I have
not actively been following the discussions in this WG and am not
familiar in detail with recent spec changes and therefore unaware of the
distinction between MAPs and Actions.  

 

In the case of WS-Transactions, the MEPs are correlated one-ways.  They
are not request-response, and therefore the service provider (i.e.
transaction participant) will have no way of contacting the coordinator
without a valid EPR in the SOAP header.

 

Even in the case of request-response, however, when the HTTP is lost, so
is the equivalent of the "reply to" address (which is actually why the
transaction specs use correlated one-ways), meaning that its presence in
the SOAP header is helpful when retries or reliability acknowledgements
are required. 

 

I was not trying to suggest that EPRs are required in all cases, simply
making the point that some of the specs dependent upon WSA define a
system level usage that also validates the need for them. 

 

How

 

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: Thursday, December 01, 2005 12:17 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

 

We need to be a bit careful here.

In general, a spec that uses EPRs to represent endpoints in messages has
a direct dependency on WSA.

On the other hand, very few specs have any legitimate reason to talk
about MAPs.  For example, if a spec defines a request-reply operation,
it should not say things like "the response to this operation MUST be
sent to the endpoint designated by the wsa:ReplyTo header."  WSA already
says that.  Repeating it adds nothing except the potential for confusion
if the redundant material is in any way out of sync with WSA itself.

Further, mentioning MAPs in such a way effectively requires use of WSA
when it's not actually needed.  I see no reason why a useful
request-response operation should not be implemented by endpoints that
don't support WSA, or support WSA but without making it wsdl:required.
It can be perfectly useful to support a request-response operation
without sending the response asynchronously to a third party.  This is
particularly relevant if the operation itself doesn't involve EPRs.

I would particularly discourage statements about wsa:* SOAP headers (or
"Message Information Headers" as they were previously called).  At the
very least, such statements should be changed to mention WSA MAPs (the
abstract counterpart to the SOAP headers).  That such a change would
need to happen when the basic semantics have not changed is a red flag
in itself.

The one sticky area I've seen is in assigning a standard [action] to an
operation.  WS-BaseNotification (full disclosure: I co-edit it) and
related specs say, essentially "The [action] MAP must be ..."  I believe
this is following the lead of WSRF. Personally, I'm not entirely
comfortable with this, but in this particular case EPRs are an integral
part of Notification, so there is no great loss from essentially
requiring WSA.

Personally, I would prefer giving the [action] value normatively in a
WSDL.  If WSA is engaged, this becomes the [action] MAP.  If not, it
might become the SOAPAction HTTP header, or might become something else,
or might not matter, all depending on the binding.  Failing that, it
would be nice to have a standard incantation to the effect of "The
action for this operation is http://foo." with the understanding that
this could be the WSA [action], the SOAPAction HTTP header, or whatever
else. 

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