Subject: Re: [wsbpel] Issue 82 - Closer to spec wording.
Hi everyone, Here is where spec wording on 82 is at the moment. This was created by taking the text from the final revision of 82, grouping sections and tweaking others to get a coherent continuous description. I tried to comment the sources of some of the sections. In the interest of time, I am sending this to the main list for review and comments. regards, Rania ----- Abstract Processes. Major Diffs in Spec. 1. Introduction ---------------- •Move from Intro and use as input to AP1.1 refactoring section: -last four sentences of second paragraph. The third paragraph. •Reword: - Fourth paragraph to : “What are the concepts required to describe business processes? To answer these questions, consider the following”. - Substitute “Business Protocols” with “Business processes” in the bullets of this paragraph. •Move from Intro, and use as input to AP1.1 refactoring section: -“if we wish to provide …. to capture the essence of public behavior while hiding private aspects.” •Delete: -“A WS-BPEL process can define a business protocol role, using the notion of abstract process…. In addition abstract processes use nondeterministic data values to hide private aspects of behavior”. •Add (right before “The basic concepts of WS-BPEL can be applied in one of two ways …”): (From first section of Peter’s text, with minor changes). It is also possible to use ‘abstract’ WS-BPEL processes. A BPEL abstract process is a partially specified process that is not intended to be executed and that must be explicitly declared as ‘abstract’. Whereas executable processes are fully concretized and thus can be executed, an abstract process may abstract away some of the required concrete operational details expressed by a fully executable artifact. All the constructs of executables processes are made available to abstract processes; consequently, executable and abstract BPEL processes share the same expressive power. In addition to the features available in executable processes, abstract processes provide two mechanisms for abstracting away operational details: (1)omission and (2)the use of explicit opaque tokens. Although a particular abstract process definition might contain complete information that would render it executable if interpreted as an executable process, its abstract status states that any concrete realizations of it are permitted to perform additional processing steps that are not relevant to the audience to which it has been given. Abstract processes serve a descriptive role, with more than one possible use case. One such use case for an abstract process might be to describe the publicly visible behavior of some or all of the services an executable process offers (represented by "myRole" in the relevant partnerLinks). Another use case might be to define a process "template" embodying domain-specific best practices. For example, such 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. Regardless of the purpose, all abstract processes share a common syntactic base. However, they actually have different, possibly conflicting, requirements for the levels of opacity and restrictions or relaxations on which parts of a process definition may be omitted or hidden, i.e. the overall level of incompleteness. Hence, different uses of abstract processes have different effects on the consistency constraints required in executable processes, and on the semantics of that process. In order to address this flexibility, a ‘base-and-profiles’ approach is provided in section 15 for defining abstract processes. A common base specifies the features that define the syntactic universe of abstract processes. However, the base lacks well-defined semantics. Given this common base, a usage profile provides the necessary specializations and the semantics based on executable BPEL for a particular usage area of an abstract process. For example, one profile might focus on publicly visible behavior; another profile might focus on process templates of particular granularity. • Substitute “business protocols” with “abstract processes” in the paragraph starting with “Even when …” • Reword: -Sentence starting with “In summary, …” -to “In summary, we believe that abstract business processes and executable business process descriptions require a common core of process description concepts.” 6.2. The Structure of a Business Process ----------------------------------------- •Add to structure (xml) at top level: abstractProcessProfile=”anyURI”? •Add to bullets “the top-level attributes are as follows”: -abstractProcessProfile: This attribute provides the URI that identifies the profile of an abstract process. It MUST be used if abstractProcess=”yes”. 8.1.1 Motivation for Message Properties ---------------------------------------- Message properties are defined here in a sufficiently general way to cover message context consisting of implicit parts, but the use in this specification focuses on properties embedded in application-visible data that is used in abstract business processes. 9. Data Handling ------------------ • Replace second paragraph with: Executable processes are permitted to use the full power of data selection and assignment but are not permitted to use opaque values. Abstract processes, on the other hand, are permitted to hide behavior. Detailed differences are specified in the following sections. 14. Extensions for Executable Processes ---------------------------------------- • Refactoring of this section waits on 158. Either way, 14.1, 14.3 and 14.6 move to relevant sections in main part of spec so that constructs in abstract are superset of those in executable BPEL. •Replace old section 15 with: ------------------------------ 15. BPEL Abstract Processes --------------------------- Abstract processes have multiple usage areas. Consequently, a base and profiles approach is provided for defining abstract processes. The common base, defined in section 15.1, specifies the features that define the syntactic universe of abstract processes. However, the base lacks well-defined semantics. Given this common base, a usage profile provides the necessary specializations and the semantics based on executable BPEL for a particular usage area of an abstract process. Nevertheless, every abstract process MUST identify the usage profile that defines its meaning. A profile is identified using a URI. This approach is extensible: new profiles can be defined as different areas are identified. Where these profiles can be defined is unspecified. Profiles are created from the base and their characteristics are defined in section 15.2. [One/two ] profile[s] will be provided in the specification. [They/it] will show how one can create a profile by building on the base. 15.1 The Common Base: The common base is simply the *syntactic form* that all BPEL abstract processes must conform to. The level of completeness, among other things, is specified in the usage profile for a particular abstract process definition. [from Peter’s 1] The syntactic characteristics of the base are: •The abstractProcess attribute MUST explicitly be set to “yes”. •(Peter ) All the constructs of executable process are permitted. Thus, there is no fundamental expressive power distinction between abstract and executable processes. •(Peter ) Operational details that are mandatory for BPEL executable processes may be omitted through the use of "opaque" entities of various types (i.e. elements, attributes, etc.) or through the omission of specific BPEL constructs. -Therefore, the following extensions are made to the syntax of executable BPEL, to allow the following opaque entities: [***Expected from 107 ***] -Omission of all syntactically *required* attributes and expressions is allowed, as long as the omitted artifact has no default value. This omission is equivalent to representing the omitted artifact with an opaque value. Note that this implies that the profile being used permits that artifact to be opaque. •A process must be ‘valid’: -(Peter’s 3) After injecting opaque tokens any where they have been omitted, it complies with the BPEL schema that accommodates extension with opacity as defined in bullet 3 above. Hence, there is only one schema, for abstract and for executable BPEL. (Check that this is consistent with resolution of 24). -(Peter’s 4) There exists at least one syntactic completion that yields a *valid executable process* using the following manipulations): -Defining all opaque tokens. -Adding new elements. The purpose of the latter check is for *syntactic* validity, in that it limits the creation of absurd BPEL constructs that the XML Schema would otherwise allow. 15.1.2 Semantics and consistency of the common base: ----------------------------------------------------- (from Peter’s main) The common base, being extremely flexible, lacks well-defined semantics. On the other hand, executable BPEL processes have well-defined semantics and prescribed behavior. The semantics of an abstract process are provided by the range of executable BPEL processes that the particular abstract process represents. This range is provided in usage profiles, and varies from one profile to another. In other words, the semantics of an abstract process depend on its associated profile. [From Peter’s 3]In addition to semantics, the 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). Any required clarifications depending on allowed opacity will be specified in the relevant usage profile. (Peter’s 5) In the common base definition, there are no requirements on how executable realizations of a given abstract process should be implemented (i.e. language, platform, etc) (c.f. analogy to WSDL); nor are specific relationships with such realizations implied. Again, a concrete usage profile might provide such information based on its use case. Note that the requirement in the common base for the existence of at least one possible syntactic completion in section 15.1 is used for validation. 15.2 Abstract Process Profiles: --------------------------------- Having defined the level of opacity and omission abstract processes, we now look closer at what this opacity means in practice. The semantics and consistency of executable BPEL processes are well -understood and laid out in this specification. The minimum requirements that a BPEL abstract process must conform to for it to be valid are defined in the common base definition. The combination of these two enables one to clearly define usage profiles that characterize classes of abstract processes based on the associated use case. In other words, a usage profile provides and the information necessary to understand a particular abstract process. [From Peter’s 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 exist 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. The characteristics of a profile are: -A profile MUST NOT violate the common base; i.e., the set of abstract processes conformant to a specific profile must be a subset of the universe of abstract processes permitted by the common (syntactic) base. -A profile MUST specify: -An identifying URI that processes written in it must refer to. -The level of opacity it allows (for example: only such and such attributes can be opaque, or X can only be opaque if Y is also opaque, or activities as well as all attributes and expressions can be opaque, etc). Note that omission in the base is a special case of opacity. Therefore, limiting the opacity also limits what can be omitted: if a profile disallows the opacity of a particular attribute or expression, then that attribute or expression cannot be omitted in abstract processes belonging to that profile. -The effects of the allowed opacity on the consistency and restrictions of affected constructs and the overall process, as a delta from executable BPEL. For example, if a profile allows opaque ”operation” attributes on receive and reply activities then that profile should specify how a receive and a reply are matched. -the rules and restrictions for creating the executable completions that its usage permits. A profile may specify additional information specific to its usage - for example additional restrictions and guidelines, such as “don’t use any links” or “don’t require a createInstance receive” - as long as they do not violate the common base. 15.3. Abstract Process Profile for … (refactoring of AP1.1) ------------------------------------------------------------- • To include refactoring of AP1.1, including old 15.1 and 15.2. 15.4 [optional, left open as part of 82] Abstract Process Profile for … ------------------------------------------------ • Reworking of the other profile that has been asked for, but is still awaiting vote. xxxxxxxxxxxxxxxxxxxxxxxxxxxx Related Items agreed on as part of Issue 82: ------------------------------------------------ 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.