[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications(withOUT change log)]
Hi everyone,
nearly back in the game over here ;) antibiotics rule.
Satish's explanation is my understanding as well.
I have also taken a stab at Yaron's request of reworking the text into
specy language, and tried to address the various concerns/comments with
the help of Peter and others.
In the interet of time, I will send the draft to the list so we can
continue the discussion. I don't get the feeling there are big stumbling
blocks at this point and hope (yet again!) that we can move to close soon.
Regards,
Rania
Diane Jordan wrote:
>
> 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]