[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - New Issue Discovered
The intent of my message was misunderstood (my issue is not about whether ebMS MEPs should have more semantics w/r to the ebMS headers). Let me clarify (See inline my answers in red color …)
From: Jacques Durand
I don’t see anything critical enough to require much of our attention before CD2 here.
[Hamid]: First, this issue or any other possible issue that may arise has nothing to do with our vote for CD2. The vote for CD 2 is planned for the end of this month and nothing will change that. We wanted to vote for CD 2 on Feb 8, and it did not happen because of delays in editing, and this time we planned to vote for it by the end of Feb (this will not be postponed anymore). So, there is no need to panic (CD 2 will be voted no matter how we agree or disagree on its contents. If someone does not agree on the contents of CD 2, changes may be submitted for CD 3. This is exactly what we did for CD 1. We voted for CD 1 even though I disagreed with much of its contents, but I knew I could change some of them for CD 2). So, I hope that this is clear enough that these discussions we are having will not affect or postpone the vote for CD 2.
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.
[Hamid]: I never said CollaborationInfo always make sense for the response, nor do I agree with such a statement. Dale, if you say that conversationID and agreementRef are important for the response message, I would say we don’t need them. Why? This is simply because the response message already contains an eb:RefToMessageId header element which would tell me (I am the Sender MSH) about the message that was sent previously and therefore I know exactly what were the conversationID and agreementRef for that message. It would simply be redundant to include such information as conversationID and agreementRef in the response message (unless we don’t require anymore that the response message include an eb:RefToMessageId header element which I doubt that).
I’d also propose to postpone any debate on whether Service/Action should be optional.
[Hamid]: The debate has nothing to do with the vote for CD 2 and there is no reason for postponing such discussions. CD 2 will be voted no matter what.
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.
[Hamid]: I don’t see any interop risk here. When I said that “CollaborationInfo” element should be optional, I meant for a response message not for a request message. Of course, we can’t express this fact in XML schema (saying that such an element is required for this but optional for that). But, the point is that we should not be constrained by the limitation of XML schema. It simply make sense to say that the element eb:CollaborationInfo is REQUIRED for a request message and OPTIONAL for a response message. Being optional does not mean a response could not have an eb:CollaborationInfo element if it chooses to and knows exactly what to put in there. The thing is that there are many use-cases where the sender is just a client and does not have a service/action concept, and does not need an eb:CollaborationInfo in the response. We cannot ignore those use-cases and simply say that eb:CollaborationInfo is always REQUIRED (just to satisfy an XML schema which is unable to allow flexibility when an element is required and when it is optional).
Should eb:From and eb:To be always reversed from request to response user message?
[Hamid]: My answer is of course yes (eb:From and eb:To SHOULD be reversed for a response) if the receiver MSH don’t know how to populate the headers of the response. However, in 99.9 % of cases, eb:From and eb:To will be reversed for the response. It may seem that not requiring eb:From and eb:To to be reversed would allow for more general and sophisticated use-cases where the responder may put any eb:From he wants and even may send this response to a different destination. But we have to be very realistic here. These exotic scenarios could not be covered like this by just saying that eb:From and eb:To are not necessary reversed for a response. In order to cover the exotic scenarios, we need to support them from the beginning in the spec and that is really out of scope because it would ask for a complete new design which ebMS-3 was not based on. There are only two cases for the response: either the response is synchronous or asynchronous. This latter case is not yet covered in the Core part of ebMS-3, and therefore it is out of scope in this discussion. For the first case of a synchronous response, it simply make sense that eb:From and eb:To would 99.9% be reversed. But this is not really the issue I was talking about.
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?
[Hamid]: Of course not. We cannot require an MSH to enforce that eb:From and eb:To are reversed for a response. In the same way we don’t require what values should be in the eb:From element of a request message (which is part of an agreement), there is no way we can require what values should be in the eb:From of a response message and that the sender MSH should enforce it. All what the sender MSH cares about is the payload returned in the response message. The only case where the sender MSH would care about eb:From in the response message is when this response message is itself a new request message (and this case can only happen if the response is asynchrnous).
- 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)?
From: Dale Moberg [mailto:email@example.com]
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.
[Hamid]: Dale, as I said, even if conversationID and agreementRef may be important, they are completely unnecessary since the response message always contains an eb:RefToMessageId which is more than enough (from RefToMessageId I can very easily figure out the values for conversationID and agreementRef)
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.
[Hamid]: It seems that my email was not correctly understood. Currently there is a real problem for any implementation that would try to conform to the current ebMS-3 draft. The problem is clear enough and it is the following: the MSH receiver is not able to fill the service/action parameters of a response when the sender MSH is just a client that does not have any service/action. The draft says the service/action are REQUIRED all the time (for any user message, be it a request or a response) and this is forcing the receiver MSH to populate these headers even though it doe not know what to put in there. That is a real problem. This is not about profiling ebMS-3. If we cannot implement ebMS-3 before ebMS-3 is profiled, then this is a real problem. We cannot write a spec that nobody can implement unless other specs are written afterwards in the aim to profile our spec and make implementations of it feasible.
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.
[Hamid]: I don’t know about ebMS-2. If ebMS-2 allows empty fields for eb:Service and eb:Action in the response message (syncreplyMode), then I would say it is the most ugly design possible. It is obvious that certain response messages don’t need Service/Action (don’t need eb:CollaborationInfo), and it is just nonsense to keep saying eb:CollaborationInfo is always REQUIRED just to be constrained by XML schema which is unable to allow flexibility.
- even the eb:From and eb:To are not required to be reversed in a Request-reply MEP (spec does not require this)
[Hamid]: This is not about whether the spec should require eb:From and eb:To to be reversed. The spec should not require nor forbid this. The case of eb:From and eb:To is not an issue, because the receiver MSH, when it does not know what to put for the eb:From and eb:To in the response message, it can always resort to reversing eb:From and eb:To to solve the issue. The problem at hand (case of service/action) is when you don’t have a value to populate a certain header that the draft says it is REQUIRED.
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.
[Hamid]: If the reply goes somewhere else, it could not be the request/response MEP that the Core spec talks about, and therefore it is out of scope to discuss it here. My opinion on this, is that eb:From and eb:To would be 99.9 % reversed for the response (within the scope of the Core spec of ebMS-3). Therefore, I see no harm in REQUIRING a response message (case of a request/response MEP described in the core spec) to reverse the eb:From and eb:To headers. I see no benefit in allowing such a flexibility for the request/response MEP to allow anything in the eb:From of a response. In any case, the sender MSH, when receiving the response of req/resp MEP, does not really care about the eb:From (the case that a response user message may be itself a new request cannot be argued here because it would violate the req/resp MEP itself). The only case where the response could be a new request by itself is when such a response is asynchronous and this is out of scope.
This discussion changed towards eb:From, eb:To and MEPs. That is not my concern and what I talked about. The real problem I was describing is about service/action elements that are made REQUIRED elements by the spec and that is very inappropriate for many use-cases where the response does not need them and the receiver MSH simply does not know how to populate them, and it is out of question to simply use empty fields for service/action simply to conform to XML schema that is black-and-white when it comes to describing required/optional elements.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]