RE: [ebxml-msg] general reliability of ebMS MEPs

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

Title: RE: [ebxml-msg] general reliability of ebMS MEPs

Doug:

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Wednesday, September 15, 2004 8:43 AM
To: Jacques Durand
Cc: 'ebxml-msg@lists.oasis-open.org'
Subject: Re: [ebxml-msg] general reliability of ebMS MEPs

Jacques,

As I remind myself of this proposal and think about today's meeting, two
questions occur to me:

- Is everything in the 'Proposal for "Response reliability"' relevant only
to option (2b) in your list near the top?

<JD> relevant only to (2b) and (3b) (although this 3rd ebMS MEP (3) has only been discussed in the TC at this point - no consensus yet). The notion of "Response reliability" described here boils down to the reliability of the response leg of a SOAP Request-response MEP. We can keep that notion abstract from the underlying protocol by just reminding the assumption put on the processing of a SOAP Request-response:

(i) the SOAP processors (Sender, and Receiver) can always correlate the request and response without
a need for special correlation indicators in message (SOAP) header. This is indeed the case when binding to a synchronous underlying protocol.

(ii) the round-trip time to complete a request-response, is expected to be relatively short (not long-lasting transactions)(this assumption matters more to the implementation of reliability, e.g. has implication on persistence capability required)

</JD>

- (r1) is considerably weakened because, unlike ebXML 2.0, a Receiving RMP
is not required to cache responses.  That is, "or else an error is notified
to the request Producer (sender side)" will be an unfortunately common case
for some Receiving RMP implementations.  What about imposing a requirement
on the Receiving RMP that it must cache responses when the (2b) pattern and
once-and-only-once are selected (for a particular incoming message)?

<JD> I indeed came to the same concusion as yours:
If a Response was successfully produced on Receiver side, it should be cached/queued for a reasonable time in case the Response fails to be delivered back. A retry mechanism would then have the Sender retry the request, and the cached Response would be sent back. So even if more than one copy of the Request message is delivered to the Consumer (due to no duplicate elimination) then the first response is the one that would be sent back (we cannot assume the Request messages are idempotent on Receiver).

Note that this is exactly the same queuing mechanism that would support a "Pull" message mode (3b).
Is that what you had in mind?
</JD>

thanx,
        doug

On 10-Sep-04 00:43, Jacques Durand wrote:

