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

Yes, at least for the starting point that I think Dave and I are talking about (and again I hope I got that right), we would be thinking about application level responsibility for interpreting a simple "ack".  In the post office analogy I think this would fit somewhere around the signed receipt idea, as in the U.S. I believe is called "certified mail."  All we'd be asking for is information confirming receipt of the message.

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, December 05, 2002 3:45 PM
To: 'Dave Hollander'; www-ws-arch@w3.org
Subject: 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!