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
>
>
>
>
>
>  
>