Jacques,
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
Jeff:
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.
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.