RE: [wsbpel] Removing "compensating a process as a whole"

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

Yuzo,

 

I understand your concern.  But keep in mind that BPEL does not have a closed world assumption.  There are many things it leaves unspecified, for instance binding and deployment of service endpoints and processes themselves.  Many policies will apply to processes in an actual implementation, including lifetime of the instance after completion (i.e., how long to maintain compensation state).

 

Consider also the BA protocol in WS-Transaction which shows how the compensation of a subordinate instance would be invoked by a controlling instance, if we were to specify such a subordinate-controller relationship in BPEL, effectively "remoting" a scope as a separate instance (without implicit state sharing).  The BA protocol messages could be handled by implicit event handlers that maintain the BA protocol semantics.

 

I am not saying yet that we should actually do this, just throwing out some interesting possibilities to think about.

 

Satish

	-----Original Message----- 
	From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] 
	Sent: Thu 6/19/2003 9:40 PM 
	To: Assaf Arkin 
	Cc: wsbpel@lists.oasis-open.org 
	Subject: Re: [wsbpel] Removing "compensating a process as a whole"
	
	

	Asaaf,
	
	> Yuzo,
	>
	> I would recommend not using an event handler but rather a pick. The
	> event handler is enabled for the lifetime of the process before you
	> reach a point where compensation is possible. However, you can replace
	> the wait with a pick that either waits for a compensation request
	> (received only once) or gives up after some time-out. That's consistent
	> with your suggestion for writing a compensation handler using the
	> available set of constructs.
	
	I understand.
	
	>
	> But there two issues that would arise as per the current specification:
	>
	> 1. Currently the specification does not allow you to perform
	> compensation from outside a compensation handler, so you can't invoke
	> compensation on enclosed scopes. Clearly you would want to do that from
	> the compensating activity that follows the base activity.
	
	I've rewritten the example as follows. It should work now.
	
	  <process>
	   <faultHandlers>
	      catch compensationRequested fault and compensate.
	    </faultHandlers>
	    <sequence>
	      <scope>
	       ... compensation handler ...
	       ... the "body" of the process ...
	      </scope>
	      <pick>
	        <onMessage...for compensation request...>
	          <throw faultName="compensationRequested"/>
	        </onMessage>
	      </pick>
	    </sequence>
	  </process>
	
	>
	> 2. For management purposes there's a value in determining that the
	> process has reach the 'completed' case after which it can only be
	> compensated or discarded. Structuring activities in this manner would
	> work, but would not give a management tool visibility into the process
	> state.
	
	I agree that this can be a problem.
	
	To solve the problem, we may need to formalize the concept of "body" of
	the process such that a process instance can be in state
	 "process as a whole=running, body=completed".
	I don't like this idea very much, but nonetheless present it here to hopefully
	promote the discussion.
	
	Yuzo
	
	>
	> So there's some benefit to the structuring mechanism. I bet we can
	> either resolve these two issues and do away with the process
	> compensation handler, or resolve the two issues you raised and define
	> how companstation is invoked and how it can expire. Any ideas?
	>
	> arkin
	>
	>
	> Yuzo Fujishima wrote:
	>
	> >I would like to propose that we remove the concept of
	> >"compensating a process as a whole".
	> >
	> >>From 6.4:
	> >  If a compensation handler is specified for the business
	> >  process as a whole (see Compensation Handlers), a business
	> >  process instance can be compensated after normal completion by
	> >  platform-specific means. This functionality is enabled by
	> >  setting the enableInstanceCompensation attribute of the
	> >  process to "yes".
	> >
	> >Rationale 1: "compensating a process as a whole" introduces
	> >uncertainties into the specification. These uncertainties leaves
	> >the feature hardly usable in my opinion.
	> >
	> >  Uncertainty 1: how to request compensating a completed process
	> >  instance is undefined.
	> >
	> >  Uncertainty 2: how long a process instance remains
	> >  "compensatable" is undefined. It should be natural to expect
	> >  that after some time the data of a completed process is
	> >  removed from the system (to save disk space, etc). Thereafter
	> >  compensation cannot be performed.
	> >
	> >Rationale 2: There already is an easier and clearer way of
	> >achieving the same effect without incurring the uncertainties
	> >described in Rationale 1. By cofiguring a process as follows,
	> >you can clearly express:
	> >  * how to initiate compensation of the process "body", and
	> >  * the deadline of initiating compensation after the completion
	> >    of the process "body".
	> >
	> >  <process>
	> >    <eventHandlers>
	> >      if a certain message is received, compensate.
	> >    </eventHandlers>
	> >    <sequence>
	> >      <scope>
	> >       ... compensation handler ...
	> >       ... the "body" of the process ...
	> >      </scope>
	> >      <wait ... until some desired time ... />
	> >    </sequence>
	> >  </process>
	> >
	> >Merits:
	> >* Clearer and more flexible semantics.
	> >* An execution engine can immediately remove data for a
	> >  completed process instance.
	> >
	> >I would love to hear your comments.
	> >
	> >Yuzo Fujishima
	> >NEC Corporation
	> >
	> >
	> >---------------------------------------------------------------------
	> >To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
	> >For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
	> > 
	> >
	>
	>
	>
	> ---------------------------------------------------------------------
	> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
	> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
	>
	>
	
	---------------------------------------------------------------------
	To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
	For additional commands, e-mail: wsbpel-help@lists.oasis-open.org