[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Removing "compensating a process as a whole"
+1. Satish, It would be very useful to have a session focused on compensation, scope state and WS-C/WS-T. We talked about that at the F2F and in the following email exchanges. Edwin > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Friday, June 20, 2003 8:48 AM > To: Yuzo Fujishima; Assaf Arkin > Cc: wsbpel@lists.oasis-open.org > > 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]