OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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.








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]