RE: preliminary notes on using WS-R in ebMS V3

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

Title: RE: preliminary notes on using WS-R in ebMS V3

Jeff:

I have sent to the list a summary of issues/items on this topic late last night ,
but have not seen my mail reflected back to me, though it is in the mail archive on ebMS members page.
(dated Aug 12).
So you may not have seen it either (the list reflector may be delayed?)

So this is just to notify you and the list , that you'll find my notes on the "Recent Email Messages" ebMS page.

Additional notes:

- Section 3 (Message ID) this section tries to suggest that a separate message ID (in addition to
"reliability" ID) might not be needed, but that needs more investigation:
clearly not all messages involved in the reliability protocol have a Reliability ID (group + seq num)
(e.g. messages with a Response header only). So it seems that reliability ID is no substitute for a conventional ebMS ID.

Even so, I can see a possibility to do without an additional ebMS ID - if we consider this worthwhile -
as any message can still be uniquely identified, being always either RM-identified itself, or related to an RM-identified message (using RefToMessageId) within a particular MEP.

- Section 6 suggests that there is value in defining ebMS MEPs, as this allows for more clearly stating how each message in such an

MEP makes use of the RMP (e.g. maps to its operations). The section only describes some ebMS MEPs, and does not suggest how they would map to RMP operations. If we decide that some legs of these MEPs map to the RMP Respond operation then we expect that no reliability (in WS-R 1.1 sense) is provided for the response. This should be the case

for "synchronous" exchanges that bind to underlying request-response transports. (In such cases, some reliability of the response leg

is supported  by the binding itself, e.g. a response failure would be known from the original Sender, which is what matters.

Yet we would need to handle such failures at ebMS level - e.g. at minimum, escalate a "transaction failure" to sender app.)

So the binding of an ebMS MEP to the underlying protocol (not the MEP itself) may decide of the use of RMP.
For example: assuming an ebMS "request-response" MEP , we would be able to provide reliability for both
messages in case of asynchronous binding to underlying protocol, but only for the request in case of synchronous binding.

This distinction would be concretized by different use of RMP operations for the response (async: use Submit, sync: use Respond)

Same for what I call the "pull-message " MEP: in case of synchronous implementation (which makes sense e.g. if security
restrictions prevent the Sender to "push"), then we would provide WS-R reliability to the pull signal only (e.g. guaranteeing

that it is received), and not to the actual business response - but again in that case, the most critical is to ensure
reliable delivery of the request leg of an underlying "synchronous" protocol.

Jacques