> This is an outline on how different ebMS 3.0 MEPs would be handled by a
> reliability component.
> This goes beyond the MEPs from Jeff that were related only to
> asynchronous Request-response MEP.
> I do not detail here  how the RM-Reply is sent back, (Jeff did it for
> the async Request-response), but instead focus on the
>
> way the ebMS MEPs map to RMP operations, the reliability features
> supported, and in particular, on the meaning of reliability for the
> response leg of Request-response MEPs. Note in particular MEP #3.
>
> Assuming three ebMS MEPs below, the following exchanges and reliability
> support apply:
>
> 1- ebMS One-way MEP (a SOAP One-way MEP with ebMS headers)
>
> SOAP One-way MEP: Payload (PO BOD, etc.) ------> S-RMP.Submit ------->
> R-RMP.Deliver -----> Payload(PO BOD, etc.)
> Reply patterns allowed: [callback, poll]
>
> 2- ebMS Request-response MEP:
>
> (a) asynchronous  (maps to two SOAP One-way MEPs)
> SOAP One-way MEP: Payload (PO BOD, etc.) ------> S-RMP.Submit ---->
> R-RMP.Deliver ---> Payload(PO BOD, etc.)
> SOAP One-way MEP: Payload (PO Ack BOD, etc.) <--- S-RMP.Deliver <----
> (Payload + RM-Reply) R-RMP.Submit <--- Payload(PO Ack )
>
> Reply patterns allowed in request: [callback, poll](also in response, if
> it is a reliable message too)
>
> (b) synchronous (maps to SOAP Request-response MEP, assuming binding to
> a request-response transport)
> SOAP Request-response MEP [request]: Payload (PO BOD, etc.) --->
> S-RMP.Submit ----> R-RMP.Deliver --> Payload(PO BOD, etc.)
>
> SOAP Request-response MEP [response]: Payload (POAck BOD, etc.) <---
> S-RMP.Notify <--- R-RMP.Respond <--- Payload(POAck BOD, etc.)
>
> Reply patterns allowed in the request: [response, callback, poll]
>
>
> 3- ebMS Pull-Message MEP: (we assume here a signal is sent requesting
> the message to be "pulled")
>
> (a) asynchronous. (same pattern as for 2.a)
> (b) synchronous (actually maps to a SOAP Request-response MEP, not a
> SOAP Response MEP as defined in SOAP 1.2 Part 2,
> because of an ebMS header in the request which is a "signal" - only
> intended to MSH - to pull a message.)
> SOAP Request-response MEP [request]: ("pull" header element, no
> payload.) ---> S-RMP.Submit ---> R-RMP.Deliver ---> pull signal to MSH
>
> SOAP Request-response MEP [response]: Payload (PO BOD, etc.) <---
> S-RMP.Notify <--- R-RMP.Respond <--- Payload(PO BOD, etc.)
>
> Reply patterns allowed in the *request*: [response, callback, poll] (see
> explanation below)
>
>
> Comments on the above:
> ----------------------
>
> - there is no consensus on the exact meaning of the term "synchronous",
> which in the above case means
> a binding of SOAP Request-response to a "synchronous" underlying
> protocol. For the lack of better term, I am using
> "synchronous" in this sense for now. (in some other definition - e.g. in
> some RosettaNet literature, synchrony is not a transport property
>
> but rather is a serialization of several request-response instances)
>
> - All exchanges that map to SOAP One-way, can be subject to full
> Reliability features as defined in WS-R.
> (except for for those features that don't apply to One-way, like
> "response" reply pattern)
>
> - If poll is used (synchronous ), that would require an additional SOAP
> Request-response MEPs not mentioned here.
>
> - finally, there has to be a way to indicate in an ebMS header which
> type of MEP a message belongs to.
> The usage of RefToMessageId will help
> correlate a "response" to a "request", but there has to be a way to tell
> if a request belongs to an ebMS One-way or Request-response.
>
>
>
> Proposal for "Response reliability":
> ------------------------------------
>
> There are two cases where reliability features as described in WS-R
> would not apply
> to an ebMS business message : these are the cases above where the
> message is submitted via "Respond" to the RMP (2.b and 3.b)
>
> However, I propose that, *in ebMS* we refine the notion of reliability
> of "ebMS Response messages"  (at least for the synchronous
>
> case).
> Indeed it does not make sense to apply the same reliability definition
> to Request messages and Response messages,
> as the mechanisms used for Requests don't apply (e.g. you can't just
> "resend" a response if no Ack is obtained, due to
> tranport binding constraints, and duplicates simply won't occur unless
> the Request was duplicated too, for the same reasons)
>
> The Reliability of a Response (response leg of SOAP Request-response) is
> defined as follows:
>
> .(r1) the guaranteed delivery contract for an ebMS synchronous Response,
> is that when a Request has been sent,
> a Response should be obtained by the Sender, or else an error is
> notified to the request Producer (sender side).
> (so no Ack is used for the Response leg, and no independent automatic
> resending of the response will be done.
> But guaranteed delivery of the Request would greatly ensure success for
> the Response, so should be part of this contract.)
>
> .(r2) the duplicate elimination contract for an ebMS synchronous
> Response, simply includes the duplicate elimination of
>
> the Request, combined with a Sender behavior that "once a response
> received for a request has been delivered to the
> Request producer (sender side), then no other response correlating to
> the same request will ever be delivered
> to the Request producer".
>
> .(r3) the ordering contract for an ebMS synchronous Response, would be
> based on the order of Request submission, NOT of
> Response submission: Response payloads would be delivered to Producer
> (sender side) in the same order as the Requests
> have been submitted by this same Producer (to the MSH). A simple way to
> enforce this, is to not send an ebMS Request message
>
> before the previous Response was received.
> A second option, more efficient, would have the MSH enforce pipe-lining
> on Sender side: Response messages would be
> delivered by MSH in same order as the requests have been submitted to
> this MSH.
>
> These definitions of Reliability for Responses can be enforced by the
> Sender MSH with very little effort:
> they mostly leverage the reliability of the Request which is supported
> by the RMP
> (even when the request is just a signal like in 3.b)
>  From an implementation viewpoint, (r1)(r2) and (r3simple option) all
> can be implemented in MSH without duplicating
> RMP functionality. Even (r2) does not require persistence of IDs beyond
> the ones of current on-going Request-responses
> which have by definition a short lifespan if synchronous.
>
> The bottom line is a rather optimistic summary:
> - the definitions of reliability used for a Request message cannot be
> applied to a Response message (in "synchronous"
> Request-response MEPs): they need be adjusted.
> - once adjusted, Response reliability appears to involve and leverage
> the reliability of the Request leg. This makes
> it easy to implement Response reliability at MSH level, without
> duplicating RMP functions.
>
>
>