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 <>
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:]
> Sent: Wednesday, March 17, 2004 4:17 PM
> To: ;
> 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]
