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

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

> >Assaf Arkin wrote:
> 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
Yep, I think we're on the same page here. If we're using a process that provides synchronous long-running operations, we submit to whatever time guarantees are provided by that process through the underlying low-level protocol and accept that we might be left waiting for some time blocking in the <invoke>. If there is a timeout it will be a fault at the protocol level and will be handled in our process using standard BPEL fault-handling. If we are not happy with this blocking arrangement (i.e. we want to have more control) then the interaction should be modeled with asynchronous invocations and callbacks where appropriate. What I do /not/ want is for BPEL to support some sort of non-blocking invocation of req/resp operations (or similar MEP) and a corresponding operaration to "retrieve" the response(s). If the process wants such fine grained control it should define a set of operations that implement the complex interaction. This reasoning extends to all MEPs: <invoke> should encapsulate the MEP and block until the MEP's FSM reaches a terminal state. 
-maciej