[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - New Issue Discovered
|
Hi everybody. 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 Guys: 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)? Jacques From: Dale Moberg [mailto:dmoberg@cyclonecommerce.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]