Re: Synchronous Messaging Proposal - Some Thoughts

[Michael Joya <mike.joya@xmlglobal.com>]

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

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.

3. The application selects a transport protocol by name.
This may be unacceptable to designers. Is transport-transparency a 
requirement of TRP? 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?

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.



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