RE: Reliable Messaging Summary - Cont

Reliable Messaging Summary - ContThere are typically three problems that
need to be addressed:

Layer 1: How to get a message from sender to receiver
Layer 2: How to improve the reliability of the delivery
Layer 3: How to synchronize the work performed using such a delivery
mechanism

You want to be able to use a protocol that is efficient in order to allow a
scalable solution. Several protocols come to mind, like UDP (exteremly low
latency, low reliability), HTTP (low latency, high reliability), SMTP (high
latency, medium reliability). An optimal solution would work equally well
for all these protocols and additional protocols. (Perhaps you are using a
proprietary protocol since both sender and receiver happen to be hosted by
the same system)

If the medium you use is extremely reliable you will typically not consider
a solution for layer 2. For example, if you need to deliver a message and
can tolerate significant delay, SMTP will work for you (SMTP actually does
layer 2 for you). However, you may not consider delays acceptable, in which
case you need improved reliability through resending. You may also want
protection from a possible modification of the message by intermediary,
again something that layer 2 would offer.

Layer 2 works to eliminate message loss as much as possible. It does so in
several ways:

- Using signatures it can prevent an attacker changing the message en route,
so the message recevied is always the message sent
- Using persistence it can assure that a message received will be available
for processing
- Using resend it will increase the likelihood that a message reaches its
destination to the point where costly solution to message loss (handling it
at the application level, human intervention) are acceptable

Even if you have an extremley reliable medium you would still want to have
layer 2 in there so you never end up processing the wrong message or losing
a message that you acknowledged.

Layer 2 will never guarantee that the message is processed, processes as was
intended by the sender, or provide the sender with information about the
processing of the message. So if two systems need to synchronize the work
they are doing, they need to resort to layer 3. I would not call layer 3
reliable messaging. Even though it improves reliability by extending layer
2, what it tries to address is actually coordination.

TCP/IP works at layer 3 since it attempts to allow two nodes to synchronize
with each other. Since it is based on IP, it must be able to address layer 2
in one way or another, and I guess the decision was to implement layer 2 as
part of TCP/IP instead of relaying on a separate protocol that does
"reliable IP". Actually, I can think of a benefit for doing both layer 2 and
layer 3 inside TCP/IP, but I don't think that benefit extends to WS.

ebXML also works at layer 3 since it tries to address interactions that are
part of a business transaction. So it actually does the work of layer 2 and
layer 3, simplifying the development of the business application by placing
as much of the workload on top of the RM. In effect it is trying to go
beyond reliable messaging and into coordination (asking what the state of
the transaction is, asking to cancel it, etc).

I think ebXML offers a very coherent approach to the problem of reliable
messaging and coordination in a single specification. The WS Architecture
working group needs to decide whether that should be addressed by a single
specification, or a combination of specification.

A possible solution would be to address reliable messaging at the protocol
layer (XMLP and SOAP), provide additional synchronization capabilities at
the coordination layer (BTP, WS-Transaction) and allow the applications to
define a synchronized protocol on top of these two layers (choreography).

arkin

  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Cutler, Roger (RogerCutler)
  Sent: Monday, December 16, 2002 11:54 AM
  To: www-ws-arch@w3.org
  Subject: Reliable Messaging Summary - Cont


  Let me try to add to the summmary I posted earlier of the Reliable
Messaging threads to cover the more recent activity.  Again, I may get this
wrong, but if I do please help out.

  It seems to me that in the recent, sometimes very detailed, threads we are
now seeing a second model for Reliable Messaging.  That is, the first more
or less takes the ebXML spec as the starting point, the second pretty much
builds on the concepts embodied by TCP/IP.  These approaches appear to have
many features in common, but I do not think that they are identical.  I am,
unfortunately, unable to select a representative set of references on the
TCP/IP-like thread, other than the already referenced "six level" starting
point.  Perhaps the experts would care to summarize where it stands?

  It seems to me that it would make sense, in a potential handoff to XMLP,
to make them aware of both approaches and let them reconcile them or
whatever.