OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Maciej Szefler wrote:

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

arkin




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]