RE: Roles for Reliability - (was RE: "Reliable" web services for Next Big Thing?)

David H wrote...

>>>What is the boundry between infrastructure and application
and thier roles in RM? <<<

This is a good point. If we assume that the basic mechanism used by RM is
the sending of an acknowledgment message by a recipient of a message, then
there are several different points at which this *could* be done where each
has a different semantic. ***PURELY FOR THE PURPOSE OF DISCUSSION*** the
attached is an example taken from an ebXML Messaging presentation I did
nearly two years ago that illustrates where various acknowledgments or error
messages **could** be generated.

What the diagram illustrates, I think, is that relying on the transport to
do RM will often not be enough. Let's take an anology with the real world.
If you send someone letter and want proof of delivery then you have a number
of options that you can request:
1. Proof that the postman delivered it - i.e. it was placed in the mailbox -
this is done by the postal service
2. Proof that someone in the mail room received it - i.e. it reached the
right company
3. Proof that it was accepted by the person who is the ultimate receiver -
i.e. it got through the internal delivery mechanism
4. Proof that it was looked at and checked by the person who is the ultimate
receiver - i.e. that the letter was opened and read
5. Proof that it was processed by the person who is the ultimate receiver -
i.e. it was proccessed and no problems were (or were not) found.

There are direct analogies between this example and information systems.
There are also issues around where you draw the line between infrastructure
and application.

Thoughts anyone on how RM fits in with this?

David


-----Original Message-----
From: Dave Hollander [mailto:dmh@contivo.com]
Sent: Thursday, December 05, 2002 8:43 AM
To: www-ws-arch@w3.org
Subject: Roles for Reliability - (was RE: "Reliable" web services for
Next Big Thing?)




There is a significant issue around the roles that must
be performed to provide predictable level of assurance.

What is the boundry between infrastructure and application
and thier roles in RM? Does there need to be a new level,
sometimes refered to extended infrastructure to handle 
these roles?

Perhaps if we just concentrate on the roles, and defer who
performs them until later, we can start to make progress.

DaveH


-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Thursday, December 05, 2002 8:53 AM
To: www-ws-arch@w3.org
Subject: "Reliable" web services for Next Big Thing? (was RE: Agenda for
5 December WSA telcon)





> -----Original Message-----
> From: Dave Hollander [mailto:dmh@contivo.com]
> Sent: Thursday, December 05, 2002 10:21 AM
> To: w3c-ws-arch@w3.org
> Subject: RE: Agenda for 5 December WSA telcon
> 

> I am inclined to support working on "reliable messaging",
> I think it is an imporant next step in wEB sERVICES 
> (anyone want to sponsor that capitialization???)
> 
> I think the single word "reliable" is just to ambiguous.

Yup. This is another one of those densely interconnected
clusters of issues (sortof like "choreography"): "Asynchrony"
is associated with it (without a reliable substrate, senders
and receivers can talk "out of band" to ensure that messages
were received), it's tangled up with Coordination and Transactions
because Web service invocations can fail for all sorts of reasons
besides messages not being delivered,  and we are sure to hear 
from the RESTifarians that the whole idea of supporting reliability
in the infrastructure rather than the application is counter 
to the One True Web Architecture. 

Can we just focus on "reliable messaging" (AFAIK, a guarantee that
a SOAP message will arrive either 0 or 1 times at its destination,
and the sender will be unambiguously informed which it was), or
is the larger architectural question of "reliability" something 
we can dig into?

So, consider this topic officially open for public discussion!