Title: RE: [ebxml-msg] Groups - New Issue Discovered
Hi everyone
I did not follow the conversation but I saw that you mention Service and Action, and even Roles ... actually they have great value if you take the top down approach and if you define your collaborative business processes (with ebXML Business Process) first. Eg you just have to look at the ebXML message header and you got all the information in one place, that is very convenient.
The From, FromRole, To, ToRole, Service, Action, and CPA id values in fact provide the link to the ebXML CPA (to look up security, reliable messaging and other messaging operational aspects). At the same time and in combination with the conversation ID these values provide the information to identify the document exchange in the collaborative business process. So to me ebXML Messaging "2.0" has actually very good support for higher level collaborative business processes. So to deal with ebXML messages that do not have those values anymore ... it would take some headscratching how to interact with the next layer (CPA in this case).
From what I see the advanced ebXML end users, those who think along the lines of adding, removing and changing collaborative business processes over time to their trading partner relationsships, do in fact take the top down approach starting with the collaborative business processes, managing the CPA's and then using ebXML messaging that supports that approach by those Role, Serivce, and Action information in the ebXML message header.
Ignore this email if my concerns are not related to your current discussion.
Sacha
-----Original Message-----
From: Jacques Durand [mailto:]
Sent: Mon 27.02.2006 16:19
To: Dale Moberg; Hamid Ben Malek;
Subject: 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:]
Sent: Monday, February 27, 2006 9:23 AM
To: Jacques Durand; Hamid Ben Malek;
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.
