RE: [wsbpel] New issue - ASSERT activity.

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

Maciej,

I think you are arguing that my macro simulation is in fact not the real
story you want to tell.  If it were the real story, and we had issues
with "to terminate or throw" and such, then I would argue strongly
against adding such a feature.  If it is an invariant that in some sense
is introducing abstract (contract-like) semantics into *all* BPEL
processes, then this is different and I would need to think more about
it.

Satish

-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com] 
Sent: Thursday, March 18, 2004 11:35 AM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] New issue - ASSERT activity.

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]