[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - New Issue Discovered
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]