[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications(withOUT change log)]
> How about : > "The semantics of an abstract process are therefore derived from the > range of executable BPEL processes that a particular abstract process > represents." But this still requires the reader to draw the conclusion that an abstract process represents some kind of executable BPEL process. I think that is too strong a connection to draw. Especially since an abstract process may be specified that has no relation to any executable BPEL process that has or ever will exist. Yaron Rania Khalaf wrote: > 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_workgroup.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_workgroup.php. > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]