Re: [wsbpel] New issue - ASSERT activity.

["David RR Webber" <david@drrw.info>]

Satish,

In this vein - still awaiting comments back on the BPEL / CAM binding and
use cases for transaction validation and construction.

I may have got this perfectly correct of course - but somehow I suspect
there's nuances on the BPEL side that need to be captured in the
functional requirements before we are ready to cut the XML to
implement the binding...

Thanks, DW

----- Original Message ----- 
From: "Satish Thatte" <satisht@microsoft.com>
To: "Chris Keller" <chris.keller@active-endpoints.com>;
<wsbpel@lists.oasis-open.org>
Cc: "Maciej Szefler" <mbs@fivesight.com>
Sent: Thursday, March 18, 2004 1:50 PM
Subject: RE: [wsbpel] New issue - ASSERT activity.


Chris,

I agree with you completely.  BPEL is not, and in my opinion should not
be extended to become, a full blown implementation language.

Satish

-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com]
Sent: Thursday, March 18, 2004 10:41 AM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Cc: 'Maciej Szefler'
Subject: RE: [wsbpel] New issue - ASSERT activity.

Satish,

I can't speak for Maciej, but it sounds like the correct interpretation.
And I have no idea how an abstract process should interpret the
assertions as assertions are runtime constructs.  But to quote Yaron, "A
specification is complete when there is nothing left to cut."  Given
that you can already do it (with the exception of easily turning it off
without changing your process) and more flexibly like choosing terminate
or throw.  I vote -1 on adding an assertion facility in this version of
the specification and let people use code like your example to perform
assertions.

Chris

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Thursday, March 18, 2004 12:35 PM
To: Maciej Szefler; peter.furniss@choreology.com;
wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] New issue - ASSERT activity.

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]

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.





To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.