wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fw: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications (withOUTchange log)]
- From: Diane Jordan <drj@us.ibm.com>
- To: wsbpel@lists.oasis-open.org
- 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.
Regards, Diane
IBM Emerging Internet Software Standards
drj@us.ibm.com
(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 -----
"Satish Thatte"
<satisht@microsoft.com>
03/04/2005 04:43 AM
|
To
| <ygoland@bea.com>
|
cc
| "Rania Khalaf"
<rkhalaf@watson.ibm.com>, <wsbpel@lists.oasis-open.org>
|
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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]