|Jacques Durand||May 3, 2005 3:57 pm|
|Subject:||RE: [ebxml-msg] leveraging ws-addressing|
|From:||Jacques Durand (JDur...@us.fujitsu.com)|
|Date:||May 3, 2005 3:57:25 pm|
Title: RE: [ebxml-msg] leveraging ws-addressing
Have not followed-up on this, and just realized that indeed wsa:To and wsa:From are not of same type in the March version. Seems hard to justify to me.
Now, I am not sure what use we can make of wsa:From. We may not want to touch it: in a SOAP intermediary mode, a sending MSH may not have the leisure to set this value.
-----Original Message----- From: Pete Wenzel [mailto:pe...@seebeyond.com] Sent: Wednesday, April 20, 2005 10:15 AM To: Jacques Durand Cc: ebxm...@lists.oasis-open.org Subject: Re: [ebxml-msg] leveraging ws-addressing
The WS-A WG is considering placing the "source endpoint" property (embodied by the "From" header) "at risk", meaning that they are uncertain that there exist any valid use cases for it, and that they seek same.
If we want them to keep it, it would be helpful to articulate our use case, perhaps also justifying why it deserves to be an envelope- level, rather than payload-level, construct.
Jacques, you only mentioned it in the context of "ReplyTo", which may or may not be related. "ReplyTo" could certainly be used in request- response pattern addressing, whereas uses of "From" may be more administrative in nature. If this is true, we might then recommend that "From" be changed to an URI (IRI?), rather than an EndpointReference, assuming that we intend it to be used only as a simple party identifier, rather than a fully specified message destination.
--Pete Pete Wenzel <pe...@seebeyond.com> Senior Architect, SeeBeyond Standards & Product Strategy +1-626-471-6311 (US-Pacific)
Thus spoke Jacques Durand (JDur...@us.fujitsu.com) on Tue, Apr 12, 2005 at 06:42:30PM -0700:
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.
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php