[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications (withOUT change log)]
There are actually two things going on I think. Rania, please correct
me if needed.
1. Stating the obvious: since abstract process syntax is a superset of
executable process syntax, but abstract processes are not directly
executable, the "interpretation" of the non-opaque constructs used must
be by association, i.e., the same as in executable processes.
2. At the purely syntactic level, avoiding egregiously bad use of
opaque constructs by stating the constraint that the process must be
completable, which does not actually require any complex rules for
completion, just "replace opaque tokens with syntactically appropriate
non-opaque ones". Which basically is a way to apply the existing
non-schema static syntactic constraints to abstract processes (e.g., the
standard rules for omitting attributes in fault handlers).
This is all independent of profiles. The profiles may apply significant
constraints on allowed completions (e.g., must not add new interactions
along existing partnerLinks) or on the syntax of compliant abstract
processes (e.g., must not have more than one partnerLink).
Satish
-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Thursday, March 03, 2005 11:51 AM
To: Satish Thatte
Cc: Rania Khalaf; wsbpel@lists.oasis-open.org
Subject: Re: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting
clarifications (withOUT change log)]
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.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]