RE: [wsbpel] Issue - 106 - ASSERT activity.

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

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:mbs@fivesight.com] 
Sent: Thursday, March 18, 2004 3:29 PM
To: Satish Thatte; wsbpel@lists.oasis-open.org
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
<satisht@microsoft.com> 
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: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]