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: 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 <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

Thus spoke Jacques Durand (JDurand@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.
>  
> 
> Jacques


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