RE: [ebxml-msg] some issues affecting header design

Comments inline:

From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, September 16, 2004 6:12 PM
To: 'ebxml-msg@lists.oasis-open.org'
Subject: [ebxml-msg] some issues affecting header design

A few topics that need be discussed and that directly affect the header design:

1. ebMS MEPs:
- We have outlined 3 MEPs (ebMS One-way, Request-response, Pull). The message ebMS header needs to indicate somehow:
(a) which type of MEP it belongs to (includes whether the MEP is synchronous or asynchronous),

[JWT] Currently we have a SyncReply element to indicate whether the ebXML message requires a synchronous reply. In addition if CPAs are used, the CPA will indicate what type of synchronous reply is requested (mshSignalsOnly, responseOnly, signalsAndResponse, signalsOnly, none). Is your proposal to enhance the current SyncReply element?
(b) which role the message plays in the MEP (e.g. an asynchronous response),

[JWT] Is it really necessary to indicate within the message, what stage of an MEP the message is in? Currently the Role/Service/Action of the ebXML Message describe what stage of the business process the message is in. This coupled with the RefToMessageId/ConversationId elements gives a fairly accurate picture of the current state of the business process.
(c) which MEP instance the message belongs to (may be concretized by a RefToMessageId link, in which case
the role of RefToMessageId would have to be refined).

2. Reliability info in ebMS header:
- the WS-Rel header will already have RM requirements for Request / One-way messages,
so no need to duplicate these in ebMS headers.

[JWT] Given the SOAP processing model, it is not guaranteed that the WS-Rel headers will be made available to the MSH. Do we want to mandate in our spec that these headers be made available to the MSH?
If reliability of responses (both in Request-response MEPs, and in "pull" MEP) is supported,
this new RM info is likely to be out of WS-R headers (because not supported in current WS-R,
and extension mechanism would not help if the consumer of this data is ebMS MSH)
- Will this RM info have to appear (i) in ebMS header of the Request or (ii) of the Response or (iii) both?
I tend to favor (i) or (iii).
- Another simpler alternative could also be: the reliability level of a (synchronous) ebMS Response
is automatically the same as of its Request. (e.g. if a Request has guaranteed deliv + dupl elim, so has its Response)
That way, no need for extra RM info.

[JWT] I agree that the reliability of a synchronous response is in part tied to the reliability of the request. So for example, if the sync response is lost or for some reason not received by the Sender, the Sender will resend, and the Receiver will respond with the original sync response that it had previously attempted to send( from it’s cache). This scenario is assuming DuplicateElimination functionality as described in the version 2.0 spec. I would prefer to avoid extra RM info if possible, however, I feel we need to analyze the reliability of responses in a bit more detail to identify any gaps.

3. CPA configuration:
- An important decision that will affect message header design is where the agreement (including Reliability contract)
needs be configured (Sender only vs. Sender+Receiver)
The aproach in current WS-R, is the Sender only needs be configured. If we keep this approach, then a Receiver will only need

to obtain CPA info from message header. This is not currently the case in ebMS 2.0.
Could that be achieved at least for messaging functions? Need to evaluate the value of this.
There seems to be some exception with security info (e.g. certificates).

[JWT] IMO the CPA(or similar mechanism) should continue to define the entire messaging(RM, transports, security, etc.) contract between two parties. I would like to discuss this further since this topic has been debated often in the past.

4. The "pull" (or pop) ebMS MEP:
It has similarities with a publish-subscribe mode. What should the granularity of the channel be?
"To" Destination? destination URL? within these, a conversation ID?
Also, in case no message is available (yet) on Receiver, what should be the behavior
for sending a response: wait until a response is available (asynchronous)? wait for a timeout (synchronous)?
return an empty response? should that polling be transparent to the requesting party (app level), meaning initiated
automatically by MSH?

[JWT] IMO, in the synchronous case, if no messages are available, then the receiver should either respond with some sort of status message that indicates there are no messages available, or simply close the transport session (HTTP 200 OK for example). As for asynchronous, we could also use this status message to indicate to the requesting MSH how many messages are available and will be sent asynchronously. Or the sender can simply fire the “pull” request and await any async messages the receiving MSH has available. This might not be the best way to accomplish this but it is one alternative. Also, IMO the polling should be transparent to the App, it should be something that is automatically initiated by the MSH based on some configuration parameter.

5. Message identity:
do we need an identity in addition to RM identity. That is still unclear.
Implementation aspects (which MSH+RMP architectures will/not handle a single indentity?) need be considered.

[JWT] Although multiple identities(MessageIds) in the Message would seem redundant and confusing, it might be necessary to correlate messages within an MEP at the MSH level. However, you are correct, this is still unclear, and arguments can be made for and against this. We definitely need to discuss this further.

Jacques

ebxml-msg message