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

["Marin, Mike" <MMarin@filenet.com>]

Fred,

With respect to topic "a"; I agree, but how do you do that using a SOAP
binding on WSDL? (Or an HTTP binding for that matter). I think the
specification should have some wording on this topic. 

--
Regards,
Mike Marin

-----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"
session 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
>