SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| IBM and SAP AG Release WS-BPEL Extension for Sub-Processes (BPEL-SPE). |
Contents
A technical white paper published jointly by IBM and SAP for WS-BPEL Extension for Sub-Processes: BPEL-SPE proposes an extension to WS-BPEL "that allows for the definition of sub-processes that can be reused within the same or across multiple WS-BPEL processes." A formal language specification defining the precise syntax and semantics of the BPEL-SPE extension is planned for later release.
The design paper recognizes that "the problem of modularization and reuse in the BPEL language has been intensively discussed in different contexts, including the work on the upcoming WS-BPEL standard. However, the outcomes of those discussions show that there is no consensus on how the problem should be resolved. The paper describes different invocation scenarios and introduces a coordination protocol to be used for interoperable invocation of sub-processes across infrastructures from different vendors."
A backgrounder document prepared by Ivana Trickovic (Standards Architect in SAP's Platform Ecosystem Industry Standards Group) discusses in detail the problem process designers are facing using the WS-BPEL language with respect to modularization and reuse of WS-BPEL process fragments or processes. This document explains why the authors believe the issue should be addressed directly in the language rather than simply as a modeling tool issue.
According to IBM's summary statement, the BPEL language currently "does not support the explicit definition of business process 'fragments' that can be invoked from another (or the same) business process. The only way to approximate similar behavior today is by defining a complete business process as an independent service and invoking it using an <invoke> activity. The fact that the invoked activity is really implemented as another process is completely hidden from the parent process, in other words, there is no chance to establish any coupling of process instance lifecycles."
A sub-process in this context is understood as "a fragment of BPEL code that can be reused within a process or across multiple processes. It may also be a long-running process, which includes interactions with other partners. However, the interaction of a subprocess with its parent process is typically limited to the initiating request message and the final reply message. A sub-process may be defined either locally within another BPEL process and reused only within that process or as a BPEL process and reused across other BPEL processes, where the latter kind of process can be used both as a sub-process as well as a business process on its own."
Section 2 of the white paper defines sub-process in general, along with the notion of a standalone sub-process and an inline sub-process; section 3 supplies details about different modes of invocations between a parent process and a subprocess; section 4 describes aspects of interoperability such as a common state model, and a protocol to couple the lifecycle between a parent process and a subprocess defined and executed in different environments.
The WS-BPEL Extension for Sub-Processes identifies key features needed to provide sub-process capabilities in a direct way, meeting the following goals: (1) allow for the invocation of a business process as a sub-process of another business process such that its lifecycle is tightly coupled to the lifecycle of the parent process; (2) allow for the definition of a business process within the context of another business process, so it can be used (and reused) within that other process; (3) allow a sub-process defined within the context of another business process to access data from its parent process; (4) allow for the invocation of sub-processes across BPEL engines so that a process running on one BPEL engine can invoke a sub-process on another BPEL engine."
The BPEL-SPE extension "is defined as a layer on top of the BPEL language so that its features can be composed with the BPEL core features whenever needed. The authors envisage that additional BPEL extensions may be introduced which may use BPEL-SPE."
WS-BPEL Extension for Sub-Processes: BPEL-SPE. A Joint White Paper by IBM and SAP. September 2005. 17 pages. Also available from IBM. Authors (alphabetically): Matthias Kloppmann (IBM), Dieter Koenig (IBM), Frank Leymann (IBM), Gerhard Pfau (IBM), Alan Rickayzen (SAP), Claus von Riegen (SAP), Patrick Schmidt (SAP), Ivana Trickovic (SAP). Modularization and Reuse in WS-BPEL. By Ivana Trickovic (SAP AG). SDN Community Contribution. SAP Developer Network (SDN). October 13, 2005. This article explains briefly the need for an extension to the Web Services Business Process Execution Language (WS-BPEL) that supports modularization and reuse. It discusses the requirements for such extension and possible ways how to resolve them. It should help readers understand why SAP and IBM have worked jointly on a proposal for sub-processes in WS-BPEL. [cache PDF] Web Services Business Process Execution Language Version 2.0. Committee Draft. 156 pages. Document Approved by the OASIS Web Services Business Process Execution Language (WSBPEL) TC on a call of 09/21/2005. Also in .DOC and HTML formats. Source: v 1.86, SourceForge 2005-10-04.
Committee Draft edited by Assaf Arkin (Intalio), Sid Askary, Ben Bloch, Francisco Curbera (IBM), Yaron Goland (BEA), Neelakantan Kartha (Sterling Commerce), Canyang Kevin Liu (SAP), Satish Thatte (Microsoft), Prasad Yendluri (webMethods), and Alex Yiu (Oracle).
"Designing complex and large business processes requires a language that supports modularization and re-use, in a portable, interoperable way. The white paper WS-BPEL Extension for Sub-Processes: BPEL-SPE outlines an extension to WS-BPEL that allows for the definition of sub-processes that can be reused within the same or across multiple WS-BPEL processes. The paper describes different invocation scenarios and introduces an appropriate coordination protocol used for interoperable invocation of sub-processes across infrastructures from different vendors.
The BPEL language currently does not support the explicit definition of business process "fragments" that can be invoked from another (or the same) business process. The only way to approximate similar behavior today is by defining a complete business process as an independent service and invoking it using an <invoke> activity. The fact that the invoked activity is really implemented as another process is completely hidden from the parent process, in other words, there is no chance to establish any coupling of process instance lifecycles.
The extension proposed in the whitepaper provides the means for the invocation of a business process as a sub-process of another business process, such that its lifecycle is coupled to the lifecycle of the parent process. It allows for the definition of a business process within the context of another business process, so it can be used (and reused) within that other process, and allows a sub-process defined within the context of another business process to access data from its parent process. Finally, it allows for the invocation of sub-processes across BPEL engines..." [from the IBM summary WS-BPEL 2.0 Extensions for Sub-Processes]
A backgrounder document "Modularization and Reuse in WS-BPEL" has been prepared by SAP to explain the motivation for the BPEL-SPE extension. Excerpts:
"The Web Services Business Process Execution Language, version 2.0 (WS-BPEL) has gained a lot of traction recently. The language is suitable primarily for designing processes which orchestrate activities of different software components exposed as Web services. This is an important step towards building fully automated business processes. The model introduces the process logic as a first-class element while reusable business logic is encapsulated in Web services.
Writing processes or process fragments that can be reused in different places within a process or even across multiple processes is desired practice especially in case of complex and large business processes. For that it is necessary to have a language that supports modularization and reuse. The WS-BPEL language does not provide a feature that supports that in a portable and interoperable way.
The WS-BPEL Extension for Sub-processes — BPEL-SPE white paper published by SAP and IBM, describes how the WS-BPEL language needs to be extended in principle to enable reuse of WS-BPEL process fragments or processes within a process or across multiple processes. The value of the proposal is that it outlines an approach to support modularization and reuse in a direct way in WS-BPEL. The proposal covers different scenarios, from factoring processes into reusable process fragments that can be reused within a single WS-BPEL process to processes that can be invoked as WS-BPEL processes or can be treated as part of another process.
Modularization in WS-BPEL is about the ability to write process fragments once and use them multiple times within the same process or across multiple processes. If a process fragment needs to be changed it is not required to go through all usages of that process fragment to apply the change. Writing process fragments that can be reused in different places is desired practice especially in case of complex and large business processes. For that it is necessary to have a language that supports modularization and reuse. The latest version of the WS-BPEL language, which is currently under an OASIS standardization process, does not provide a way to do that. It does not support a definition of WS-BPEL fragments that can be invoked from within the same or from different WS-BPEL processes.
It has been argued that this is a problem of modeling tools and no particular feature is required in the WSBPEL language to support this more directly. One may also argue that a process can be decomposed into WS-BPEL processes which would be exposed as Web services and invoked using the WS-BPEL invoke activity. However, a WS-BPEL fragment is similar to a WS-BPEL scope in that the lifecycles of the calling process and the called WS-BPEL fragment are not independent. For example, if the calling process terminates the called WS-BPEL fragment has to be terminated too. This means that the termination signal must be propagated down to the chain of WS-BPEL fragment calls. The same is true in case of compensation. The other direction is interesting as well. For example, if a WS-BPEL fragment is explicitly terminated the signal must be propagated to the calling process. Obviously, the lifecycle dependency between the calling process and the called process fragment is an important aspect, which cannot be fully met by using the WS-BPEL invoke activity.
Modularization and reuse have been identified as a requirement for WS-BPEL, although a resolution has been postponed for a future version of the language. Some vendors have already provided proprietary implementations. Standardization of these concepts is important to obtain portability and interoperability. The white paper discusses requirements and outlines concepts needed to support modularization and reuse, in a portable, interoperable way.
Possible approaches: There are different approaches of how the problem of the modularization and reuse in WS-BPEL could be resolved:
Macros in WS-BPEL. Macros are a mechanism used in programming languages for code factoring. They
range from simple text substitutions to code transformations. Macros as text substitutions have been
thoroughly discussed within the OASIS WS-BPEL Technical Committee. In WS-BPEL, they would have
similar structure as WS-BPEL scopes, except the ability to see variables defined in the parent scope(s). A
macro would not need to be a valid WS-BPEL process but just a fragment of WS-BPEL code and a preprocessor
would take care to complete text substitution in the target process. It would occur as a scope in the
target WS-BPEL process. Syntax and static analysis of a WS-BPEL process could be performed as soon as
all usages of macros are resolved. This approach is complex from the usability point of view. Also, it does not
make possible to use a WS-BPEL process exposed as a Web service as a (reusable) part of another WSBPEL
process. Using the WS-BPEL onEvent structure. Fragments of WS-BPEL code could be defined as event handlers
and as such they can be called multiple times within the same process instance. However, this approach
requires an intra-process communication mechanism which is not provided in the language yet. Alternatively, partner links could be used for modeling intra-process communications, but initially they have been introduced
for designing interactions with partners. Also, this approach does not address cases where WS-BPEL
fragments are defined as WS-BPEL processes. In that case, a WS-BPEL process would be exposed as a
Web service and the same invocation mechanism, that is the WS-BPEL invoke activity, would be used as
for other Web services. That means this approach has same drawbacks as the language today does. Sub-processes in WS-BPEL. The idea is to define a new structure (called sub-processes) in WS-BPEL
that represents WS-BPEL fragments. These sub-processes would be defined either locally within a process
and reused only within that process or as a WS-BPEL process and reused across other WS-BPEL processes.
Additionally, an accompanying invocation mechanism would be defined that supports calling sub-processes in
the context of a WS-BPEL process. The mechanism must ensure that a sub-process is tightly coupled in
terms of its lifecycle to the calling process, as explained in the previous section.
The third approach seems to be the most general one covering reusability within a single process as well as across multiple processes and being extensible to include invocation of sub-processes defined in different infrastructures. Therefore, [this] white paper uses the third approach; that is it introduces the notion of sub-processes. This new structure respects some syntactical restrictions; for example, a sub-process implements a request-response operation from the point of view of the calling process and no interaction beyond the initiating request message and the final response message is allowed between the sub-process and the calling process. A WS-BPEL process is used to define a fragment of WS-BPEL code that can be reused across multiple WS-BPEL processes. In this case, the WSBPEL process respects also the same syntactical restrictions mentioned above. In additional, the white paper discusses different invocation scenarios and introduces an appropriate coordination protocol used for interoperable invocation of sub-processes across infrastructures from different vendors..."
The [Committee Draft, 01-September-2005 WS-BPEL] document "defines a notation for specifying business process behavior based on Web Services. This notation is called Web Services Business Process Execution Language. Processes in WS-BPEL export and import functionality by using Web Service interfaces exclusively.
Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. WS-BPEL is meant to be used to model the behavior of both executable and abstract processes.
WS-BPEL provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces...
WS-BPEL uses a notion of message properties , which are a type of variable property, to identify protocol-relevant data embedded in messages. Properties can be viewed as "transparent" data relevant to public aspects as opposed to the "opaque" data that internal/private functions use. Transparent data affects the public business protocol in a direct way, whereas opaque data is significant primarily to back-end systems and affects the business protocol only by creating nondeterminism because the way it affects decisions is opaque. We take it as a principle that any data that is used to affect the behavior of a business protocol must be transparent and hence viewed as a property.
The implicit effect of opaque data manifests itself through nondeterminism in the behavior of services involved in business protocols. Consider the example of a purchasing protocol. The seller has a service that receives a purchase order and responds with either acceptance or rejection based on a number of criteria, including availability of the goods and the credit of the buyer. Obviously, the decision processes are opaque, but the fact of the decision must be reflected as behavior alternatives in the external business protocol. In other words, the protocol requires something like an if activity in the behavior of the seller's service but the selection of the branch taken is nondeterministic. Such nondeterminism can be modeled by allowing the assignment of a nondeterministic or opaque value to a message property, typically from an enumerated set of possibilities. The property can then be used in defining conditional behavior that captures behavioral alternatives without revealing actual decision processes. WS-BPEL explicitly allows the use of nondeterministic data values to make it possible to capture the essence of public behavior while hiding private aspects.
The basic concepts of WS-BPEL can be applied in one of two ways. A WS-BPEL process can define a business protocol role, using the notion of abstract process. For example, in a supply-chain protocol, the buyer and the seller are two distinct roles, each with its own abstract process. Their relationship is typically modeled as a partner link. Abstract processes use all the concepts of WS-BPEL but approach data handling in a way that reflects the level of abstraction required to describe public aspects of the business protocol. Specifically, abstract processes handle only protocol-relevant data. WS-BPEL provides a way to identify protocol-relevant data as message properties. In addition, abstract processes use nondeterministic data values to hide private aspects of behavior.
It is also possible to use WS-BPEL to define an executable business process. The logic and state of the process determine the nature and sequence of the Web Service interactions conducted at each business partner, and thus the interaction protocols. While a WS-BPEL process definition is not required to be complete from a private implementation point of view, the language effectively defines a portable execution format for business processes that rely exclusively on Web Service resources and XML data. Moreover, such processes execute and interact with their partners in a consistent way regardless of the supporting platform or programming model used by the implementation of the hosting environment.
WS-BPEL defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web Service interfaces, and the structure of the relationship at the interface level is encapsulated in what we call a partner link. The WS-BPEL process defines how multiple service interactions with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination. WS-BPEL also introduces systematic mechanisms for dealing with business exceptions and processing faults. Finally, WS-BPEL introduces a mechanism to define how individual or composite activities within a process are to be compensated in cases where exceptions occur or a partner requests reversal.
WS-BPEL is layered on top of several XML specifications: WSDL 1.1, XML Schema 1.0, and XPath1.0. WSDL messages and XML Schema type definitions provide the data model used by WS-BPEL processes. XPath provides support for data manipulation. All external resources and partners are represented as WSDL services. WS-BPEL provides extensibility to accommodate future versions of these standards, specifically the XPath and related standards used in XML computation..." [from the Version 1.86 Abstract and Introduction]
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
