preliminary notes on using WS-R in ebMS 3.0

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

Title: preliminary notes on using WS-R in ebMS 3.0

I owe Jeff these notes on using WS-R in ebMS 3.0:

  Summary of perceived issues:

  1 - Order of feature processing in the message is TBD. Not sure yet if it can be serialized by well-separate functional groups (allowing for an implementation involving different SOAP processors). I.e., intertwining of functions of different groups, should be avoided. An exampe of processing order of received messages:

(a) security, (b) reliability, (c) un/packaging, (d) payload services.
Constraints:
- reuse of existing specifications (WSS, WS-R) will ignore ebMS headers.
- payload services should remain independent from XMLDsig and sig validation.
- Receiver: Reliability would be processed before other significant ebMS processing like payload services, so
that messages are only processed if passed reliability  (e.g. not duplicates , or not in a broken ordered sequence)
- Security (at least some form of it) will likely need be processed first (clearly encryption,
  but also authentication)

2 - Models of RM integration that need be supported: (this is not just an implementation issue,
but will affect the specification itself.)
- Option A: The MSH is an RMP (enhanced with ebMS functions).
This means that the Deliver operation in WS-R, is also an ebMS delivery to the same Consumer.
- Option B: The MSH is a pipe-lined composition of an RMP and separate processor(s) of other ebMS features. (e.g. SOAP nodes, or Java handlers.) This model would support the reuse of RMP implementations that are unaware of ebMS. when implementing an MSH.

 
3 - Message ID:
Given the reliable message ID (group + sequence number), and if RM is a mandatory feature in V3.0,
is there a need for another message ID (in ebMS headers)?
-In design option A, the message ID used for RM can be clearly be used as ebMS ID.
-In design option B, using a separate "ebMS ID" may still not be needed: it all depends on the type of communication assumed between the serialized processors. On the Sender side, although ebMS packaging is done before adding RM headers (order: (d)+(c)+(b) ), ebMS packaging/payload svces may not need use any message ID (other than references to previous messages such as RefToMessageId). On the Receiver side, (order: (b)+(c)+(d) ) the ebMS unpackaging step will require knowledge of the Message ID. The RMP could pass it along (though some implementations may not, as this is normally for RMP consumption only. E.g. an RMP SOAP node will consume and remove the RM headers).  

4 - Semantics of acknowledgement:
In option (A), RMP delivery = MSH delivery, and the reliability contracts are about delivery to the MSH COnsumer.
In option (B), the RMP delivery can be interpreted as passing the message to the next MSH processor. In that case it may happen that the message is Acked, while never delivered to the MSH COnsumer (e.g. bad ebMS packaging). An option would be to reduce chances of ebMS failure (e.g. move un/packaging earlier), though that would not completely eliminate the above scenario. It is to be noted that WS-R interpretation allows for composition architectures where the "Delivery" we want RM contracts to target (here MSH to COnsumer), has to occur after additional(and possibly failing) processing, beyond RMP functions. Indeed, this additional processing can be included in the interpretation of the RMP Deliver operation: since the message is acked only if Deliver is complete, (and faulted otherwise) that means RM contracts can effectively be about MSH delivery to COnsumer (e.g. message would not be

acked if ebMS unpackaging failed, and would be RM-faulted "MessageProcessingFailure" instead.)
Not all "building bloc" MSH implementations may be able to achieve this, if off-the-shelf RMP implementations prevent this broader interpretation of Deliver. But design (B) is compatible with Ack on MSH delivery.

5 - Composing Security and reliability:
In option (B) A message rejected by the security processor will not reach the RMP, and therefore may cause unnecessary resending (in case of Guaranteed Delivery). Note that this is the case with any processor preceeding the RMP.

Such a failure should generate a fault back, which should reach the Sender RMP ultimately. This kind
of 3rd party fault was not explicitly mentioned among those that can stop message resending in WS-R,
(though latest rewording in WS-R could be interpreted as blocking resending for any external fault code as well, other than MessageProcessingFailure...). (maybe that should be a configurable feature for WS-R that enhance composability).

As a consequence, there is a gray area in WS-R as how to avoid resending in case
of SOAP fault due to processing failure prior to the receiving RMP. (Possibly, a post-RMP processor on Sending side, could block retries that it knows have been faulted by its counterpart on Receiving side...)

6 - The use of RMP operations (Deliver, Respond...) may need be linked to specific ebMS patterns.
So far the reliability of messages submitted via RMP Respond operation, is not supported in WS-R.
We will likely need to describe ebMS MEPs more formally than in ebMS 2.0, e.g. in terms of SOAP MEPs,
in a way that is somehow abstracted from the underlying transport.
  - We can identify three ebMS MEPs (here described informally) that we have talked about in V3:
(and I am assumimg here a tie to SOAP MEPs, though not sure of how much we need this tie)
  (i) The usual One-way. At SOAP level, it is a SOAP One-way MEP, characterized by
  a single message initiated by the sender (i.e. not as a result of a previous protocol action
  such as an HTTP GET or POST). If SOAP binds to a request-response transport like HTTP, this MEP means no SOAP envelope appears in the response (but error codes can still be returned and interpreted at transport level).

  The ebMS One-way MEP simply extends on the SOAP One-way by requiring
  that the message sent be an ebMS message (tells what are the headers and attachement style allowed).
  (ii) The ebMS Request-response MEP. At SOAP level, it is a SOAP Request-response MEP,
  as defined in SOAP 1.2 Part 2 (adjuncts).
    The ebMS Request-response MEP extends on the SOAP One-way by defining what types of ebMS
  messages (headers, etc) may be found in the request and the response.
  (iii)  The ebMS "Pull-Message" MEP. (or other name... refers to the pulling of messages, initiated by Receiver) This also means sending a request message in order to get a response, but the request

  is a signal intended to the MSH only, and not to the Consumer of the MSH.
  This could map differently to SOAP MEPs: if the request is not even a SOAP message, then
  this can map to a SOAP Response MEP (as defined in SOAP 1.2 Part 2).
  But if we intend to have the request be an ebMS signal, then it will map to a SOAP
  Request-response MEP. The difference with (ii) is of course the type of ebMS header
  allowed in the request.
- the use of RefToMessageId , and of "synchronous messaging", may define which of these ebMS MEPs is used.

7 -  The notions of RM group and ebMS COnversation seem orthogonal so far. Conversation
  will be broader than a group (concern messages both ways, involve several partners).
  Can a group span several conversations, i.e. can COnversations reuse groups, merely as
  particular QoS carriers, or should the scope of a group be contained within (belong to) a conversation.