Re: Message Reliability Text

Much of this seems very clear and accurate. A few comments inline.

Cutler, Roger (RogerCutler) wrote:

> Reliability may not be related simply to the end result of the operation 
> but also to factors like visibility.  For example, two applications may 
> have the same probability of producing a particular successful result, 
> but if one of them displays the inner workings of the process in such a 
> way that makes it possible to anticipate and avoid developing problems 
> or to analyze and correct errors after the fact, that application may 
> reasonably be considered more reliable than one which acts as a black box.

Interesting point. I do think reliablity implies a certain kind of 
visiblity. However, I disagree that greater visibility to errors always 
implies greater reliability.

In general, I'd prefer a somewhat more restrictive formulation: 
Reliablity as a feature is intended to reduce the error frequency for 
interactions, at least for a certain class of errors related to data 
transport. It also typically provides a greater amount of information 
about either successful or unsuccessful attempts at delivery.

> 
> In practice, many of the aspects of system reliability are handled under 
> the umbrella of the management function.  However, there is a subset of 
> system reliability that relates to messaging that is commonly considered 
> separately and referred to as reliable messaging.  In general, this 
> refers to a predictable quality of service related to the delivery of 
> the messages involved with the Web service.  In more detail, the sender 
> of the message would like to be able to determine whether a given 
> message has been received by its intended receiver so that it is 
> possible to take compensating action in the event the message has not 
> been received.  On the other hand, the intended receiver of the message 
> may wish to be assured that it has received and processed a message once 
> and only once.  The general goal of reliable messaging is to define 
> mechanisms that make it possible to achieve these objectives with a high 
> probability of success in the face of inevitable but unpredictable 
> network, system and software failures.

I think this is fine as an overview, but it glosses over a little the 
fact that individual reliability features such as confirmation of 
receipt and once-and-only once delivery are not necessarily present 
together. The reliable messaging specs mentioned below make this quite 
clear.

> The goals of reliable messaging may also be examined with respect to 
> whether one wishes to confirm only the receipt of a message, or perhaps 
> also to confirm the validity of that message.  

 > Three questions may be
> asked about message validity:
> 
> 1 - Was the message received the same as the one sent? This may be 
> determined by such techniques as byte counts, check sums, digital 
> signatures.
> 
> 2 - Does the message conform to the formats specified by the agreed upon 
> protocol for the message?  Typically determined by automatic systems 
> using syntax constraints (eg xml well formed) and structural constraints 
> (validate against one or more xml schemas or WSDL message definitions).
> 
> 3 - Does the message conform to the business rules expected by the 
> receiver? For this purpose additional constraints and validity checks 
> related to the business process are typically checked by application 
> logic and/or human process managers.
> 
> One may ask which of these message validity issues belong in the 
> technical infrastructure represented by the Web services architecture.  
> The usual answer is that the first is definitely in-scope, the last is 
> definitely not, and the second may or may not be depending on the system 
> being considered.  

IMO reliability implies 1 (complete and accurate delivery of the message 
contents). The WSA certainly allows 2 as well (this is a primary use of 
XML Schema) but you could argue it's not an aspect of reliability. If I 
send you a message and it is not what you expect, IMO it could still be 
said you received it reliably. 3 is similarly out of scope.

[Note: it seems to me that the WG may wish to decide
> that 2 is definitely in or definitely out of scope].
> 
> The final layer of this conceptual hierarchy is the actual mechanism 
> used to implement the reliable messaging goals.  This is most often 
> achieved via an acknoweldgement infrastructure, which is a set of rules 
> defining how the parties to a message should communicate with each other 
> concerning the receipt of that message and its validity.  WS-Reliability 
> (_www.oasis-open.org/committees/download.php/1461/WS-ReliabilityV1.0Public.zip_ 
> <file://www.oasis-open.org/committees/download.php/1461/WS-ReliabilityV1.0Public.zip>) 
> is an example of a specification for an acknowledgement infrastructure, 
> as is WS-ReliableMessaging 
> (_http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp_).   
> 

Might want to clarify here that the acknowledgement may take place at 
the application layer or transport layer.

--Jon

Received on Friday, 25 April 2003 13:07:29 UTC