[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 82 - propsal for a vote (last, no change log)
Abstract Processes. Major Diffs in Spec. 1. Introduction ---------------- • Reword last four sentences of second paragraph. Delete the third paragraph of the introduction. Mutually visible message exchange behavior of each of the parties involved can be described using an Abstract Process, without revealing their internal implementation. There are two good reasons to separate the public aspects of business process behavior from internal or private aspects. One is that businesses obviously do not want to reveal all their internal decision making and data management to their business partners. The other is that, even where this is not the case, separating public from private process provides the freedom to change private aspects of the process implementation without affecting the visible behavior. Visible behavior must clearly be described in a platform-independent manner and may capture behavioral aspects that have cross-enterprise business significance. •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. •Remove from Introduction since this mainly deals with AP1.1. Relevant text/ideas can be reused for the AP1.1 profile, reworked to fit the text for that profile. -“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 (abstract or executable) …”): It is also possible to use ‘abstract’ WS-BPEL processes. A WS-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 WS-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). In one particular usage scenario, another use case might be to define a process "template" that may embody 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. We use ‘consistency constraints’ to refer to constraints required for a valid executable WS-BPEL process that are not enforceable by the XML Schema, such as requiring at least one receive with ‘createInstance’ set to true or that every link with a source activity must have a target activity. 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 WS-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 ----------------------------------------- • Remove: abstractProcess=”true|false” 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 is mandatory for abstract processes. • Delete: "Although <exit> is permitted as an interpretation of the token activity, it is only available in executable processes and as such is defined in the section on Extensions for Executable Processes." 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 WS-BPEL. •Replace old section 15 with: ------------------------------ 15. WS-BPEL Abstract Processes --------------------------------------- (editor’s note: a couple of sentences of intro) 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 defines the necessary syntactic constraints and the semantics based on executable WS-BPEL for a particular use case for abstract processes. 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 WS-BPEL abstract processes must conform to. The syntactic characteristics of the base are: [1] The abstractProcessProfile attribute MUST exist and have a value referring to an existing profile definition. [2] All the constructs of executable process are permitted. Thus, there is no fundamental expressive power distinction between abstract and executable processes. [3] Certain syntactic constructs that are mandatory according to the XML Schema for WS-BPEL executable processes may be hidden as in 15.1.1. [4] An abstract process MUST comply with the syntactic validity constraint defined in 15.1.2. 15.1.1: Hiding syntactic elements. The rules for hiding syntactic elements as mentioned in clause [3] are: - The following syntactic entities may use an opaque form, using an extension to the syntax of executable WS-BPEL: [***Expected from 107 ***] - Omission may be used as a shortcut to opacity, from hereon referred to as "omission-shortcut". The “omission shortcut” is exactly equivalent to representing the omitted artifact with an opaque value at the omitted location. It is only allowed to omit tokens whose omission and omitted location can deterministically be detected. To enforce this, we restrict the omittable tokens to all [things from 107] which are both (1) syntactically *required* by the Executable WS-BPEL XML Schema, and (2) have no default value. If the omitted token is an activity, the implied opaque activity has the exact form <opaqueActivity/> (ie: no standard-elements or standard-attributes). Notice that (1) deliberately excludes any non-Schema requirements of executable WS-BPEL. Therefore, an abstract process P1 that uses the omission-shortcut is always equivalent to an abstract process P2 that is the same as P1 but injects opaque tokens anywhere they have been omitted and does not use the omission-shortcut. To illustrate, consider a process that omits the variable attribute in all invoke activities. This is equivalent to another process which is identical to P1 except that it includes the 'variable' attribute on all its invokes but with the value "opaque", and vice versa. 15.1.2 Syntactic Validity Constraints An abstract process is valid if it meets both of the following criteria, referred to in clause [4] : - Comply with the WS-BPEL XML Schema (How to do the schema, & abstract/exec schema issues tbd in 82.1). This is purely an XML Schema check and does not enforce any non-schema validation rules, such as requiring that every link that has a source must also have a target. -There exists at least one basic executable completion of the abstract process (see definition below). The purpose of the latter check is to improve the static validation of an abstract process beyond simply the XML Schema check, thereby limiting the creation of absurd constructs in the abstract processes that the Schema would otherwise allow. On the other hand, the semantics of an abstract process comes from the range of executable processes that can be created from the executable completions (not limited to 'basic executable completions') allowed by its profile. Definition: A basic executable completion of an abstract process is an executable completion whose allowed syntactic transformations are limited to (a) below. Definition: An executable completion of an abstract process is an executable process that • is derived using some combination of the following syntactic transformations: a) Opaque Token Replacement: Replacing every opaque token (including those omitted using the omission-shortcut above) with a corresponding executable token. For example, replacing an opaque activity with an <empty>. b) Addition of BPEL Constructs: Adding new BPEL XML elements anywhere in the process. • is a valid executable WS-BPEL process that satisfies all static validation rules mandated by this specification including both schema-based and non-schema-based rules. **Note: Special case will be allowed for the base if the createInstance receive issue is resolved such that that activity is allowed to be omitted in an abstract process since that has an open issue]. 15.1.2 Interpretation of the common base: ----------------------------------------------------- The common base, being extremely flexible, lacks well-defined semantics. On the other hand, executable WS-BPEL processes have well-defined semantics and prescribed behavior. The semantics of an abstract process are provided by the range of executable WS-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. In addition to semantics, the consistency constraints of executable WS-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 WS-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 completions sections of the relevant usage profile. 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 syntactic validation. 15.2 Abstract Process Profiles and the Semantics of Abstract Processes: --------------------------------- The common base for abstract processes is a specification of the syntactic universe within which abstract processes are defined. It is not meant to provide any semantics for abstract processes since the semantics must express a specific intent for the interpretation of an abstract process and the common base provides no mechanism to express such intent. Profiles are provided to define classes of abstract processes with a common (shared) semantic interpretation of the members of the class. 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 (see below). The reason being that the semantics of those constructs can be realized only in the possible executable completions. As an edge case, a permitted completion may sometimes be in essence identical to the abstract process syntactically, but this is the exception rather than the rule. A profile MUST not violate the common base. Specifically, a profile defines (i) A URI that identifies the profile and is used as the value of the abstractProcessProfile attribute by all abstract processes that belong to the class defined by the profile. (ii) A class of abstract processes that is a subset of the common base, i.e., the set of syntactically valid abstract processes that belong to the profile. Note that the subset does not have to be proper, i.e., it may include the entire common base. Examples include profiles that disallow control links or certain types of opaque tokens. Note further that the subset must be consistent with respect to the use of the omission-shortcut. Specifically, if a profile limits the use of opaque tokens in the class of abstract processes it covers, then it can only permit those omissions that correspond to permitted usage of opaque tokens. For instance, if a profile does not allow attributes to be opaque, then abstract processes belonging to that profile cannot omit attributes using the omission-shortcut. (iii) The set of permitted executable completions for abstract processes that belong to the class. The set of permitted executable completions must be non-empty for each abstract process in the class. For example, a profile may include all the syntax of the common base, and only permit executable completions of "Opaque Token Replacement” but not allow "Addition of BPEL Constructs".. The class of abstract processes covered by this profile can only include abstract processes which, when completed within the constraint, represent valid executable processes. The profile must therefore specify additional syntactic constraints beyond those of the common base to ensure this. For example, specifying that a <reply> is the reply to the same operation as a prior <receive> when their operation attributes are opaque. The profile would do this in the completions section, by specifying how one can determine the replacement of the “operation” attribute in a <reply>. Another example is a profile that allows “Opaque Token Replacement” and only the addition of BPEL constructs that create leaf-nodes or subtrees. By disallowing arbitrary additions, such a profile would not allow executable completions to do such things as wrap an existing activity with a <while>, or add a <sequence> around activities in a <flow>. On the other hand, it would allow the creation of new leaf activities inside an existing <flow>. 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. 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. Editor’s Note: add note about profile/base versioning from Monica. See minutes of April 6 for decision. (from Rania: I don’t have the minutes yet..) The submission of proposals for these profiles is not bounded by the April 1st deadline.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]