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