Re: [wsbpel] Topics for the "Review input from TC members" sessionof the F2FSome

[Assaf Arkin <arkin@intalio.com>]

Maciej Szefler wrote:

>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. 
>  
>
I definitely agree that synchronous != HTTP connection. We have the 
technology to make synchronous interactions that take more than a few 
minutes and are reliable, so why not use it? Yes, it complicates the 
process engine implementation, but it simplifies the process design. If 
you want to see a lot of processes being defined it makes all the sense 
to invest a bit more in developing these engines and simplifies the task 
of developing the processes. I'm all in favor for moving in that direction.

I do however think that it makes life much easier if time-outs, 
failures, complex MEPs, etc are handled either by the low-level protocol 
or by the process. If that logic is specific to the process then it 
should be defined as part of the process which in some cases means using 
asynchronous operations with invocations. If that logic is of no 
interest to the process, and you can pick a suitable protocol to use, 
then let the protocol deal with the nasty details.

Is that consistent with your thinking?

arkin


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