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

Re: NEW ISSUE: Handling arbitrary sets of associated endpoints [i054]

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Sat, 19 Mar 2005 17:37:53 -0800
Message-Id: <753fc82d32a5024ee9d7707a55295e77@bea.com>
Cc: public-ws-addressing@w3.org
To: David Hull <dmh@tibco.com>

This is now issue 054;

On Mar 10, 2005, at 2:44 PM, David Hull wrote:

>  Title: Handling arbitrary sets of associated endpoints.
>  Description: Asynchronous applications may define interactions in  
> which an incoming message may produce outgoing messages to any number  
> of different endpoints.  To take a concrete example, a service may be  
> required to receive a message and do one of
> 	1.  	Send a fault to a fault destination.
> 	2.  	Send application data to a "normal processing" destination.
> 	3.  	Send (possibly different) application data to a "special  
> processing" destination.
>  Obviously arbitrarily many variations are possible.
>  It is not clear from section 3 of the core spec exactly how to handle  
> this in terms of Message Addressing Properties.  If it is possible,  
> the text should make clear how interactions beyond the well-known  
> cases of one-way and request/reply may be realized.  If, as it  
> appears, the Message Addressing Properties cannot cover such cases,  
> they should be amended to do so.  If such interactions are out of  
> scope, which appears doubtful, this should be clarified.
>  Justification: The WSA charter dictates that "The components must be  
> extensible to enable other mechanisms such as new kinds of  
> relationships between correlated messages, policies, or service  
> semantics to be built upon Web Services Addressing." and section 3  
> amplifies this, saying that "Message addressing properties  
> collectively augment a message with the following abstract properties  
> to support one way, request reply, and any other interaction pattern:"
>  Target: core, with some impact on bindings
>  Proposal:
>  Review section 3 and either demonstrate a direct means of handling  
> use cases such as the above, or determine that they cannot be  
> handled.  In the event that the current MAPs cannot cover cases such  
> as the one above, I have proposed a modification [1] to MAPs to  
> replace the ad-hoc [reply endpoint] and [fault endpoint] properties  
> with a more general [associated endpoints] property (suggestions for a  
> better name are always welcome), similar in structure to the existing  
> [relationship] property.  We would pre-define IRIs designating "reply"  
> and "fault" endpoints, just as we pre-define an IRI for the "reply"  
> relationship.
>  I do not detail in that proposal how to bind this to SOAP, but the  
> resulting headers should be of the form
>  <wsa:associatedEndpoint type="anyUri">EPR</wsa:associatedEndpoint>
>  where the @type attribute is the IRI component from the  
> associatedEndpoint and the EPR child is the EPR component.  It would  
> also be possible to special-case the SOAP binding of fault and reply  
> endpoints to appear in SOAP as wsa:FaultTo and wsa:ReplyTo elements,  
> if this is deemed necessary or desirable.
>  While it would be possible to implement this proposal without  
> changing the existing descriptions of reply and fault endpoint  
> semantics (e.g., default and anonymous destinations), it would be  
> desirable to migrate these descriptions to the binding documents,  
> which already cover much of the mechanics of request/reply.  I have  
> proposed this, from the point of view of the core spec, in [2].  I  
> would regard this as a sub-issue of the main issue, and again, the  
> main issue can be resolved without implementing it.
>  References:
>  [1]  
> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/ 
> 0078.html
>  [2]  
> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/ 
> 0074.html

Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems
Received on Sunday, 20 March 2005 01:38:13 UTC

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