Re: NEW ISSUE: Handling arbitrary sets of associated endpoints

Jonathan Marsh wrote:

> What do you propose should happen if a client received a 
> <wsa:associatedEndpoint type="anyUri">EPR</wsa:associatedEndpoint> 
> header with a URI it didn't understand?
>
>  
>
What do we currently do if a receiver gets an IRI it doesn't understand 
for relationship?

> ------------------------------------------------------------------------
>
> *From:* public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *David Hull
> *Sent:* Thursday, March 10, 2005 2:44 PM
> *To:* public-ws-addressing@w3.org
> *Subject:* NEW ISSUE: Handling arbitrary sets of associated endpoints
>
>  
>
> 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
>