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

["Satish Thatte" <satisht@microsoft.com>]

I completely agree that "thread management" tricks should not be added to BPEL to manage "long-running" MEPs.  
 
At the same time we should keep in mind that there is a related issue regarding the constraints an outstanding MEP against a service may (or may not) place on additional interactions with the same service from concurrent activities.  This is the tricky issue of how bindings affect process that we need to at least discuss to see what, if anything, we can do to mitigate it in BPEL.

	-----Original Message----- 
	From: Maciej Szefler [mailto:mbs@fivesight.com] 
	Sent: Fri 5/30/2003 11:14 AM 
	To: Assaf Arkin 
	Cc: Mark Little; Marin, Mike; wsbpel@lists.oasis-open.org 
	Subject: RE: [wsbpel] Topics for the "Review input from TC members" session of the F2FSome
	
	

	> >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
	
	---------------------------------------------------------------------
	To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
	For additional commands, e-mail: wsbpel-help@lists.oasis-open.org