[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]