RE: Champions for Draft-status requirements? / D-AC017

>What wording would you have in mind for "4"
 
>>There is, I believe, also a 4th characteristic of reliable messaging; the
ability of 
>>an application to include the act of sending and receiving a message in
coordinated 
>>transactions with other resource managers such as the application's
database. I suppose 
>>that this could technically be considered an aspect of 3, but an important
point worthy of 
>>mention. 

 
How about:
 
The ability of a participating web services to coordinate and align their
transaction-related 
operations such that they can either commit or roll back updates to their
respective 
resources (e.g., application database and transactional objects, persistent
queues, etc.)
used in the end-to-end web service transaction. 
 
 
There are a couple of issues/considerations here:
1. Peer-to-peer web services interactions is being assumed
2. Definition of a transaction is lacking (e.g., is this atomic transaction
or cohesive transaction?)
3. Are we implying option of using 2PC between participating web services?
4. Not all web services will require such aspects of reliability; however,
complex transaction
   supply chains scenarios are relevant target use cases
5. Participating web services may use different transaction managers/models,
transport
   protocols, which may imply transaction coordination and interoperability
(E.g., wireless 
   web service app that interacts with an online web service app which
interacts to 
   another online web service).
 
 
 
Zahid Ahmed
 
 
-----Original Message-----
From: Burdett, David [ mailto:david.burdett@commerceone.com
<mailto:david.burdett@commerceone.com> ]
Sent: Thursday, August 29, 2002 11:49 AM
To: 'Christopher B Ferris'; www-ws-arch@w3.org <mailto:www-ws-arch@w3.org> 
Subject: RE: Champions for Draft-status requirements? / D-AC017


Chris
 
>>>As you may recall, I was involved as well:) <<<
 
How could I forget ... ;)
 
I like your definitions,  however, they do not address what I think is the
certainty that although you can be sure a message was received, you can
never be absolutely sure that it was not.
 
So I would tweak "3" to say ...
 
"3.  the ability of both sender and receiver to carry out 1 & 2 with a high
probability of success in the face of (inevitable, yet often unpredictable)
network, system, and software failures"
 
What wording would you have in mind for "4"
 
David

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, August 29, 2002 4:32 AM
To: www-ws-arch@w3.org
Subject: RE: Champions for Draft-status requirements? / D-AC017



David, 

As you may recall, I was involved as well:) I think your characterization is
close. 
I offer yet another stab at a definition as I believe that your definition
is slightly suggestive 
of a solution: 

Reliable messaging refers to: 
1)  the ability of a sender to be able to determine whether a given message
has been 
received by its intended receiver and to take compensating action in the
event a given message 
has been determined not to have been received 
2) the ability of the intended receiver to be assured that it receives and
processes a given message 
once and only once 
3) the ability of both sender and receiver to successfully carry out 1 & 2
in the face 
of (inevitable, yet often unpredictable) network, system, and software
failures 


As Geoff has pointed out, there may be varying QoS characteristics that
apply mostly to 
the degree to which sender and receiver will provide for 3 to minimize the
potential for 
undelivered messages or for compensation of catastrophic failure. 

There is, I believe, also a 4th characteristic of reliable messaging; the
ability of 
an application to include the act of sending and receiving a message in
coordinated 
transactions with other resource managers such as the application's
database. I suppose 
that this could technically be considered an aspect of 3, but an important
point worthy of 
mention. 

Cheers, 

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624 

www-ws-arch-request@w3.org wrote on 08/28/2002 07:49:55 PM:

> 
> I was involved in ebXML Messaging from the early days, so how about this
as
> a statement of the requirement from an ebXML perspective ...
> 
> Reliable Messaging is the ability for one service to use a protocol to
send
> a message to another so that:
> 1. The sender of the message is provided with positive confirmation that
the
> message was successfully delivered
> 2. The probability of successful delivery of the message is very high
> 3. The recipient of the message can identify and, if required, ignore any
> duplicates of the message
> 4. The sender of the message is notified if, for some reason, delivery of
> the message was not possible or is uncertain
> 
> Hope this helps.
> 
> David
> 
> -----Original Message-----
> From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
> Sent: Wednesday, August 28, 2002 11:33 AM
> To: 'Geoff Arnold'; Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: RE: Champions for Draft-status requirements? / D-AC017
> 
> 
> 
> OK by me.  I was just giving it a shot, for what it was worth.  Perhaps
you
> could flesh out a better explanation of what reliable messaging is?  As I
> keep saying, I think it is important because there is a very widespread
> perception that security and reliable messaging are the hot spots for
making
> web services practically usable for business processes.  The requirements
> doc talks a lot about security ...
> 
> -----Original Message-----
> From: Geoff Arnold [mailto:Geoff.Arnold@Sun.COM] 
> Sent: Wednesday, August 28, 2002 12:49 PM
> To: Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: Re: Champions for Draft-status requirements? / D-AC017
> 
> 
> On Wednesday, August 28, 2002, at 01:06  PM, Cutler, Roger 
> (RogerCutler) wrote:
> 
> >  One of the solutions to this problem, I think, is to
> > define reliable messaging a bit more accurately, for example by
> > replacing
> > terms like "reliably exchange" (below) with something like "reduce the
> > uncertainty of the message transmission to a practically acceptable 
> > level".
> 
> The phrase "practically acceptable level" seems to be inviting trouble.
Why
> not simply talk about measurable reliability levels (i.e. QoS)?
> 
> Curious,
> 
> Geoff
>

Received on Thursday, 29 August 2002 16:18:13 UTC