Re: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications(withOUT change log)]

["Yaron Y. Goland" <ygoland@bea.com>]

Then sentence "The semantics of an
abstract process are therefore derived from those of the executable
processes to which it would be mapped." confused me as it would imply 
that all abstract processes MUST be mapped to an executable process. But 
I was unaware of us ever wishing to imply that? Is the only possible use 
of an abstract process to create an executable process? I would draw a 
distinction with point 4 at the end of the proposal which just says that 
it must be possible to create an executable process through some fairly 
undefined mechanism. But that is different than implying that the end 
goal always is an executable process.

"One or two profile(s) will be given in the specification. " - Which is it?

"[The TC will rework the 1.1 AP definition into a profile with a
defined URI." - This sentence seems incomplete

The proposal itself is still not in a form that is readily include-able 
in the spec. The list of features of abstract processes is both 
incomplete (for example point 3 refers to opaque values without defining 
how they work, do you intend to resolve the dependent issue first?) and 
not in spec form.

I would expect that the final proposal would be in a form that is either 
ready to be included in the spec or reasonably close. That is the only 
way we can make sure that all the edge cases have been properly dealt 
with. Otherwise the editors will end up having to find those edge cases 
themselves and then file new issues. But it is not the job of the 
editing team to debug proposals.

Nevertheless I am happy with the over all design and direction of the 
proposal. My comments are therefore restricted to encouraging that the 
proposal be completed so we can vote on it.

	Thanks,

		Yaron


Rania Khalaf wrote:
> Hi,
> 
> here is the text with proposed updates incorporated and no
> highlighting of changes.
> -----------
> 
> Proposal for Issue 82:
> 
> NOTE: Ambiguities should be limited/focus on non-substantive changes
> to the accepted concept, i.e. editorial comment, further clarification
> that do not change the substance of the accepted proposal from Peter
> dated 12/15/2004.
> 
> 
> Abstract BPEL definition:
> 
>   A BPEL abstract process is a partially specified process that is not
> intended to be executed. Executable and abstract BPEL processes share
> the same expressive power, while the latter allows process definitions
> that are capable of abstracting away operational details _ either
> through omission or explicit opacity.  Whereas executable processes
> are fully concretized and thus can be executed, an abstract process
> may lack some of the required concrete operational details expressed
> by a fully executable artifact. An abstract BPEL process must be
> explicitly declared as 'abstract'.
> 
> Abstract processes serve a descriptive role, with more than one
> possible purpose. One such purpose for an abstract process could be to
> define the publicly visible behavior of some or all of the services it
> offers ("myRole" in its partnerLinks), which may include its
> interactions along its partnerLinks with other services.  Another
> purpose could be to define a process "template" embodying
> domain-specific best practices, encoded in a platform-neutral and
> portable way by both enterprises and vertical standards organizations.
> For example, a process "template" could capture some essential process
> logic while leaving out operational details that will be concretized
> when mapping the partial process specification to a fully executable
> artifact.
> 
> The different uses of abstract BPEL require different levels of
> opacity and restrictions or relaxations on which elements of a
> corresponding executable artifact are omitted or hidden.  To cleanly
> enable different usages of abstract processes, an extensible approach
> is taken using a set of basic, minimal requirements (base) for all
> abstract processes.
> 
> The abstract process base definition lacks well-defined
> semantics. Conversely, executable processes have well-defined
> semantics and prescribed behavior. From the abstract process base
> definition, "usage profiles" can be defined. The semantics of an
> abstract process are therefore derived from those of the executable
> processes to which it would be mapped.
> 
> To define these semantics, the range of corresponding executable
> processes can be constrained by a usage profile, placing constraints
> on what is opaque or omitted.  An abstract process MUST identify the
> usage profile that defines its meaning.  The profile is identified
> using a URI. Where profiles are defined is left unspecified.
> 
> The base is simply a set of minimum requirements for all abstract
> processes. Profiles are created from the base. One or two profile(s)
> will be given in the specification. They/it will show how one can
> create a profile by building on the base.
> 
> [The TC will rework the 1.1 AP definition into a profile with a
> defined URI.
> 
> It is left open whether another profile will be defined in the
> specification that is identical to the base. If so, it will be given a
> URI to identify it and added. It is suggested that a separate, new
> issue XX be opened for this. The dependency (by allowed closing order)
> of these three issues is: 82, XX, 158.
> 
> The placement of these profiles and other questions concerning the
> structure of the ultimate specification and how many documents there
> will be will be left open and dealt with as part of 158] . Issue 158
> cannot be closed until 82 is closed.
> 
>        Semantics of Abstract Processes:
> 
>       [1] Although it might contain complete information that would
> render it executable as specified for executable BPEL, its abstract
> status states that any concrete realizations of it may perform
> additional processing steps that are not relevant to the audience to
> which it has been given. The minimum criteria for an abstract process
> is defined in this specification while completeness is left to the
> usage profile a particular abstract process definition belongs to.
> 
>       [2] Abstract processes permit the use of all of the constructs of
> executable processes. Thus there is no fundamental expressive power
> distinction between abstract and executable processes.
> 
>       [3] An abstract process may omit operational details that are
> mandatory for BPEL executable processes through the use of "opaque"
> entities of various types (i.e. elements, attributes, etc.) or through
> the omission of specific BPEL elements or attributes that are allowed
> to be implicitly opaque. This omission is treated as a syntactic
> shortcut equivalent to the attribute or expression being in the
> omitted location with an opaque value.
> 
>       The semantics and consistency constraints of executable BPEL are
> clearly defined. The semantics of each language construct in an
> abstract process are always derived from that of the same construct in
> executable BPEL. (i.e. an invoke is always an invoke).
> 
>       The difference is strictly a consequence of the opacity used in
> that construct (missing information) and other parts of the process
> affected by it ( For example, opacity in a link source element may
> affect the link target element).
> 
> 
>       Additionally, an abstract process is required to be syntactically
> valid using the BPEL schema, that accommodates extension with opacity
> and omissions as detailed in bullet 3 above. One schema exists for
> abstract and executable BPEL. (Check that this is consistent with
> resolution of 24).
> 
>       [4] In this base definition, to avoid absurd constructs and to
> clarify opacity, the minimial requirement is that for any abstract
> process, there exists at least one syntactic completion that yields a
> *valid executable process* by
> 
>           a) replacing each opaque token by a concrete entity or
> removing the opaque token completely, and
> 
>           b) adding new BPEL XML elements anywhere in the process.
> 
> 
> This is used for checking the syntactic validity of an abstract
> process not for process semantics.
> 
>       [5] For this base definition, there are no requirements on how
> concretized, executable realizations of abstract process should be
> implemented (ie: language, platform, etc) (c.f. analogy to WSDL); nor
> are specific relationships with such realizations specified.
> 
>       [6] Abstract processes are *incomplete* and non-executable by
> definition, whether or not they contain opaque entities. Therefore the
> semantics of the non-opaque constructs they contain cannot be
> understood in isolation from the relationship of the abstract process
> with the executable *completions* that are permitted by the profile
> the abstract process references.
> 
>       The reason being that the semantics of those constructs actually
> exists only in the possible executable completions. As an edge case, a
> permitted completion may sometimes be identical to the abstract
> process syntactically, but this is the exception rather than the rule.
> 
>       __
> 
> 
> 
> 
> 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.
>