| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Fw: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications (withOUTchange log)]
- From: Diane Jordan <firstname.lastname@example.org>
- To: email@example.com
- Date: Fri, 4 Mar 2005 08:32:38 -0500
I've heard from Rania that she has the
flu and is traveling. She hopes to be able to get back to us in the
next couple days.
IBM Emerging Internet Software Standards
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709
----- Forwarded by Diane
Jordan/Raleigh/IBM on 03/04/2005 08:31 AM -----
03/04/2005 04:43 AM
|RE: [Fwd: Re: [wsbpel] Issue
82 - Adding requesting clarifications (withOUT change log)]|
There are actually two things going on I think. Rania,
me if needed.
1. Stating the obvious: since abstract process syntax is a superset
executable process syntax, but abstract processes are not directly
executable, the "interpretation" of the non-opaque constructs
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).
From: Yaron Y. Goland [mailto:firstname.lastname@example.org]
Sent: Thursday, March 03, 2005 11:51 AM
To: Satish Thatte
Cc: Rania Khalaf; email@example.com
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
> 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:firstname.lastname@example.org]
> Sent: Wednesday, February 16, 2005 7:30 AM
> To: email@example.com
> Cc: firstname.lastname@example.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
> > processes to which it would be mapped." confused me
as it would
> > that all abstract processes MUST be mapped to an executable
> > I was unaware of us ever wishing to imply that? Is the
> > of an abstract process to create an executable process?
> > distinction with point 4 at the end of the proposal which
> > it must be possible to create an executable process through
> > undefined mechanism. But that is different than implying
> > goal always is an executable process.
> How about :
> "The semantics of an abstract process are therefore derived from
> range of executable BPEL processes that a particular abstract process
> This removes the directionality while maintaining the concept.
> > "One or two profile(s) will be given in the specification.
> is it?
> Whether it will be one or two profiles was intentionally left open
> 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
> > 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
> > how they work, do you intend to resolve the dependent issue
> > 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
> > ready to be included in the spec or reasonably close. That
> > way we can make sure that all the edge cases have been
> > with. Otherwise the editors will end up having to find
> > 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
> > proposal. My comments are therefore restricted to encouraging
> > 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
> > Thanks,
> > Yaron
> > Rania Khalaf wrote:
> >> Hi,
> >> here is the text with proposed updates incorporated
> >> highlighting of changes.
> >> -----------
> >> Proposal for Issue 82:
> >> NOTE: Ambiguities should be limited/focus on non-substantive
> >> to the accepted concept, i.e. editorial comment, further
> >> that do not change the substance of the accepted proposal
> >> dated 12/15/2004.
> >> Abstract BPEL definition:
> >> A BPEL abstract process is a partially specified
process that is
> >> intended to be executed. Executable and abstract BPEL
> >> the same expressive power, while the latter allows
> >> that are capable of abstracting away operational details
> >> through omission or explicit opacity. Whereas
> >> are fully concretized and thus can be executed, an
> >> may lack some of the required concrete operational
> >> by a fully executable artifact. An abstract BPEL process
> >> explicitly declared as 'abstract'.
> >> Abstract processes serve a descriptive role, with more
> >> possible purpose. One such purpose for an abstract
> >> define the publicly visible behavior of some or all
> >> offers ("myRole" in its partnerLinks), which
may include its
> >> interactions along its partnerLinks with other services.
> >> purpose could be to define a process "template"
> >> domain-specific best practices, encoded in a platform-neutral
> >> portable way by both enterprises and vertical standards
> >> For example, a process "template" could capture
> >> logic while leaving out operational details that will
> >> when mapping the partial process specification to a
> >> artifact.
> >> The different uses of abstract BPEL require different
> >> opacity and restrictions or relaxations on which elements
> >> corresponding executable artifact are omitted or hidden.
> >> enable different usages of abstract processes, an extensible
> >> 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
> >> definition, "usage profiles" can be defined.
The semantics of an
> >> abstract process are therefore derived from those of
> >> processes to which it would be mapped.
> >> To define these semantics, the range of corresponding
> >> processes can be constrained by a usage profile, placing
> >> on what is opaque or omitted. An abstract process
> >> usage profile that defines its meaning. The profile
> >> using a URI. Where profiles are defined is left unspecified.
> >> The base is simply a set of minimum requirements for
> >> processes. Profiles are created from the base. One
> >> 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
> >> defined URI.
> >> It is left open whether another profile will be defined
> >> specification that is identical to the base. If so,
it will be
> >> URI to identify it and added. It is suggested that
a separate, new
> >> issue XX be opened for this. The dependency (by allowed
> >> of these three issues is: 82, XX, 158.
> >> The placement of these profiles and other questions
> >> structure of the ultimate specification and how many
> >> will be will be left open and dealt with as part of
158] . Issue
> >> cannot be closed until 82 is closed.
> >> Semantics of Abstract Processes:
> >>  Although it might contain
complete information that
> >> render it executable as specified for executable BPEL,
> >> status states that any concrete realizations of it
> >> additional processing steps that are not relevant to
> >> which it has been given. The minimum criteria for an
> >> is defined in this specification while completeness
is left to the
> >> usage profile a particular abstract process definition
> >>  Abstract processes permit
the use of all of the
> >> executable processes. Thus there is no fundamental
> >> distinction between abstract and executable processes.
> >>  An abstract process may omit
operational details that
> >> mandatory for BPEL executable processes through the
> >> entities of various types (i.e. elements, attributes,
> >> the omission of specific BPEL elements or attributes
> >> to be implicitly opaque. This omission is treated as
> >> shortcut equivalent to the attribute or expression
being in the
> >> omitted location with an opaque value.
> >> The semantics and consistency
constraints of executable BPEL
> >> clearly defined. The semantics of each language construct
> >> abstract process are always derived from that of the
> >> executable BPEL. (i.e. an invoke is always an invoke).
> >> The difference is strictly a consequence
of the opacity used
> >> that construct (missing information) and other parts
> >> affected by it ( For example, opacity in a link source
> >> affect the link target element).
> >> Additionally, an abstract process
is required to be
> >> valid using the BPEL schema, that accommodates extension
> >> and omissions as detailed in bullet 3 above. One schema
> >> abstract and executable BPEL. (Check that this is consistent
> >> resolution of 24).
> >>  In this base definition, to
avoid absurd constructs and
> >> clarify opacity, the minimial requirement is that for
> >> process, there exists at least one syntactic completion
> >> *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
> >> process not for process semantics.
> >>  For this base definition,
there are no requirements on
> >> concretized, executable realizations of abstract process
> >> implemented (ie: language, platform, etc) (c.f. analogy
> >> are specific relationships with such realizations specified.
> >>  Abstract processes are *incomplete*
> >> definition, whether or not they contain opaque entities.
> >> semantics of the non-opaque constructs they contain
> >> understood in isolation from the relationship of the
> >> with the executable *completions* that are permitted
> >> the abstract process references.
> >> The reason being that the semantics
of those constructs
> >> exists only in the possible executable completions.
As an edge
> >> permitted completion may sometimes be identical to
> >> process syntactically, but this is the exception rather
> >> __
> >> To unsubscribe from this mailing list (and be removed
> >> of the OASIS TC), go to
> > To unsubscribe from this mailing list (and be removed from
> > the OASIS TC), go to
> To unsubscribe from this mailing list (and be removed from the roster
> the OASIS TC), go to
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]