OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Topics for the "Review input from TC members" sessi on of the F2FSome


I think that Fred is right and we should assume that RM specs will exist.
The problem is that there is no such thing as 100% reliable message delivery
- 99.9999% maybe but not 100%. The problems behind for this has been
explored ad nauseam in other groups [1].

The reason it can't be 100% is that all reliable messaging protocols are
based on the principle of sending an acknowledgement when a message is
received. However the following sequence is always possible ...

1. A sends message to B
2. B sends ack message to A but the ack message get's lost
3. B forwards the message to the application for processing
4. B crashes, catastrophically - e.g a fire and there is no back up of
messages received or sent

No matter how many times A resends the message, it will never be able to
determine *at the messaging level* that the message has been delivered - you
have to make inquiries at the application level to find out what has gone
on.

Although you might think that this makes reliable messaging pointless, I
don't actually think so as, if reliability really is 99.9999% then the
process designer could probably reasonably decide ...

"If a message get's lost then send a message to an administrator who can fix
it manually, e.g. on the phone"

... on the other hand, if reliability is only 99% because there is no RM
protocol, then the process designer might want to make the application to
handle the problem and include the logic for it in the process definition.

Here's another use case that needs to be handled ...

1. An application passes data to a (SOAP) message handler for sending over
the internet
2. The SOAP message handler can't send the message as there is no transport
available as a car fire in an underground car park burnt the cables
connecting the computer centre to the internet and there was no backup (this
is true story actually)

What should the application do - assume the message will be delivered? In
this actual use case, it took about 3 days for internet connections to be
restored.

Either way, handling lack of successful message delivery, is a problem that,
IMO, has to be considered in any (business) process definition spec.

Just my $0.02c

David

[1]
http://www.w3.org/Search/Mail/Public/search?type-index=www-ws-arch&index-typ
e=t&keywords=reliable+messaging
-----Original Message-----
From: Cummins, Fred A [mailto:fred.cummins@eds.com]
Sent: Thursday, May 22, 2003 11:53 AM
To: Marin, Mike; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Topics for the "Review input from TC members"
sessi on of the F2FSome 


Mike,

Such busiess operations should be implemented with reliable messaging.
Thus the individual participants employ transactions to post and 
remove messages from their respective queues, and the reliable
messaging protocol assures that messages are communicated from the
sending queue to the receiving queue once and only once.  In effect
the reliable messaging protocol is the "transaction" protocol of the
exchange.

Fred Cummins
EDS

> -----Original Message-----
> From: Marin, Mike [mailto:MMarin@filenet.com]
> Sent: Thursday, May 22, 2003 2:17 PM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Topics for the "Review input from TC 
> members" session
> of the F2FSome 
> 
> 
> 
> I have few issues that I will like to add to the list of "Review input
> from TC members" for the F2F meeting.
> 
> a- We don't have distributed transactions on web services yet.  So how
> do we insure that an activity such as an "invoke" is executed exactly
> one time?  The following example illustrates the problem:
>  
> 1. Process A begins execution of an invoke instruction, and sends an
> input message to Process B.  There is no output message defined on the
> invoke.
> 2. Process B is defined with a receive instruction 
> corresponding to the
> invoke of process A, and the receive instruction creates a 
> new instance
> of the process.  So upon receipt of the message from process A, a new
> instance of process B is created, and this instance executes 
> the receive
> instruction.
> 3. The machine hosting process A crashes.
> 4. Process B executes the next step, which is to debit an account and
> update a database.
> 5. Process B terminates.  Process B has finished.
> 6. The machine hosting process A is restarted.  Process A then
> re-executes the invoke instruction.  
>  
> On step 6, how can we prevent process A from executing the invoke a
> second time, creating another instance of process B, and debiting the
> account a second time?  
> 
> b- Invoking an operation, with input and output, that is 
> implemented by
> a process using receive and replay requires the WSDL operation to be
> asynchronous. A process may take days or weeks between the receive and
> the reply, so the client cannot keep a connection open waiting for the
> reply. Although WSDL 1.1 talks about asynchronous operations; it does
> not seems to be any support for it in the WSDL specification. 
> 
> From the point of view of the process executing the invoke 
> the operation
> is asynchronous in that the process blocks for the reply. 
> But, from the
> point of view of the service implementing the receive reply pair; the
> operation is asynchronous, and there is no way to prevent the time
> between the receive and the reply from taking weeks. So, the invoking
> process is blocked, but it cannot maintain a connection open.
> 
> c- I am also concerned with the use of WS-Addressing for end point
> references. I'm basically echoing the comment by Ron Ten-Hove.
> 
> d- Just a note in the specification reference section, 
> reference [16] is
> WS-Addressing. In appendix C, reference [16] seems to be for
> WS-Transaction.
> 
> 
> --
> Mike Marin           | FileNET Corporation   | (714) 327-5134 
> Software Architect   | 3565 Harbor Boulevard | mmarin@filenet.com 
> eProcess Development | Costa Mesa, CA 92626  | mmarin@acm.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]