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