RE: [ebxml-msg] Groups - New Issue Discovered

Your point is really about whether ebMS MEPs should have more semantics w/r to the ebMS header content.

- CollaborationInfo still contains info that makes sense for responses (e.g. COnversationId, and AgreementRef - though optional - will likely be used in the response if it has been used in the request.)

Dale>> The use of ConversationId should be required for allowing several concurrent instances of a process to be distinguished for monitoring purposes, IMO.

Otherwise ebMS lacks some features needed for a business quality solution.

Perhaps we can have a web services profile for “interoperability” of a MSH with a WS node, but to me, that would just be something like saying, use SOAP 1.1/1.2.

- Service/Action are the only questionable fields, and here it may be up to users ( up to some profiling they decide) how to use them in a response.

Other ebXML specifications say how Service and Action are to be used in combination with ebMS. Are you going to ignore that?

- In case they are not supposed to be used, they can always remain empty fields - the way ebMS2 would do with its de-facto req-resp MEP (syncreplyMode) - otherwise if we don't like that then these elements should be the ones to be made optional.

- even the eb:From and eb:To are not required to be reversed in a Request-reply MEP (spec does not require this)

Dale>> I think we should require that they be reversed and that this is part of the definition of the MEP. If a Reply goes somewhere else, it is a different MEP. I think this requirement should be made for interoperability and so that monitoring of messaging contracts remains governed by clear semantics. Are we really aiming to become so technologically amorphous that ebMS provides no support for the other parts of ebXML?

- and indeed, in some cases the response may go to a different party on the back-end, even if the same MSH is used.

Dale>> I think this alters the definition of Request Response pattern as understood in ebXML (which is mainly a business semantic). Certainly it loosens it up so much that the ebMS becomes a poor implementation for the BPSS patterns.

ebxml-msg message