RE: Synchronous Messaging Proposal - Some Thoughts

["Burdett, David" <david.burdett@commerceone.com>]

Mike

See comments below.

David

-----Original Message-----
From: Michael Joya [mailto:mike.joya@xmlglobal.com]
Sent: Tuesday, December 12, 2000 1:46 PM
To: ebxml-transport@lists.ebxml.org
Subject: Re: Synchronous Messaging Proposal - Some Thoughts


>>>    Proposal: OnceAndOnlyOnce messages should be required to use a
>>> synchronous transport medium. The acknowledgement should arrive on the
>>> same connection as was used to send the original message.

> Basically I disagree with this restriction. Using a synchronous transport
is
> fine, but there is no need, IMO, to restrict reliable messaging to this
type
> of transport. The key elements of any reliable transport are the
following:
<snip>
I see your points, David. I was just unsure of the utility of reliable 
messaging over a protocol with such a high turnaround time. I suppose I 
am focusing on SMTP with this. Here is the (potentially ugly) scenario I 
foresee:

Cl --> SMTP Request --> Sv
Cl   <-- SMTP Ack -->   Sv
Cl  <-- SMTP Reply --   Sv
Cl   --> SMTP Ack -->   Sv

To me, this is a costly trip for a request that may be as simple as a 
drill-down browse request to a registry. 

<davidb>
I agree, and if you designed a "reliable" query mechanism thatr worked in
this way, then the designer probably didn't do a good job. But if we think
about this, why do you need reliable messaging on a query, by definition, a
query cannot change state, so repeating the query is not a problem. Where
you might more reasojnably use SMTP is if you are sending a purchase order
where the processing of the order is not urgent. For this I think SMTP could
be OK, and therefore we should not preclude its use.
</davidb>

Uncomfortable tradeoffs I can 
see surrounding the (Asynchronous+Reliable) message combination:

1. An application-derived reply IMPLIES msh-derived acks.
You get rid of the acks this way. However, suppose the errorURI differs 
from the original message's SenderURI. The message has been received and 
should be acknowledged. Due to exceptional cases in the application, an 
error must be sent. An ack is required, a reply to the senderURI is not. 
For this reason, I find it difficult to support 1.
<davidb>The Error URI should **only** be used to report problems in the
envelope or header that the MSH can detect. If there is an application level
error then the application needs to determine a way of reporting it. What
this would mean is an aysnch transport, then an error in the envelope should
be sent to the ErrorURI instead of the SenderURI. If there is no error, then
the ack should be sent to the SenderURI.
</davidb>

2. The application selects BestEffort when doing lightweight ops.
This may be unacceptable to the application. Is this what you intend? 
To me, this is the most acceptable tradeoff. If this is the case, please 
mention this in the specification.
<davidb>I think I must be misunderstanding you. When you say that the
application selects BestEfforts, then the application should not select it
unless it is acceptable. I do think though that BestEffort will often be an
appropriate approach where reliability is not required, e.g. when doing a
query.</davidb>

3. The application selects a transport protocol by name.
This may be unacceptable to designers. Is transport-transparency a 
requirement of TRP? 
<davidb>What is a requirement is that the same message can be sent using
various transport protocols with different protocols being used on each
hop.</davidb>
I'm not in much position to argue for or against 
this. However, what's the point in having an MSH if the application is 
choosing and setting underlying transport methods anyway?
<davidb>Generally the MSH would select the transport based on what had been
agreed/specifiec in the CPA.</davidb>

4. Constraint is enforced in the MSH layer that Reliable delivery 
semantics REQUIRE synchronous transports.
This is my original suggestion, countered by David. In addition to my 
original points, I think it would bring some simplicity to the overrall 
process.

   I don't mean to present this as an argument in either of the above 
cases :). It's just that I will be glad when the specification is more 
clear on which combination and sequence of async/sync replies/acks 
reliable/unreliable is proper; and how an MSH should delegate accordingly.
<davidb>Chris Ferris and I are working on this. I agree the current spec is
not clear.</davidb>


-- 
// mike.joya@xmlglobal.com
// XML Global
// POC Project Team - ebXML
// Vancouver, Canada
// 604.717.1100 x230