OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]