RE: [ebxml-msg] Groups - New Issue Discovered

[Hamid Ben Malek <HMalek@us.fujitsu.com>]

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.