RE: [wsbpel-abstract] Potential requirements and use case

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

Monica,

Regarding your suggestion to maintain an explicit abstract/executable
distinction, probably using the current process-level attribute, I agree
with you.

I don't quite understand what you mean by "statically verifiable set of
conditions to specify when a process model is ready to execute".  I
would hope that abstractProcess="no" and the schema for executable
processes plus simple static checks that we already have in the text
which we should gather in a list (issue 84) should be sufficient.  Did
you have something else in mind?

Satish

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Thursday, July 22, 2004 3:35 PM
To: Satish Thatte
Cc: wsbpel-abstract@lists.oasis-open.org; Ron Ten-Hove
Subject: Re: [wsbpel-abstract] Potential requirements and use case

Satish: We'd provide some additional suggestions:

    * If an abstract process contains opaque elements or activities,
      they must be elaborated.
          o Make explicit the semantics surrounding opaque if accepted.
[1]
    * Ensure we can specify a process is abstract or executable
      irrespective of whether opaque is used. [2]
    * Suggest we define a statically verifiable set of conditions to
      specify when a process model is ready to execute.
    * Ban extensions from affecting 'ready to execute.' [3] This is
      inline with current specification that bans extensions affecting
      BPEL semantics.

[1] In order to provide a guide for developers and allow other 
computational or conformance capabilities to be used on top of the 
abstract process.
[2] The condition may occur that opaque activities may have not been 
explicitly added yet, but you wish to ensure that someone doesn't try to

execute an incomplete process.  We currently have 
abstractProcess="yes|no"? under Process. Is this sufficient?

Thanks.

>Thatte: I think we are agreeing on a few things
>
>1. abstract BPEL allows partial specification of executable processes.
>
>2. we need a precise definition of conformance between a partial
process and any executable process that claims to be its completion
>
>3. We do not want to preclude any use case for abstract processes,
including 
>
>a. A notation for specifying the externally visible behavior of a web
service or a collection of web services where the notation may be used
with various degrees of austerity as appropriate for the needs of the
specifier,
>
>b. A notation for exchange of process requirements across autonomous
entities where the abstract and the executable process are NOT "owned"
by the same entity, and
>
>c. A notation for partial specification in a modeling context where the
abstract and the executable process ARE "owned" by the same entity.
>
>4.  <opaque> activities and expressions are primarily intended as a
proposal for allowing the designer of an abstract process to express
his/her intentions regarding mandatory points of extension.  The purpose
of <opaque> is NOT to specify all allowable points of extension,
prohibiting all other potential points of extension in the completion of
an abstract process.  Secondarily, <opaque> activities and expressions
serve as a convenience for technical specification and validation using
a single schema.
>
>I would argue that the technical convenience argument for <opaque> is a
weak one because the syntactically mandated completion points can be
easily found by tools and forcing an abstract process designer to
explicitly design them in helps tools and BPEL specification writers at
the expense of the users of abstract BPEL, i.e., those who read and
write instances of abstract BPEL.  This is especially the case for use
case (a) above where brevity and readability are likely to be very
important.
>
>I believe the primary intention of the <opaque> proposal as a mechanism
for expressing the intention for mandatory extension applies primarily
to use case (c) and as such I would argue that it belongs more in the
realm of a tools oriented extension rather than an essential aspect of
abstract BPEL.  
>
>Satish
>  
>