RE: NEW ISSUE: Handling arbitrary sets of associated endpoints

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?

 

________________________________

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.ht
ml
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0074.ht
ml