MHonArc v2.5.0b2 -->
















ebxml-msg message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Another header v 3.0 option (ws-addressing) with discussion and a question.




From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: <ebxml-msg@lists.oasis-open.org>
Date: Thu, 23 Oct 2003 12:50:10 -0700






Hi,

We already have identified two new WS- style headers that could take
over some functionality of ebXML Messaging v 2.0 header, wss security
header and wsrm reliability header. I mentioned that we could let the v
3.0 ebXML header remain in a reduced form that did all existing 2.0
functionality that is not taken over by some agreed upon WS- style
header. [We could also maybe use the original v 2.0 functionality if
some WS- functionality was not implemented or was less preferred by some
community. I am not certain if that makes things too complicated or
provides us with a simple 2.0 backwards compatibility mode, which could
be an advantage in v 3.0...]

Anyhow, I mentioned that PartyId information in the To and From elements
of the current header seemed likely to be residual elements that were
not captured elsewhere. I forgot about ws-addressing when I said that,
which I don't think is a WS- spec that is submitted anywhere, but is one
that contains a bunch of "message information header blocks" such as,

<wsa:MessageID> xs:anyURI </wsa:MessageID>
<wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
<wsa:To>xs:anyURI</wsa:To>
<wsa:Action>xs:anyURI</wsa:Action>

<wsa:From>endpoint-reference</wsa:From>
<wsa:ReplyTo>endpoint-reference</wsa:ReplyTo>
<wsa:FaultTo>endpoint-reference</wsa:FaultTo>
<wsa:Recipient>endpoint-reference</wsa:Recipient>

where endpoint-reference is a chunk like

<wsa:EndpointReference>
<wsa:Address>xs:anyURI</wsa:Address>
<wsa:ReferenceProperties> ... </wsa:ReferenceProperties> ?
<wsa:PortType>xs:QName</wsa:PortType> ?
<wsa:ServiceName PortName="xs:NCName"?>xs:QName</wsa:ServiceName> ?
<wsp:Policy/> *
</wsa:EndpointReference>


Clearly a lot of the endpoint-reference apparatus is WS specific, and
the semantics of 
ServiceName and Action are not identical to similar terms in ebXML.

Also, "types" for PartyID values are not present, nor a provision for
"Role" values.

In other words, here are some WS- spec values that do somewhat related
jobs as parts of ebXML Messaging header, but not exactly. I doubt that
we could replace the PartyId, Service, Action, and Role elements within
the ebXML header by the WS-addressing blocks without loss.  So, so far,
it looks like the ebXML header elements should stay. 

I am not certain whether there is any reason to
prohibit/disallow/discourage the WS-Addressing elements from the SOAP
header region, however. There might be a reason to allow them to be used
(perhaps by SOAP intermediaries, for example). Can anyone think of any
conflict that could arise from mixing the two forms of addressing
together?

Thanks
Dale Moberg










Follow-Ups:

Re: [ebxml-msg] Another header v 3.0 option (ws-addressing) withdiscussion and a question.
From: Doug Bunting <Doug.Bunting@Sun.COM>








[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]