OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: notes on WS-R + ebMS 3

Title: notes on WS-R + ebMS 3



Thank you for your notes, here is some initial feedback. I would like to discuss these in greater detail on today’s call if possible. Cheers!




1 – Overall I agree with you order of Message processing listed below. The only one that is unclear to me is (c) un/packaging. Depending on how you define un/packaging, this could be the first processing step in the inbound Message processing task (i.e., unpackaging the MIME Multipart, etc).


2 – I think ideally we should have Option B as a goal. In my opinion, allowing implementers to build a pipelined MSH consisting of separate SOAP processors/handlers(home grown or 3rd party) would be ideal. I feel this would make our spec more attractive to implementers and increase its adoption. However, we must clearly describe in the spec the Message processing flow and the interaction between each SOAP processing node.


3 – Since I would like to keep the SOAP Header as small as possible, I feel that having both the eb:MessageId and the WS-R MessageId would be redundant. One concern I have is that currently in v2.0 the MessageId/RefToMessageId pair are used both in ReliableMessaging (Acknowledgments), and to identify business request/response pairs. Not sure if Option A will work with all WS-R implementations, for the reason you list in Option B. That being that the WS-R MessageId is for RMP consumption only. E.g. an RMP SOAP node will consume and remove the RM Headers. Perhaps we can discuss both Options A and B in more detail on the next call.


4 – I feel that Option B would best suit a “pipelined” MSH architecture. I like the composition architecture that you describe below, where the RMP Delivery operation consists of a series of separate processing operations (handled by separate SOAP processors/handlers in the MSH pipeline). The Deliver operation only succeeding if all processing operations succeed.


5 – This could be a problem. If security processing fails, which would result in the MSH faulting the Sender, we would not want the Sending RMP to resend that Message. I think that given your point about the latest WS-R rewording, we would want to clarify in our spec that the MSH would expect the Sending RMP to block resending for an external fault code. A post-RMP processor is also an option I think we should discuss.


6 – Is the lack of support for a reliable RMP Respond operation a concern? Could we work around this by using two one-way operations perhaps? I would like to discuss this since I am not comfortable that I truly understand the issue. In any case, all three MEPs (One-Way, Request-Response, and Pull-Message) that you describe below are applicable to v3.0 and in my opinion will need to be supported. In my opinion conversations are definitely broader than a group. How we describe the relationship between Groups and Conversations is still TBD. You present some interesting options that I would like to discuss further on the next call.


From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, August 18, 2004 9:23 AM
To: Jeff Turpin
Subject: notes on WS-R + ebMS 3


Just wanted to make sure you got this in the mail archive
(was not reflected for some reason)

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]