RE: Proposed text on reliable messaging

Thanks, Roger.  Yes, that was what I tried to express.

I also think that we agreed more than we don't agree between Frank and me.
Frank's "fifthly" suggestion sounds pretty good to me as well.

Hao

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
Sent: Tuesday, August 26, 2003 12:12 AM
To: Francis McCabe; He, Hao
Cc: www-ws-arch@w3.org; w3c-wsa-editors@w3.org
Subject: RE: Proposed text on reliable messaging



I think that there is a possibility that you have misunderstood to some
extent what Hao has been trying to say -- but I'm not sure that I
understand myself.  I don't THINK that he is really saying that reliable
messaging should address business function.  I thought that the "action"
he is talking about refers to the acknowledgement action, not the
delivery of a car to someone's doorstep.

Having said that, I agree with your statements below and I PARTICULARLY
agree with your "fifthly" one.

I suspect, however, that there may be more common ground between you and
Hao than this thread seems to imply.  I'm pretty sure that there is at
least some measure of missed communication here, but I'm not smart
enough (nor do I have time enough, to be honest) to try to track it
down.

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: Monday, August 25, 2003 2:37 AM
To: He, Hao
Cc: www-ws-arch@w3.org; 'w3c-wsa-editors@w3.org'
Subject: 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>