Re: Proposed text on reliable messaging

First of all, it is not *my* definition of reliable messaging. Any 
number of people have looked at this stuff, and there are even specs 
out there that focus on Message Reliability.

Secondly, AFIK, noone else has linked the two levels in the single pot 
of reliable messaging

Thirdly, there are any number of slips 'twixt the cup o' the message 
and the lip o' the application

Fourthly, RM was never intended to be the answer to *reliability* If 
you want to tackle reliability at the application level you are welcome 
to try.

Fifthly, I strongly believe that a better approach would be to look for 
analogues of reliability at the different levels: E.g.,
   Message reliability at the Message Oriented Model level
   Service Reliability at the Service Oriented Model level
   Trust at the Policy model level

This last is why I get a little hot under the collar: I think that you 
are conflating in an effort to solve the problem in a `quick' way. But 
a point solution the solution does not make.

Frank

On Monday, August 25, 2003, at 11:36  AM, He, Hao wrote:

> Agreed -- the difference is massive and important.  The only problem 
> with
> the RM in your definition is that it provides little value to 
> applications,
> if there is any at all. Applications still need to know whether the 
> business
> function is triggered so people still need to implement similar things 
> that
> you have done at the RM layer.  This has been verified in a number of 
> Web
> service implementations I know of.  If we want to make RM in Web 
> service any
> useful, we really need to make the requirement.
>
> Hao
>
> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Monday, August 25, 2003 12:22 PM
> To: He, Hao
> Cc: www-ws-arch@w3.org; 'w3c-wsa-editors@w3.org'
> Subject: Re: Proposed text on reliable messaging
>
>
> There is a massive difference between knowing that a message has been
> delivered and knowing whether the business function that should be
> triggered by that message has been performed. The former is part of
> reliable messaging, the latter is not.
>
> On Monday, August 25, 2003, at 07:52  AM, He, Hao wrote:
>
>> I would argue that "got through" is just as vague as "acting on the
>> message".  What matters to end applications is that they need to know
>> whether messages they sent have caused the expected effects so they
>> can take
>> corresponding actions.  Simplying knowing that a message has been
>> shipped is
>> not sufficient. A message is shpped from point A to point B does not
>> mean
>> much unless the intented receiver at point B can act on the message.
>> This is
>> the end-to-end argument in http://www.reed.com/Papers/EndtoEnd.html
>> The point is that millions of things can still go wrong even your
>> messages
>> arrive at point B.
>>
>> Hao
>>
>> -----Original Message-----
>> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
>> Sent: Saturday, August 23, 2003 10:33 PM
>> To: He, Hao
>> Cc: www-ws-arch@w3.org; 'w3c-wsa-editors@w3.org'
>> Subject: Re: Proposed text on reliable messaging
>>
>>
>>
>> I have serious doubts about some of this stuff.
>>
>> The requirement to `act on a message' is vague, onerous and off the
>> point. If the intent is to encourage reliability then this neither
>> guarantees nor is sufficient for the goal.
>>
>> Clearly, the essence of reliable messaging is that the *sender* of a
>> message has some guarantee that the message *got through*. That should
>> be the focus of this topic, not *acting on the message*
>>
>> Frank
>>
>> On Thursday, August 21, 2003, at 08:28  AM, He, Hao wrote:
>>
>>> I've taken my action item to work on the reliable messaging text. 
>>> I've
>>> tried
>>> to improve the text on the following aspects:
>>>
>>> 1. To clarify the concept of "reliable messaging" under the context 
>>> of
>>> Web
>>> services.
>>> 2. To articulate more on the difference between "guarantee of
>>> delivery" and
>>> "reliable messaging"
>>> 3. To add the "end-to-end argument".
>>> 4. To explain why the "life cycle" of a message may be important to
>>> improve
>>> reliability.
>>> 5. To correct a few typos.
>>>
>>> As always, your comments are appreciated.
>>>
>>> Hao
>>>
>>> 2.3.1.13 Reliable messaging
>>> 2.3.1.13.1 Definition
>>>
>>> Reliable messaging is a feature that may contribute to the overall
>>> reliability and efficiency of Web services. Reliable messaging
>>> requires
>>> participating software agents to act on a message after receiving it.
>>>
>>> Relationships to other elements
>>>
>>> reliable messaging is
>>>
>>> a feature
>>>
>>> reliable messaging may be realized by
>>> a combination of message acknowledgement and correlation.
>>>
>>> a good practise of reliable messaging is
>>> to make the life cycles of messages available to participating
>>> software
>>> agents.
>>>
>>> 2.3.1.13.3 Explanation
>>>
>>> Reliable messaging can improve the overall reliability and efficiency
>>> of Web
>>> services. Reliable messaging in Web services not only requires the
>>> delivery
>>> of messages but also the contact on the receiving agent to act on
>>> those
>>> messages as defined in service contracts.
>>>
>>> The goal of reliable messaging is to both reduce the error frequency
>>> for
>>> messaging and to provide sufficient information about the life cycle
>>> of
>>> messages. Such information enables a participating agent to make a
>>> compensating decision when errors or less than desired results occur.
>>> It is
>>> important to note that a guarantee of the delivery of message  alone
>>> does
>>> not improve the overall reliability due to the "end-to-end
>>> argument."[1]  It may, however, improve the performance of messaging.
>>> Requiring an agent to act on a message after receiving it would
>>> improve the
>>> overall  reliability of Web services that only involve two software
>>> agents.
>>> High level correlation such "two-phase commit" is needed if more than
>>> two
>>> agents are involved.
>>>
>>> Reliable messaging may be realized with a combination of message
>>> receipt
>>> acknowledgement and correlation. In the event that a message has not
>>> been
>>> properly received and acted upon, the sender may attempt a resend, or
>>> some
>>> other compensating action at the application level. Note that in a
>>> distributed system, it theoretically
>>> not possible to guarantee correct notification of delivery; however,
>>> in
>>> practice, simple techniques can greatly increase the overall
>>> confidence in
>>> the message delivery.  For example, a good practise is to make
>>> messaging
>>> idempotent so a sender can attempt sending a message again without
>>> worrying
>>> of causing undesired effects, if it is unsure about the status of the
>>> previous message.
>>>
>>> Message correlation may be used by the receivers of messages to 
>>> ensure
>>> that
>>> messages are only acted on once - with duplicate messages being
>>> ignored or
>>> treated as errors. Whether two messages are duplicated is defined at
>>> the
>>> application level.
>>>
>>> [1]http://www.reed.com/Papers/EndtoEnd.html
>>> <InterScan_Disclaimer.txt>
>> <InterScan_Disclaimer.txt>
> <InterScan_Disclaimer.txt>

Received on Monday, 25 August 2003 03:37:23 UTC