W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

What to do about MAP extensibility, if we need to

From: David Hull <dmh@tibco.com>
Date: Tue, 08 Mar 2005 14:40:40 -0500
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-id: <422DFFB8.7010108@tibco.com>
I'm happy with leaving [action] as mandatory.  It's basically saying 
"every message has a purpose", which is probably OK.

As for endpoints, replace [reply endpoint] and [fault endpoint] with 
[associated endpoints] (0 .. *) as a  set of 0 or more (IRI, EPR) pairs, 
and pre-define IRIs for "reply" and "fault".  Note that the SOAP binding 
can still special-case this, mapping (replyIRI, ...) as it currently 
maps [reply endpoint] and so forth.

This suggests an interesting refinement: Share the IRI for "reply" 
between [associated endpoints] and [relationship].  That is, define a 
single "reply" IRI, denote the reply endpoint by (replyIRI, /reply EPR/) 
and the reply-to relationship by (replyIRI, /requestMID)/.  A fault, 
similarly, would have the relationship (faultIRI, /requestMID)/, and the 
hypothetical "special handling" message would have the relationship 
(specialHandlingIRI, /initiatingMID/), the only difference being that 
specialHandlingIRI is defined ad-hoc while replyIRI and faultIRI are 
defined by us.

I'm not passionate about this or any other particular approach (though I 
do like this one at the moment), but as I read the charter, we /do/ have 
to make sure that we can directly cover cases outside the well-known 
MEPs: "The components must be extensible to enable other mechanisms such 
as new kinds of relationships between correlated 
<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#correlation> messages, 
policies <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#policy>, or 
service semantics 
<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#service_semantics> to 
be built upon Web Services Addressing."
Received on Tuesday, 8 March 2005 19:41:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:24 UTC