Comments inline:
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