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

["Satish Thatte" <satisht@microsoft.com>]

David,
 
Distributed transaction coordination has all the same problems that you mention.  Most people don't build handling of transactions with uncertain outcome into applications.  This is handled manually in the few cases where it occurs.  Now you could argue that these distributed transactions often occur within firewalls and in closer proximity than we might have in the relable messaging B2B case but I would argue that in most cases the same principal applies.
 
Satish

	-----Original Message----- 
	From: Burdett, David [mailto:david.burdett@commerceone.com] 
	Sent: Mon 5/26/2003 11:12 PM 
	To: 'Cummins, Fred A'; Marin, Mike; wsbpel@lists.oasis-open.org 
	Cc: 
	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
	
	---------------------------------------------------------------------
	To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
	For additional commands, e-mail: wsbpel-help@lists.oasis-open.org