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.


Since you mention Eiffel and Java, my understanding in a classical 
implementation is like the following ...  funcA is the caller and funcB is 
the callee.

funcA() {
         try {
                 funcB();
         } catch (AssertionException e) {
                 System.exit();
         }
}

funcB() throws AssertionException {
         assert pre-condition;
         // doStuff;
         assert post-condition;
}

This is very different from what you want, whch is the following ... (note 
the assertion call has been moved)

funcA() {
         try {
                 assert pre-condition;
                 funcB();
                 assert post-condition;
         } catch (AssertionException e) {
                 System.exit();
         }
}

funcB() throws AssertionException {
         // doStuff;
}


If you look into that, the assertion is NOT a contract between funcA and 
funcB.  It is purely an implementation detail of funcA (who just want to 
check its own state at some stage) which doesn't need to be shared with 
funcB at all.  Therefore, I argue that assert itself is an activity rather 
than attached to another activity.

I fully agree the importance of "program by contract" and pre-condition / 
post-condition declaration.  But I think this concept belongs to the WSDL 
rather than BPEL.

Best regards,
Ricky

At 01:35 PM 3/18/2004 -0600, Maciej Szefler wrote:
>The main point is that an assertion would in no way change the structure 
>of the process. Assertions would be "out-of-band" statemements about the 
>expected behavior of a process (like the Java "assert" or Eiffel 
>"invariant"/"require"/"ensure" keywords). So the switch/case/terminate 
>usage is inadequate not because it cannot simulate (roughly speaking) the 
>semantics of assertions, but because it fails to express the intent of the 
>assertion.
>
>I would object to having the assertions throw faults of any sort: the 
>purpose of assertions is not to impact control flow, but rather to detect 
>serious errors (violations of asserted invariants) in the process or the 
>BPEL engine implementation. I understand that other languages (including 
>both Java and Eiffel) throw exceptions/errors if an pre/post/invariant is 
>violated; however, in the context of a high-level and fundamentally 
>concurrent language like BPEL, practicality of handling an assertion 
>violation is questionable.
>
>As for abstract processes, assertions would only increase their expressive 
>power. With assertions in abstract processed one could for example express 
>that not only will a response be returned, but that the response message 
>will contain a certain number of records.
>
>Now as for the argument that assertions are un-necessary because they can 
>be simulated. I disagree completely. Sequence can be simulated with flow 
>and yet we have sequence. If anything the argument for assertions is 
>stronger than that for sequence: assertions provide an entirely different 
>class of functionality (invariant checking) where sequenece provides a 
>redundant mechanism in the class of "control-flow" constructs. Also this 
>ignores the value of assertions in abstract processes where they cannot be 
>"simulated".
>
>I should also point out, that adding assertions would be very 
>"low-impact": assertions could be left un-implemented by a BPEL 
>implementation (simply by ignoring the pre-/post-condition elements) 
>without at all affecting the execution of a (valid) process.
>
>I maintain that an assertion facility would be invaluable to those 
>interested in developing BPEL conformance test-cases, serve as an 
>extremely useful debugging facility, and provide a superior method of 
>communicating the "process contract" in abstract processes.
>
>-maciej
>
>
>On Thu, 18 Mar 2004 09:34:39 -0800, Satish Thatte <satisht@microsoft.com> 
>wrote:
>
>>Am I correct in understanding that this is a macro for (using the old
>>syntax)
>>
>><switch>
>>    <case condition="precondition-xpath-expression">
>>        <terminate/>
>>    </case>
>></switch
>><any-activity>
>><switch>
>>    <case condition="postcondition-xpath-expression">
>>        <terminate/>
>>    </case>
>></switch>
>>
>>Or did you have something else in mind?  How would you interpret the
>>pre/post conditions in abstract processes?
>>
>>Satish
>>
>>-----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
>>of:
>>   <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_workgroup.php.
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]