[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 106 - ASSERT activity.
OK, this helps. Side question: why is it more useful to think of pre/post conditions as opposed to just assertions at certain points in the process? Also it would help to have an example or two. -----Original Message----- From: Maciej Szefler [mailto:firstname.lastname@example.org] Sent: Thursday, March 18, 2004 3:29 PM To: Satish Thatte; email@example.com Cc: Furniss, Peter Subject: Re: [wsbpel] Issue - 106 - ASSERT activity. The story I'm after is more along the lines of expressing an abstract contract, certainly my intent was not to propose a mechanism to express run-time behavior. In retrospect, I should have not included the references to termination semantics; what "happens" in terms of run-time behavior if an invariant is violated is almost irrelevant: a process that has such a violation is not valid (or in bizarro-world the process is valid but the BPEL implementation is not). I'm not opposed to leaving the consequences of assertion violations in the netherworld of implementation-dependent behavior which might make the contract-orientation a bit more obvious. Also I noticed that I had a Freudian slip with the subject line "ASSERT activity", which actually materially misrepresents the proposal ("Activity Assertions" would be better). My apologies to Peter for cross-posting the new issue to the list, it seems I could not limit my careless to the subject line alone. -maciej On Thu, 18 Mar 2004 12:42:38 -0800, Satish Thatte <firstname.lastname@example.org> wrote: > 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:email@example.com] > Sent: Thursday, March 18, 2004 11:35 AM > To: Satish Thatte; firstname.lastname@example.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 > <email@example.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:firstname.lastname@example.org] >> Sent: Wednesday, March 17, 2004 4:17 PM >> To: email@example.com; firstname.lastname@example.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]