some issues affecting header design

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: 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),
(b) which role the message plays in the MEP (e.g. an asynchronous response),
(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.
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.

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).

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?

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.

Jacques