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?
>
To amplify the answer I gave earlier:

I don't think the core spec needs to define this behavior.  The MEP 
descriptions in the WSDL binding leaves open the possibility of values 
for anything it doesn't care about, and this would be just another 
case.  I can include whatever associated endpoints I like in a request, 
but only reply and fault endpoints are significant.  I'll note that 
there appear to be a couple of bolts to tighten in this spec in any 
case, there will most likely have to be a bit more discussion of the 
exact details.

For the type of fully asynchronous system like the one I described, it 
is up to the designers of such a system to say what an unknown 
associated endpoint might mean, or whether it is allowed at all.

My guiding principle in all this is that the core should speak of 
addressing a one-way message and /allowing/ further properties to be 
attached to it in order for it to fit naturally into larger patterns 
including, but not limited to, request/reply over a 
request/reply-oriented transport.  Beyond not getting in the way of such 
applications, and possibly pre-defining a few values that are already 
known to be useful, the core spec should be silent on anything larger 
than one-way.

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