[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - New Issue Discovered
Hamid: Not sure if that is really a new issue
- at least one critical enough to need immediate attention. Your point is really about whether ebMS
MEPs should have more semantics w/r to the ebMS header content. But: - 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.) - 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. 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) and
indeed, in some cases the response may go to a different party on the back-end,
even if the same MSH is used. So it appears a lot of this is more
an issue for some profiling to decide - beside maybe the optionality of
Service/Action which does not seem that critical. Jacques From: While implementing the current draft, I discovered a new issue: The current draft (both 08 and 09)
don't really talk about a response UserMessage in terms of packaging. The
packaging described throughout the draft is implicitly (or explicitly) made for
a request UserMessage, a PullRequest, and an Error Message (but not for a
response UserMessage). It is implicily assumed in the draft that a response
UserMessage is very similar to a request UserMessage and therefore, there
should be no difference between them in packaging. Actually, all what the draft
says about a response UserMessage is one thing only: that a response
UserMessage MUST have the element eb:Messaging/eb:MessageInfo/eb:RefToMessageId
in order to correlate this response UserMessage with a request UserMessage
(whether this response UserMessage is returned synchronously on the same
connection or asychronously as a separate UserMessage in its own connection).
This seems fine at first glance, but it is not fine when you start implementing
this. Here is exaclty the problem when you start populating the packaging
headers for a response UserMessage: ·
The eb:MessageInfo element of the response UserMessage
would have a child element eb:RefToMessageId that contains the value of the
MessageId of the request UserMessage. ·
The eb:From element in the response UserMessage would
correspond to the eb:To element from the request UserMessage, and the same
thing for eb:To (in other terms, eb:From and eb:To elements are simply inverted
for a response UserMessage by taking the eb:From of the request and making it
an eb:To in the response, and taking the eb:To in the request and making it an
eb:From in the response). So far, so good (just using common sense). ·
Now the problem arises when trying to populate the element
eb:CollaborationInfo of the response UserMessage. The collaborationInfo element
contains three REQUIRED elements: a Service, an Action, and ConversationID. The
problem is that the response UserMessage is just "a response". In
other terms, the response UserMessage is not intended for an action and a
service. Even if we consider the very twisted case where a response UserMessage
is also a request to be consumed by a Service, there is no way for the receiver
MSH to know what service and action values should be put in the headers of a
response UserMessage (since such information has never been vehiculated to the
receiver MSH). ·
The same argument goes for eb:MessageProperties element (but
fortunately this one is optional). ·
The element eb:PayloadInfo of a response UserMessage is
somehow a little different. First, it is normal (common) that a response
UserMessage contains a payload (this payload is simply the data returned from a
given service that has consumed a request UserMessage). This payload data that
is returned is easily described in the P-Modes configuration that is shared
between the two MSH and therefore the sender MSH knows exactly the format of
such payload and how to extract it and hand it over to the sender application. Conclusion: It seems to me that it is
incorrect in our current drafts that the element eb:CollaborationInfo is
REQUIRED. This element SHOULD be optional. There are many cases (I would say
99%) where the response UserMessage is not to be consumed by a Service and
action but simply to be handed over to the sender application which may be
playing a client role only. Any thoughts? Hamid. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]