- From: <michael.mahan@nokia.com>
- Date: Fri, 24 Oct 2003 13:50:17 -0400
- To: <RogerCutler@chevrontexaco.com>, <Hao.He@thomson.com.au>, <www-ws-arch@w3.org>
- Cc: <Mike.Champion@SoftwareAG-USA.com>
No - my phone was cutting out during the teleconf when reliability was discussed. If the group addressed this specifically and an agreement was made then I apologize for bringing it up again. I assume this was discussed on the teleconf - the latest text from you does address the issue I am raising. MikeM >-----Original Message----- >From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On >Behalf Of ext Cutler, Roger (RogerCutler) >Sent: October 24, 2003 12:48 PM >To: Mahan Michael (NRC/Boston); Hao.He@thomson.com.au; >www-ws-arch@w3.org >Cc: Mike.Champion@SoftwareAG-USA.com >Subject: RE: Message reliability > > > >Are you aware of the objections I had to the definition that strikes >what you want striken? How do you answer that? > >-----Original Message----- >From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On >Behalf Of michael.mahan@nokia.com >Sent: Friday, October 24, 2003 10:59 AM >To: Hao.He@thomson.com.au; www-ws-arch@w3.org >Cc: Mike.Champion@SoftwareAG-USA.com >Subject: RE: Message reliability > > > >Two issues: > >The definition states only that the messaging parties involved are >suitably informed and have the same understanding of delivery status. >The explanation then states that the goal is to reduce error >frequency. It seems that this should be stricken - unless it is in >scope for reliable messaging to address compensating actions. (I >don't know if that is true or not, but the definition doesn't say >it). > >Also, the explanation discusses overall system reliability which >for me is tried to repeatable results. The explanation then claims >that performance is enhanced at both the message and system level >when message reliability is applied. The way I measure performance >is by speed and latency metrics. In this dimension, reliable messaging >does not enhance performance. > >Mike > > >>-----Original Message----- >>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On >>Behalf Of ext He, Hao >>Sent: October 23, 2003 06:14 PM >>To: 'www-ws-arch@w3.org ' >>Cc: 'Champion, Mike' >>Subject: RE: Message reliability >> >> >>It was agreed to accept Roger's definition in today's >>discussion, so the >>text has been modified to reflect the decision. >> >>Editors of the architecture document, please incorporate the >>text into the >>document. >> >>Hao >> >> >> 2.3.1.13 Message reliability >>2.3.1.13.1 Definition >>Message reliability is the degree of certainty that a message will be >>delivered and that sender and recipient will both have the same >>understanding of the delivery status. >> >>... skip ... >> >>2.3.1.13.3 Explanation >> >> >>The goal of message reliability is to both reduce the error >>frequency for >>messaging and to provide sufficient information about the status of a >>message delivery. Such information enables a participating >>agent to make >>a compensating decision when errors or less than desired >results occur. >>High level correlation such "two-phase commit" is needed if >>more than two >>agents are involved. Note that in a distributed system, it is >>theoretically >>not possible to guarantee correct notification of delivery; >however, in >>practice, simple techniques can greatly increase the overall >confidence >>in the message delivery. >> >>It is important to note that a guarantee of the delivery of messages >>alone does not improve the overall reliability of a Web service due >>to the "end-to-end argument."[1] It may, however, improve the >>performance >>of >>messaging, and therefore, the overall performance of a Web service. >> >>Message reliability 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. >> >>[1]http://www.reed.com/Papers/EndtoEnd.html >> > > > >
Received on Friday, 24 October 2003 13:50:23 UTC