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] 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]