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

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

Is the real issue that we want a way to define a meaningful set of 
syntactic rules for abstract processes and that the text is attempting 
to do that by defining a series of rules for transforming an abstract 
process into an executable process and then saying "Look, if you can't 
successfully apply these rules to your abstract process instance then 
your abstract process instance is syntactically invalid?"

	Yaron (the confused)


Satish Thatte wrote:
> I think the real point is that the constructs used in abstract processes
> derive their semantics from the semantics of executable processes.
> Completion is simply one way in which this semantics is realized.
> 
> -----Original Message-----
> From: Rania Khalaf [mailto:rkhalaf@watson.ibm.com]
> Sent: Wednesday, February 16, 2005 7:30 AM
> To: ygoland@bea.com
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting
> clarifications (withOUT change log)]
> 
> Hi Yaron,
> 
> Yaron Y. Goland wrote:
>  > 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.
>  >
> 
> How about :
> "The semantics of an abstract process are therefore derived from the
> range of executable BPEL processes that a particular abstract process
> represents."
> 
> This removes the directionality while maintaining the concept.
> 
>  > "One or two profile(s) will be given in the specification. " - Which
> is it?
>  >
> 
> Whether it will be one or two profiles was intentionally left open as
> part of 82. We propose that a new issue be created to handle 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.
> 
> see note at the end
> 
>  >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.
>  >
> 
> The answer to this will come out of issue 107
> 
>  > 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.
> 
> Looking into draft of spec to see where changes would occur, while
> making no assumptions about dependent specs other than putting
> place-holders.
> 
> Regards,
> Rania
> 
>  >
>  >     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_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_workgr
> oup.php.
>