[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: leveraging ws-addressing
Given that several wsa features are nearly stable today
(have been for a long time at least), here is my perspective on how this can
interfere with V3. (just some thoughts to start a thread on this, not even a
proposal...) There are two aspects in wsa: -
message addressing properties (directly
affecting the message as wsa headers) -
endpoint reference (EPR) that is
a standalone construct describing a WS endpoint (minimal content is just an Address
URI) I am focusing on message addressing properties, because that
is where we see a direct interference with ebMS headers, and see the possible leverage
or processing conflicts . From the start, a position among these could be taken
: -
(a) remain orthogonal and
independent from wsa headers (compose with them, but no ebMS semantics). Issue:
there might be conflicting semantics with ebMS headers (e.g. replyTo, FaultTo...) -
(b) make use of them - require
them - for ebMS semantics. Issue: it would not be possible anymore to
allow usage of these headers - in general - for a non-ebMS
semantics, when that does not conflict with ebMS (this raises again
questions like what places can an MSH take in a SOAP processing chain ). See
the 2 use cases at the end of that mail: how much do we want to allow here?. -
( c) use ebMS specific headers like
(a) but in an optional way, and when not present default on equivalent wsa
headers. This would allow for reuse of wsa processing components in an
MSH. Headers we need to consider are: -wsa:MessageID: Seems semantically well aligned with ebMS
ID. Required in several cases where other headers below are used. -wsa:RelatesTo: analogous to RefToMessageID. The @relationshiptype
would be ebMS namespace. -wsa:ReplyTo: "mandatory if a response is expected"
. Probably useless in case of a simple request-response MEP (must align with "From")
, would be useful in case of aggregate MEP. Would be remembered by a receiving
MSH as long as needed to send back related responses. Needs an EPR infoset as
value. -wsa:FaultTo: used for SOAP fault addressing, could also apply
to ebMS Errors (both can be combined). Needs an EPR infoset as value. So far giving an ebMS semantics to the above seems to be
aligned with their general intent even in case these have already been set for
reasons other than ebMS (e.g. MessageID). So option (b) above seems OK here. The
following two are more questionable: -wsa:To: destination URI. Could be an MSH URL, or beyond if
the MSH can act as a SOAP intermediary. In the latter case, we can't rely
on wsa:To for representing the destination MSH. Then it would not have ebMS
semantics. -wsa:Action: Mandatory for wsa compliance. Could be a
substitute to eb:Action only if we disregard the following 2 use cases, where
both elements seem needed in same message. Composition Use Cases where both
eb:Action and wsa:Action seem to be needed: 2 SOAP nodes are cooperating at a same
(receiver) location on message processing: (C1) wsa:Action is consumed
by an intermediary on receiver side, with a proper semantics e.g. dispatching message to
next node which is the MSH (ultimate node). The MSH will still need an eb:Action
header element (normally independent from wsa:Action) to process the ebMS
message. (C2) the MSH is not the ultimate
recipient, and acts as a SOAP intermediary. wsa:Action is to be consumed by a
node beyond the receiving MSH, that implements its semantics. At that point the
message is no longer an ebMS message (ebMS headers have been consumed before,
and eb:Action with them). In both cases above, we have
a composition semantics, where wsa:Action is not a substitute for eb:Action.
In other cases, clearly wsa:Action can be a substitute for eb:Action. Some defaulting
could then apply. Jacques |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]