[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] New issue - ASSERT activity.
More thoughts ... In the classical "program by contract" semantics, pre-condition and post-condition is a contract offered by the callee to the caller. If the call is fulfilling pre-condition, then the callee is obliged to process the call and by the end guarantee that post-condition is fulfilled. The key point I want to make here is this is a "contractual aspect" which is an interface, "non-executable". How to enforce this "contract" is an "implementation issue" (executable) of the callee side. Typically, the checking of pre-condition is done by the callee, which throw an exception when the checking fails. Before the callee return, it will also check the post-condition to make sure it fulfills the contract. By seeing your example, I'm not sure this is what you mean. In your case, the process is the caller and the activity is the callee. But quite different from the typical implementation, the checking is all done at the "caller", not "callee". It sounds like the caller just want to make sure it is at certain state before making a call as well as after making a call. If this is your intention (which is quite different from the classical "program by contract" model), then all you need to provide a mechanism to check the process state at any given point in time, there is no need to have <assert> associated with any other <activity>. It may be conceptually simpler if <assert> itself is just a basic activity (similar to <assign>) which can be put anywhere in the process. The execution of this activity is equivalent to <switch> <case condition="condition-xpath-expression"> <throw faultName="AssertionFailure"/> </case> </switch> Thoughts ?? Rgds, Ricky >-----Original Message----- >From: Maciej Szefler [mailto:mbs@fivesight.com] >Sent: Wednesday, March 17, 2004 4:17 PM >To: peter.furniss@choreology.com; wsbpel@lists.oasis-open.org >Subject: [wsbpel] New issue - ASSERT activity. > > >I'd like to propose the addition of an assertion facility to the BPEL >language. Specifically I'd like to see <precondition> and ><postcondition> >elements added to the list of standard elements, something along the >lines >the <any-activity> > <precondition> > <expression language="XPath"> > some-xpath-expression > </expression> > </precondition> > <postcondition> > <expression language="XPath"> > some-xpath-expression > </expression> > </postcondition> > > .... > > </any-activity> > >Interpetation of the <pre-/post-condition> elements would be optional, >but >if assertions are enabled the expressions must evaluate to "true" or >else >the process instance is immediately terminated (ala <terminate>). >Assertions would be available to both executable and abstract processes. > >-standard argument for assertions goes here-. > >-maciej > >-- >Maciej Szefler [mbs(a)fivesight.com] [+1-312-432-0556x226] > >To unsubscribe from this mailing list (and be removed from the roster of >the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr >oup.php. > > >To unsubscribe from this mailing list (and be removed from the roster of >the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]