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