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

["Maciej Szefler" <mbs@fivesight.com>]

Assaf Arkin wrote:
> But I still believe we need to make a distinction between 
> interactions 
> that are finite in time (where finite could be 24 hours) and 
> constrained 
> to some fault-detecting context (e.g. a BPEL scope), and between 
> interactions that are not finite in time and not constrained to a 
> fault-detecting context and so are done using separate asynchronous 
> operations. For example, if you consider submitting a 
> purchase order and 
> receiving an acceptance, that is typically finite in time and 
> handled by 
> the same sender.
I would not argue with the above characterizations. Certainly as a purely practical matter the finite time constraint is very important. My feeling is that the distinction you make based on fault-detecting context is in general more significant and should be viewed as /the/ distinction between synch/asynch interactions. 

> 
> But if you consider receiving an invoice and submitting 
> payment, these 
> two messages can be handled by different processes. In some 
> implementations the invoice will be sent and the payment would be 
> received by the same process. In another implementation the 
> invoice will 
> be sent by some process which then starts a payment 
> collection process, 
> and the payment is correlated and routed to the payment collection 
> process (which can be used in other contexts as well). This 
> is a clear 
> case where using asynchronous interactions becomes more 
> interesting. If 
> a failure occurs while waiting for the payment this is not a 
> problem for 
> the process sending the invoice - you already shipped the 
> order there's 
> nothing you can do about it. It is, however, an issue for the payment 
> collection process to deal with.

The case I am thinking of is something along the lines of a loan approval process where the loan parameters are submitted and the loan is either approved or denied. To me this is a synchronous request/response interaction; even though the approval process may take weeks, I would like to model such a process without asynchronous callbacks. This is particularly handy when nesting processes (i.e. when the loan approval process is a sub-process of a loan origination process), reducing considerably the complexity of the nesting processes. 

-Maciej Szefler