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

Guys:

I don't see anything critical enough to require much of our attention before CD2 here.

Basically what I hear from Dale is that indeed whatever is in CollaborationInfo element makes sense in general for a response, whether "synchronous" or not. That was also my impression.

I'd also propose to postpone any debate on whether Service/Action should be optional. There seems to be serious arguments against it, or for making this a non-issue (e.g. I now recall that the ebMS2 profiling for RosettaNet makes use of Service/Action for response messages - either Action or Signal messages - regardless whether synchronous or not.) It seems that far from being used only in the sense of "method invocation" (which makes sense only for a request) Service/Action is often used as <businesss Tx Id / doctype name> pair. Also optionality adds one more interop risk.

Should eb:From and eb:To be always reversed from request to response user message?

That is the only statement I would challenge... (though it seems there are at least 2 TC members who think it should be so)

The practical side of this issue is:

- do we want to require MSHs to enforce this?

- will that apply only to the [synchronous] "simple Request-reply MEP"? when later on we have more complex asynchronous MEPs with async response messages that have as much business semantics as the simple MEP will the MSH still need to do so? How would this interfere with possible use of wsa:ReplyTo ?

I'd say it is all well and good if an agreement or BP requires this - that can always be verified above MSH level, like so many other Bus Tx parameters like timing. That could also be enforced by the "processing mode" , i.e. configuration. Can we be so sure that this constraint suffers no exception that it should be hardcoded in the MSH (i.e. in MEP definition)? Aren't we going to face such exceptions if we allow an MSH to be associated with several "eb:From" (or eb:To)?

Jacques

From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Monday, February 27, 2006 9:23 AM
To: Jacques Durand; Hamid Ben Malek; ebxml-msg@lists.oasis-open.org
Subject: 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