[ebxml-msg] Re: Final Summary on [ebxml-cppa] Comments on reliablemessaging in the 1.0.5 draft

[Christopher Ferris <chris.ferris@sun.com>]

I do not think that the idea of special handling for situations
when the synchronous connection is lost (to send the response
on an asynchronous channel) is such a good idea and would
oppose any change to the ebMS spec that attempted to take this
approach.

If the synchronous connection is lost, then the response
message can be cached, persisted or the transaction can be
rolled back as deemed most suitable for any given implementation
that is intended to provide a synchronous response. If the
response is lost from the original senders POV (the client
in the HTTP binding) because a connection was dropped, it will resend
and either the cached/persisted response can be returned or
in the case where the transaction was rolled back, it can be
repeated assuming that the rollback included all memory of the
original message.

Cheers,

Chris

Dale Moberg wrote:

> Here is what I hope is my final remark in this thread.
> I corresponded with David F. off-line to make certain
> I understood what concerned him. I think David is basically
> worried about using synchronous modes of transport, but
> more specifically, about handling exceptions when the
> connection is "lost" before a reply (response MSH signal or
> BusinessLevel Response etc.) gets back. 
> 
> Currently this is just an error and
> would force trying again. David wishes to have special exception
> handling for a situation in which the data has arrived OK,
> and a response is available, and the connection dropped.
> His proposal is to send the response asynchronously when
> this exceptional case is encountered. The advantage is
> a resource usage optimization--the need to retry is
> diminished.
> 
> My proposal is that such an agreement about exception
> handling, and fallback in Transports to be tried, might
> be handled using a CPA, rather than as part of a protocol
> specification. However, this functionality might not
> make it into the CPPA 1.1 version. CPPA already can
> describe agreements to use alternative transports within
> a service binding. Basically David F's convention could
> be a special flavor of this alternative transport
> agreement.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>