The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
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
Last modified: July 01, 2008
Business Process Execution Language for Web Services (BPEL4WS)

Contents

Note: Subsequent to the publication of the WS-BPEL 2.0 specification as an OASIS Standard, technical work continued at OASIS in connection with WS-BPEL for People (BPEL4People). This 2-part specification provides a language for the specification of Executable and Abstract business processes, extending the Web Services interaction model to support business transactions.

Introduction

"WS-BPEL is an acronym for Web Services Business Process Execution Language. WS-BPEL 2.0 is a revision of the original acronym BPEL4WS (Business Process Execution Language for Web Services) 1.0 and 1.1. WS-BPEL is an XML based language enabling users to describe business process activities as Web services and define how they can be connected to accomplish specific tasks. WS-BPEL is designed to specify business processes that are both composed of, and exposed as, Web Services. WS-BPEL 2.0 is an orchestration language. An orchestration is from one actor's point of view, where choreography looks at a global system and all the actors, and their interactions, without looking at any single actor's internals. Unlike an orchestration, there is no conductor in choreography — it is a peer to peer set of relationships. Examples of choreography languages include BPSS and WS-CDL. BPEL orchestrates services that are exposed using WSDL 1.1. These services can be created using any language (including BPEL), but the fact that they are exposed via WSDL 1.1 means that BPEL need not know anything about their implementation. Any web service with a WSDL 1.1 contract can be used by or within by a BPEL process WS-BPEL 2.0 is not designed to use RESTful services because these types of services do not use WSDL. Services to be used by BPEL must be described using a WSDL contract. WS-BPEL 2.0 is specifically designed to orchestrate long-running web service conversations..." [adapted 2007-05 from TC materials]

WS-BPEL Publication Milestones

[April 12, 2007] In April 2007, OASIS announced that its members had approved the Web Services Business Process Execution Language Version 2.0 specification, Committee Specification 01, as an OASIS Standard. WS-BPEL uses Web services standards to describe business process activities as Web services, defining how they can be composed to accomplish specific tasks. 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 services interfaces. 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 separates the public aspects of business process behavior from internal or private aspects-and supports both. The standard can be used both for executable processes, which describe the actual behavior of participants in business interactions, and for abstract processes, that may be used to represent publicly observable behaviors. Abstract processes serve a descriptive role and allow for more than one possible use case. WS-BPEL leverages other Web services standards such as SOAP and WSDL for communication and interface description. By describing the inbound and outbound process interfaces in WSDL, BPEL enables them to be easily integrated into other processes or applications. In turn, this allows consumers of a process to inspect and invoke a BPEL process just like any other Web service, thereby inheriting all other aspects of a Web service such as quality of service policies. More than 37 organizations collaborated to develop WS-BPEL, including representatives of Active Endpoints, Adobe Systems, BEA Systems, Booz Allen Hamilton, EDS, HP, Hitachi, IBM, IONA, Microsoft, NEC, Nortel, Oracle, Red Hat, Rogue Wave, SAP, Sun Microsystems, TIBCO, webMethods, and other members of OASIS. Active Endpoints, IBM, Intalio, SEEBURGER, and Sun Microsystems verified successful usage of WS-BPEL, in accordance with eligibility requirements for all OASIS Standards. Several open source implementations of WS-BPEL 2.0 are currently available or in development..."

[April 16, 2003]   OASIS Forms Web Services Business Process Execution Language TC (WSBPEL).    A new Web Services Business Process Execution Language TC is being formed at OASIS to continue work on the business process language published in the Business Process Execution Language for Web Services (BPEL4WS) 1.0 specification. "Continuing the approach and design used in BPEL4WS, the work of the BPEL TC will focus on specifying the common concepts for a business process execution language which form the necessary technical foundation for multiple usage patterns including both the process interface descriptions required for business protocols and executable process models. BEA, IBM, Microsoft, SAP and Siebel intend to submit an updated Business Process Execution Language for Web Services (BPEL4WS) version 1.1 specification at the first meeting of the TC. This revised document is a modularized and updated version of the original specification that clearly identifies the core concepts and required extensions for BPEL4WS. TC activity is not intended to specify bindings to specific hardware/software platforms and other mechanisms required for a complete runtime environment for process implementation." The TC Co-Chairs are Diane Jordan (IBM) and John Evdemon (Microsoft). The first meeting of the WSBPEL TC will be held by phone conference call on May 16, 2003.

[August 22, 2002] On August 9, 2002 Microsoft, IBM, and BEA announced the publication of three specifications which "collectively describe how to reliably define, create, and connect multiple business processes in a Web services environment. The specifications will help organizations coordinate business processes and transactions within the enterprise and with partners and customers across heterogeneous systems and within the enterprise. Announced were the new specifications to address transacted communications of Web services (WS-Coordination, WS-Transaction) and a new language to describe business processes (Business Process Execution Language for Web Services, or BPEL4WS). BPEL4WS allows companies to describe business processes that include multiple Web services and standardize message exchange internally and between partners. WS-Coordination and WS-Transaction provide companies with a reliable and durable way of handling multiple Web services interactions, regardless of the underlying computing infrastructure."

From the 2002-08 announcement: "A business process describes the flow of tasks, the order in which they need to be performed, the type of data shared and how other partners are involved... Once the business process and the connections with customers, partners and internal entities are defined using BPEL4WS, the next step is to coordinate the various activities that occur within a business process, in order and at the right time for completion. WS-Coordination and WS-Transaction complement BPEL4WS by providing a way for companies to coordinate and integrate a number of distinct Web services and business processes, consistently and reliably, across a variety of implementation environments to ensure the right outcome... For example, a travel agency that exposes its business travel processes -- such as hotel, flight or car rental reservation applications -- as Web services can integrate and transact with the business travel processes of its customers and partners. Using BPEL4WS, WS-Coordination and WS-Transaction, the travel agency's customer could electronically submit a travel itinerary to an agent; the agent's system can automatically procure the appropriate airline, hotel and car reservations from partners to match the customer request; and the system can then send confirmation of all reservations back to the customer once the itinerary processing is complete. In case one of the applications fails, tasks that have already been completed can be automatically undone..."

Business Process Execution Language for Web Services abstract: "This document defines a notation for specifying business process behavior based on Web Services. This notation is called Business Process Execution Language for Web Services (abbreviated to BPEL4WS in the rest of this document). Processes in BPEL4WS 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. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes. BPEL4WS 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. BPEL4WS 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... This is an initial public draft release of the BPEL4WS specification. We anticipate a number of extensions to the feature set of BPEL4WS that are discussed briefly at the end of the document. BPEL4WS represents a convergence of the ideas in the XLANG and WSFL specifications. Both XLANG and WSFL are superseded by the BPEL4WS specification."

BPEL4WS Version 1.0 Bibliographic information: Business Process Execution Language for Web Services. Version 1.0. 31-July-2002. By Francisco Curbera (IBM), Yaron Goland (BEA Systems), Johannes Klein (Microsoft), Frank Leymann (IBM), Dieter Roller (IBM), Satish Thatte (Microsoft - Editor), and Sanjiva Weerawarana (IBM). Copyright 2001-2002 BEA Systems, International Business Machines Corporation, Microsoft Corporation, Inc.

Principal References

  • OASIS WSBPEL Technical Committee

  • [April 2007] Web Services Business Process Execution Language Version 2.0. OASIS Committee Specification. 31-January-2007. PDF. Note: this CS01 version was balloted and approved as an OASIS Standard in April 2007 [ballot]. Produced by members of the OASIS Web Services Business Process Execution Language (WSBPEL) TC, under co-chairs Diane Jordan (IBM) and John Evdemon (Microsoft). Edited by Alexandre Alves (BEA), Assaf Arkin (Intalio), Sid Askary (Individual), Charlton Barreto (Adobe Systems), Ben Bloch (Systinet), Francisco Curbera (IBM), Mark Ford (Active Endpoints Inc), Yaron Goland (BEA), Alejandro Gumzar (JBoss Inc.), Neelakantan Kartha (Sterling Commerce), Canyang Kevin Liu (SAP), Rania Khalaf (IBM), Dieter König (IBM), Mike Marin (IBM — formerly FileNet Corporation) Vinkesh Mehta (Deloitte), Satish Thatte (Microsoft), Danny van der Rijn (TIBCO Software), Prasad Yendluri (webMethods), and Alex Yiu (Oracle). "This document defines a language for specifying business process behavior based on Web Services. This language is called Web Services Business Process Execution Language (abbreviated to WS-BPEL in the rest of this document). 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. Abstract business processes are partially specified processes that are not intended to be executed. An Abstract Process may hide some of the required concrete operational details. Abstract Processes serve a descriptive role, with more than one possible use case, including observable behavior and process template. WS-BPEL is meant to be used to model the behavior of both Executable and Abstract Processes. WS-BPEL provides a language for the specification of Executable and Abstract business processes. 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..."

  • Web Services Business Process Execution Language Version 2.0. Working Draft. 23-August-2005. Prepared by members of the OASIS Web Services Business Process Execution Language (WSBPEL) TC. 154 pages. 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). Source: SourceForge.Net CVS repository 'wsbpeltc'.

  • [December 02, 2004] "Web Services Business Process Execution Language." Edited by 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). Produced by members of the OASIS Web Services Business Process Execution Language (WSBPEL) Technical Committee. Working Draft v 01. 08-September-2004. Document identifier: 'wsbpel-specification-draft-01'. Characterized as a WS-BPEL TC editors' draft specification, "clean copy, no tracking highlights as requested... Draft, a preliminary unapproved sketch, outline, or version." Posted to the Kavi document repository by Prasad Yendluri on Wednesday, 08-September-2004 07:28pm. HTML source (lacking image files).

  • [December 04, 2003] "Web Services Business Process Execution Language." Working Draft Version 01, "23 November 2003." This is a copy of the latest editor's draft (as of Nov 23, 2003) of the specification. Proposed first TC draft. Submitted to the OASIS Kavi repository by Prasad Yendluri on Wednesday, 03 December 2003 02:34pm; Modified by Diane Jordan (drj@us.ibm.com) on Thursday, 04 December 2003 11:16am. .DOC source. "This document defines a notation for specifying business process behavior based on Web Services. This notation is called Business Process Execution Language for Web Services (abbreviated to BPEL4WS in the rest of this document). Processes in BPEL4WS 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. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes. BPEL4WS 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. BPEL4WS 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." See also the earlier version of Friday, 31 October 2003 01:39pm, posted by Yaron Goland with the description "This is an unofficial, unsupported, unapproved, in progress, copy of the latest editor's draft from the CVS server. If you are or anyone else should read or try to do anything with this spec the OASIS TC will disavow any knowledge of the spec's existence. This message will self destruct in five seconds...." [2003-10-22 PDF and cache .DOC]

  • [May 06, 2003] "Business Process Execution Language for Web Services. [BPEL4WS.]" By Tony Andrews (Microsoft), Francisco Curbera (IBM), Hitesh Dholakia (Siebel Systems), Yaron Goland (BEA), Johannes Klein (Microsoft), Frank Leymann (IBM), Kevin Liu (SAP), Dieter Roller (IBM), Doug Smith (Siebel Systems), Satish Thatte (Microsoft - Editor), Ivana Trickovic (SAP), and Sanjiva Weerawarana (IBM). Version 1.1. 5-May-2003. 136 pages. DIFF version March 31, 2003 -->> May 05, 2003. Copyright (c) 2002, 2003 BEA Systems, International Business Machines Corporation, Microsoft Corporation, SAP AG, and Siebel Systems. "This document defines a notation for specifying business process behavior based on Web Services. This notation is called Business Process Execution Language for Web Services (abbreviated to BPEL4WS in the rest of this document). Processes in BPEL4WS 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. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes. BPEL4WS 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. BPEL4WS 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..." Note: This version of the BPEL4WS specification was made available by OASIS WSBPEL Technical committee co-chairs Diane Jordan and John Evdemon in a 2003-05-06 posting by Diane Jordan to the wsbpel@lists.oasis-open.org mailing list [Subject: Information for the OASIS Open WS BPEL Technical Committee]. The version is identified as "a copy of the final version of the BPEL4WS V1.1 specification which the authors plan to submit at the first meeting [of the WSBPEL TC] on May 16, [2003]; please note that this version will not be active on the authors' websites until May 12, [2003]..." The document's copyright notice reads (in part) "BEA, IBM, Microsoft, SAP AG and Siebel Systems (collectively, the 'Authors') agree to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions, to patents that they deem necessary to implement the Business Process Execution Language for Web Services Specification." See: "OASIS Forms Web Services Business Process Execution Language TC (WSBPEL)."

  • [April 17, 2003] See previous reference for a later "Version 1.1." See the DIFFs version providing a comparison between the BPEL4WS V1.1 document dated March 31, 2003 and the V1.1 document dated May 5, 2003; posted by Diane Jordan to the WSBPEL list on June 02, 2003; [source]. Business Process Execution Language for Web Services. Version 1.1. 31-March-2003. 134 pages. By Tony Andrews (Microsoft), Francisco Curbera (IBM), Hitesh Dholakia (Siebel Systems), Yaron Goland (BEA Systems), Johannes Klein (Microsoft), Frank Leymann (IBM), Kevin Liu (SAP), Dieter Roller (IBM), Doug Smith (Siebel Systems), Satish Thatte (Microsoft - Editor), Ivana Trickovic (SAP), and Sanjiva Weerawarana (IBM). Copyright (c) 2002, 2003 BEA Systems, International Business Machines Corporation, Microsoft Corporation, SAP AG, and Siebel Systems. Abstract: "This document defines a notation for specifying business process behavior based on Web Services. This notation is called Business Process Execution Language for Web Services (abbreviated to BPEL4WS in the rest of this document). Processes in BPEL4WS 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. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes. BPEL4WS 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. BPEL4WS 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." APPENDIX D of the v1.1 specification supplies the XML (XSD) Schemas. In this second public draft release of the BPEL4WS specification (v1.1), a "more modular structure [has been given] to the initial specification announced in August 2002 by Microsoft, IBM, and BEA." See details in the 2003-04-16 news story "OASIS Forms Web Services Business Process Execution Language TC (WSBPEL)." General references in "Business Process Execution Language for Web Services (BPEL4WS)." Related specifications are listed in "Business Process Management and Choreography." [PDF source: IBM]

  • XML Schemas (from BPEL4WS Specification APPENDIX D, Version 1.1 dated May 05, 2003) include:

    1. BPEL4WS Schema. Version 1.1 dated May 05, 2003.
    2. Partner Link Type Schema. Version 1.1 dated May 05, 2003,
    3. Message Properties Schema. Version 1.1 dated May 05, 2003.

  • BPEL4WS v1.1 2003-03-31 XML Schemas, from Appendix D:

  • Websites for the published BPEL4WS Version 1.1 specification:

  • Press for BPEL4WS V1.1 (March 31, 2003):

  • "Web Services Specifications for Business Transactions and Process Automation." News item 2002-08-12.

  • "Microsoft, IBM and BEA Deliver Specifications for Business Transactions and Process Automation Within and Between Companies. WS-Coordination, WS-Transaction and BPEL4WS Describe How to Reliably Define, Create and Connect Multiple Business Processes in a Web Services Environment."

  • Websites for the published BPEL4WS Version 1.0 specification:

  • Business Process Execution Language for Web Services. Version 1.1.

  • Related Specifications:

    • Web Services Coordination (WS-Coordination). August 09, 2003. From BEA Systems, International Business Machines Corporation, and Microsoft Corporation. Abstract: "This specification (WS-Coordination) describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed transactions. The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. Additionally this specification describes a definition of the structure of context and the requirements for propagating context between cooperating services."

    • Web Services Transaction (WS-Transaction). August 09, 2002. From BEA Systems, International Business Machines Corporation, and Microsoft Corporation, Inc. "WS-Transaction describes coordination types that are used with the extensible coordination framework described in the WS-Coordination specification... The WS-Coordination specification defines an extensible framework for defining coordination types. A coordination type can have multiple coordination protocols, each intended to coordinate a different role that a web service plays in the activity. To establish the necessary relationships between participants, messages exchanged between participants carry a CoordinationContext. The CoordinationContext includes a Registration service PortReference of a Coordination service. Participants use that Registration service to register for one or more of the protocols supported by that activity. This [WS-Transaction] specification provides the definition of two coordination types including their respective protocols for: (1) An atomic transaction (AT) is used to coordinate activities having a short duration and executed within limited trust domains. They are called atomic transactions because they have an "all or nothing" property. The Atomic Transaction specification defines protocols that enable existing transaction processing systems to wrap their proprietary protocols and interoperate across different hardware and software vendors. (2) A business activity (BA) is used to coordinate activities that are long in duration and desire to apply business logic to handle business exceptions. The long duration prohibits locking data resources to make actions tentative and hidden from other applications. Instead, actions are applied immediately and are permanent. The Business Activity specification defines protocols that enable existing business process and work flow systems to wrap their proprietary mechanisms and interoperate across trust boundaries and different vendor implementations."

    • WSTX schema and WSTX WSDL; WSBA schema and WSBA WSDL.

  • Collaxa BPEL4WS Tutorial. Also available in PDF format. See other resources in the Collaxa BPEL Developer Center.

  • [IBM] Customer testimonials for BPEL4WS, WS-TX, and WS-C. From: The Bekins Company, CommerceQuest, E2open, Hitachi Software, Holosofx, i2 Technologies, Siebel Systems, Inc., and Vitria Technology.

General References: Articles, Papers, News

  • Messaging and Transaction Coordination: General reference document on standards related to coordination of messages/transactions, as well as choreography, workflow, and business brocess modeling, especially in the Web Services arena.

  • [January 14, 2008] OASIS announced that consortium members have submitted a charter proposal for a new WS-BPEL Extension for People (BPEL4People) Technical Committee. Companies sponsoring the proposal include Active Endpoints, Adobe, BEA, IBM, Oracle, SAP, Software AG, and Sun Microsystems. The designated TC Convenor is Jeff Mischkinsky (Oracle). This Technical Committee proposal follows a June 2007 statement from a group of six technology vendors, including Active Endpoints, Adobe, BEA Systems, IBM, Oracle, and SAP AG, announcing that the two-part BPEL4People specification would be submitted to OASIS in the near future. The Web Services Business Process Execution Language Version 2.0 (WS-BPEL) specification was published as an approved OASIS Standard in April 2007. It provides a language for the specification of executable and abstract business processes, extending the Web Services interaction model to support business transactions. The FAQ document published by the OASIS Web Services Business Process Execution Language Technical Committee recognizes that "BPEL was not designed for human workflow." The proposed BPEL4People Technical Committee would define: (1) extensions to the OASIS WS-BPEL 2.0 Standard to enable human interactions, and (2) a model of human interactions that are service-enabled. This work will be carried out through continued refinement of the Version 1.0 documents released in June 2007, consistent with the WS-BPEL Extension for People — BPEL4People Joint White Paper published by IBM and SAP in July 2005. In particular, the new TC work will focus upon: (1) Defining the specification of a WS-BPEL extension enabling the definition of human interactions ("human tasks") as part of a WS-BPEL process; (2) Defining the specification of a model enabling the definition of human tasks that are exposed as Web services; (3) Defining a programming interface enabling human task client applications to work with human tasks.

  • [November 28, 2007] "Transactional BPEL Processes with AO4BPEL Aspects." By Anis Charfi (SAP Research, CEC Darmstadt, Darmstadt, Germany), Benjamin Schmeling (UBL Informationssysteme, Neu-Isenburg, Germany), and Mira Mezini (Software Technology Group, TU Darmstadt, Germany). Presented at the Fifth IEEE European Conference on Web Services (ECOWS 2007). November 26-28, 2007 in Halle (Saale), Germany. 10 pages, with 24 references. "Recently, OASIS approved two standards respectively for Web Service composition and for Web Service transactions. Nevertheless, it is still unclear how WS-BPEL and the WS-TX family of specifications interoperate, i.e., how to use atomic transactions and business activities in the context of BPEL processes. In this paper, we present several transactional requirements in BPEL processes and argue that BPEL's compensation mechanism provides only limited support for a few of these requirements, e.g., it cannot cope with atomic transactions with the ACID properties. To support transactional BPEL processes, we use the AO4BPEL process container framework. In this framework, the transaction requirements of the process activities are specified declaratively in a deployment descriptor and an aspectbased container is generated automatically to integrate the process execution with the transaction middleware, which is provided as a transaction Web Service based on Apache Kandula... To enable transactional workflows in BPEL, we used the AO4BPEL process container framework, which provides several benefits. It is open and light-weight, i.e., it can be easily extended by deploying new aspects. Moreover, further middleware Web Services can be integrated. Another advantage is the separation of concerns as functional and non-functional code are separated. In addition, the use of XPath allows to quantify over several processes. On the other hand our approach has some limitations w.r.t performance (e.g., the overhead for pointcut matching) and works only for our AO4BPEL engine. As future work, we will provide transaction aspects that allow the BPEL process to be a participant in a transaction. This is needed in many scenarios, e.g., the transfer process may be called as part of another transactional activity such as a rental car booking process that uses the transfer process for payment. Moreover, we will implement appropriate XSLT templates to generate aspects for restoring variable values in case of transaction rollback and for enforcing the variable isolation level serializable. In addition, the business activity port type will be implemented as soon as support for WS-BA is available in Sandesha. Another thrust of future work is to decouple the AO4BPEL language and its implementation from SOAP so that it can be used with the other messaging layers that can underly BPEL..." [cache]

  • [June 25, 2007] "BPEL4People Specifications Integrate Human Interactions Into Business Process." A group of six technology vendors, including Active Endpoints, Adobe, BEA Systems, IBM, Oracle, and SAP AG, announced the publication of two 'BPEL4People' specifications which define an approach for integrating human interactions using Web Services Business Process Execution Language (WS-BPEL) 2.0. In July 2005, IBM and SAP jointly issued a white paper "WS-BPEL Extension for People — BPEL4People." It describes scenarios where users are involved in business processes, and motivates and outlines appropriate extensions to WS-BPEL to address these scenarios. BPEL4People as released in 2007-06 is now comprised of two specifications: "WS-BPEL Extension for People (BPEL4People) Version 1.0" and "Web Services Human Task (WS-HumanTask) Version 1.0". These two specifications take the ideas outlined in the white paper and together provide a concrete realization of them. BPEL4People extends the capabilities of WS-BPEL to support a broad range of human interaction patterns, allowing for expanded modeling of business processes within the WS-BPEL language. WS-BPEL focuses on business processes that orchestrate Web service interactions. However, in general, business processes are comprised of a broad spectrum of activities that most often require the participation of people to perform tasks, review or approve steps and enter data — for example, a credit approval scenario that may require approval on certain transaction limits or activity levels. These human interactions are now addressed in the new BPEL4People specifications. The authors of BPEL4People plan to submit the specifications to OASIS in the near future, and will propose a Technical Committee to produce an OASIS standard based on it.

  • [June 25, 2007] "BPEL4People aims to bridge gap between humans and SOA. BPEL4People standard for SOA-based business processes heads to OASIS." By Rich Seeley. From SearchWebServices.com (June 25, 2007). "Recognizing that service-oriented architecture (SOA) business processes involve people too, a group of vendors today published specifications aimed at extending the Business Process Execution Language (BPEL) 2.0 standard to include human interaction. The BPEL4People specifications will be submitted to the OASIS standards body in the fall, but are ready for developers and architects to download today from the Web sites of the participating vendors, said Ed Cobb, vice president for emerging technologies and standards at BEA Systems Inc. The other vendors supporting the specifications are IBM, Oracle, SAP AG, Adobe Systems Inc. and Active Endpoints Inc. Michael Bechauf, vice president of industry standards at SAP: 'BPEL4People consists of two specifications. WS-BPEL Extension for People layers features on top of the recently approved OASIS WS-BPEL 2.0 standard and describes human tasks as activities that may be incorporated as first-class components in WS-BPEL process definitions. The companion specification, Web Services Human Task, introduces the definition of stand-alone human tasks, including the properties, behavior and operations used to manipulate them. The two specifications are designed so they can either be used together or independently... BPEL4People specification defines a way to integrate tasks that need to be executed by a human user with an SOA-based business process. It introduces the notion of people activity and that of a task that needs to be executed as part of that activity. To date, the BPEL 2.0 standard only defines basic activity types that are related to SOA, which is invoking Web services or receiving a message. The BPEL4People specification adds the ability to request a people activity within an SOA-based business process. Diane Jordan, program manager in emerging Internet standards at IBM and co-chair of the OASIS BPEL technical committee: 'The need to link software-driven business processes to the people who interact with the computer systems was a requirement those working on the original BPEL specification and heard from businesses from the beginning. BPEL4People provides a standard way for SOA-based business processes to communicate with people through alerts and reminders that can be sent to a desktop or even a cell phone... the specifications monitor work queues and also covers events such as reassignment of tasks when an employee is out sick or otherwise unable to continue working on it.'..."

  • [April 09, 2007] "How to Deliver Composite Applications with Java, WS-BPEL, and SOA." By Gopalan Suresh Raj, Prabhu Balashanmugam, and Kevin Schmidt. From SYS-CON Virtualization (April 09, 2007). "The vast adoption of Java technology by the industry in the past decade is a testament to the power of Java. Development of new applications, services, and components using Java is not going away, but many organizations have progressively moved to the next phase in maturing their IT Infrastructure. This phase is driven by many factors including how businesses operate. There are some technologies that are starting to play a critical role in this phase, for example, service-oriented architecture (SOA) is a key enabler. Java EE technology is a natural service-enabler of existing applications, thereby forming the foundation of SOA. Service-enabled applications create the opportunity to compose functions from disparate and cross-functional applications to model business processes that transcend application and enterprise boundaries. Web Services Business Process Execution Language (WS-BPEL) provides a faster way to compose and orchestrate services by reuse. Java and WS-BPEL complement each other perfectly and provide a solid foundation for integrating services and delivering composite applications. This article will briefly explain what these technologies are and how they can work together to improve developer productivity and business agility. The science of delivering composite applications becomes more of an art when architects try to understand when to switch from Java to WS-BPEL. This decision often determines the agility of the composite application..."

  • [February 07, 2007] Aspect-Oriented Workflow Languages: AO4BPEL and Applications. By Anis Charfi. Vom Fachbereich Informatik der Technischen Universitaet Darmstadt. zur Erlangung des akademischen Grades eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte. Dissertation von Diplom-Informatiker. Referent: Prof. Dr.-Ing. Mira Mezini. With abstract. 201 pages. "This thesis focuses on the modularity of workflow process specifications. In particular, it studies the expression support for crosscutting concerns and workflow changes in current workflow languages and workflow management systems. To illustrate the issues, two workflow languages are considered: a visual graph-based language and the Web Service composition language BPEL. This thesis starts by describing the implementation of several crosscutting concerns such as data collection for billing, activity execution time measurement, and security in typical processes of a travel agency. When examining the resulting workflow specifications, the following observations are made. First, the workflow constructs that implement a crosscutting concern cannot be encapsulated in a separate module with a well-defined interface. They are rather scattered across the specifications of several workflow processes. Second, the workflow specifications that result after adding the implementation of a crosscutting concern are tangled. That is, the workflow constructs that implement the business logic are intertwined with the workflow constructs that implement the other concerns... Moreover, this thesis introduces a specific aspect-oriented workflow language for Web Service composition called AO4BPEL. The design and implementation of AO4BPEL can be considered as a proof-of-concept for aspect-oriented workflow languages. This thesis shows using examples how workflow aspects support a better modularization of crosscutting concerns and workflow changes. Moreover, AO4BPEL aspects increase the flexibility and adaptability of BPEL processes, as they can be used to modify BPEL processes at runtime. In addition, this thesis presents two applications of AO4BPEL to show the value and usefulness of aspect-oriented workflow languages. In the first application, a process container framework for providing middleware support to BPEL processes is proposed. In this framework, the non-functional requirements of the process activities such as security, reliable messaging, and transactions are specified declaratively using a deployment descriptor. These requirements are enforced using a process container that is inspired by enterprise component models. The process container is implemented as a light-weight and extensible container using a set of AO4BPEL aspects that are generated automatically from the deployment descriptor. The container calls middleware Web Services to enforce non-functional requirements such as security, reliable messaging, and transactions. These Web Services are implemented by extending Open Source implementations of WS-* specifications such as WS-Security and WS-AtomicTransaction. In the second application, a hybrid approach to Web Service composition is introduced. This approach separates the implementation of the business rules from the BPEL process according to the principles of the Business Rules Approach. At the implementation level, AO4BPEL aspects are used to implement all types of business rules in a separate and modular way..."

  • [December 05, 2006] "Reliable, Secure, and Transacted Web Service Compositions with AO4BPEL." By Anis Charfi, Benjamin Schmeling, Andreas Heizenreder, and Mira Mezini (Software Technology Group, Darmstadt University of Technology). Presented at The Fourth IEEE European Conference on Web Services (ECOWS'06). December 4-6, 2006, Zurich, Switzerland. 10 pages, with 28 references. "Web Service Compositions in BPEL have several nonfunctional requirements such as security, reliable messaging, and transactions. Although many WS-* specifications address such non-functional concerns in the Web Service context, they focus only on the messaging-level requirements without addressing the process-level requirements. In this paper, we discuss different non-functional requirements in BPEL workflows and observe that current orchestration engines lack support for the specification and enforcement of such requirements, especially for process-level requirements. To solve this problem, we present a container framework, which introduces an XML-based deployment descriptor to specify the non-functional requirements in a declarative way. To enforce these requirements, a process container intercepts the process execution and calls dedicated middlewareWeb Services. We implemented the process container as a lightweight container using a set of AO4BPEL aspects that are automatically generated from the deployment descriptor. In addition, we have implemented BPEL middleware Web Services for reliable messaging, security, and transaction." See also about AO4BPEL, "an aspect-oriented extension to BPEL4WS that allows for more modular and dynamically adaptable web service compositions. Aspect-Oriented Programming (AOP) is a paradigm that addresses the issue of modularizing crosscutting concerns in web services compositions such as authorization and authentication, business rules, and persistence. AOP introduces units of modularity called aspects to overcome the inherent problem of code scattering and tangling due to crosscutting concerns in complex systems. Aspects associate sets of join points — well-defined points in the process execution — with additional behaviour defined in an advice. In AO4BPEL, each activity is a potential join point. A collection of related join points is identified by a pointcut — a query over joint points. That is, a pointcut specifies the crosscutting structure of a concern and advice associate behavioural effect to this structure. The pointcut language of AO4BPEL is XPath. That is, XPath expressions are used to select the activities where the advice code should be executed. Pointcuts can span several processes. An advice in AO4BPEL is a BPEL activity that specifies some crosscutting behavior that should execute at certain join points. Like AspectJ, AO4BPEL supports before, after and around advice. The activity of integrating aspects into base functionality is called weaving. A weaver is a tool that integrates a base program's execution with aspects. In the case of AO4BPEL, the base program is the BPEL process and the weaver is an aspect-ware orchestration engine. AO4BPEL supports dynamic weaving, i.e., aspects can be deployed or un-deployed at process interpretation time..."

  • [August 18, 2006] "Business Processes for Web Services: Principles and Applications." By Rania Khalaf, A. Keller, and F. Leymann. From IBM Systems Journal Volume 45, Number 2 (2006). Special Issue: Celebrating 10 Years of XML. Accepted for publication December 7, 2005; Published online May 10, 2006. "The Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) is an XML-based language for defining business processes that provides an interoperable, portable language for both abstract and executable processes and that was designed from the beginning to operate in the heterogeneity and dynamism that is commonplace in information technology today. BPEL builds on the layers of flexibility provided by the Web Services stack, and especially by XML. In this paper, we provide a brief introduction to BPEL with emphasis on architectural drivers and basic concepts. Then we survey ongoing BPEL work in several application areas: adding quality of service to BPEL, extending BPEL to activities involving humans, BPEL for grid computing, and BPEL for autonomic computing..."

  • [February 2006] "A View Based Analysis of Workflow Modeling Languages." By Martin Vasko and Schahram Dustdar. Vienna University of Technology, Distributed Systems Group (DSG), Information Systems Institute, A-1040 Wien, Argentinierstrasse 8/184-1, Austria. Published in the IEEE Proceedings of the 14th Euromicro International Conference on Parallel, Distributed, and Network-Based Processing (PDP 2006). "The different approaches of emerging workflow modeling languages are manifold. Today, there exist many notations for workflow modeling with various specializations on different domains. In this paper we analyze three well known business process (workflow) modeling notations for their support for elaborated key aspects in workflow modeling. The aim of this paper is to discuss their differences and commonalities concerning these aspects. This paper discusses the commonalities and the differences of well known workflow modeling languages: BPEL, BPMN and YAWL... The three analyzed business modeling notations all have their strengths and weaknesses. BPMN is a well elaborated visual modeling notation which provides good support for behavioral aspects of workflow design and is able to map to BPEL4WS. Although it is not extensible to define organizational structures, functional breakdowns, data and informational models and business rules it provides a de-facto standard to model business processes. BPMN is targeted to all business users and tries to close the gap between business process design and business process implementation. BPEL is probably the most frequently used and widely accepted industry business process execution language. It is based on Web Service standards and supports most of the elaborated workflow patterns. The notation has its weaknesses in dealing with data structures and complex control flows. As the process model is based on WSDL it perfectly fits in Web Service architectures. YAWL extends Petri nets by numerous mechanisms and features to enable complex multiple instances workflows and advanced branching and synchronization patterns. BPEL is based on well known web service technologies. Its strengths lie in the good support for workflow patterns and its powerful data structures support by extensive use of XQuery. Regardless it has to penetrate the web service market to unleash its full potential..."

  • [November 09, 2005] "WS-BPEL Language Basics." By Thomas Erl. From 16.1 "Service-Oriented Design Part IV: Business Process Design (Chapter 16)" in Service-Oriented Architecture Concepts, Technology, and Design, described at SOA Systems. Prentice Hall Professional Technical Reference; ISBN; 0-13-185858-0; July 2005. "Step-by-step instructions for building a service-oriented business process are provided in this chapter. A WS-BPEL process definition is created as part of the case study examples to orchestrate services that were modeled and designed in previous chapters. The orchestration service layer provides a powerful means by which contemporary service-oriented solutions can realize some key benefits. The most significant contribution this sub-layer brings to SOA is an abstraction of logic and responsibility that alleviates underlying services from a number of design constraints. For example, by abstracting business process logic: (1) Application and business services can be freely designed to be process-agnostic and reusable. (2) The process service assumes a greater degree of statefulness, thus further freeing other services from having to manage state. (3) The business process logic is centralized in one location, as opposed to being distributed across and embedded within multiple services. In this chapter we tackle the design of an orchestration layer by using the WS-BPEL language to create a business process definition... The Business Process Execution Language for Web Services (BPEL4WS) was first conceived in July, 2002, with the release of the BPEL4WS 1.0 specification, a joint effort by IBM, Microsoft, and BEA. This document proposed an orchestration language inspired by previous variations, such as IBMUs Web Services Flow Language (WSFL) and Microsoft's XLANG specification. Joined by other contributors from SAP and Siebel Systems, version 1.1 of the BPEL4WS specification was released less than a year later, in May of 2003. This version received more attention and vendor support, leading to a number of commercially available BPEL4WS-compliant orchestration engines. Just prior to this release, the BPEL4WS specification was submitted to an OASIS technical committee so that the specification could be developed into an official, open standard. The technical committee is in the process of finalizing the release of the next version of BPEL4WS. It has been announced that the language itself has been renamed to the Web Services Business Process Execution Language, or WS-BPEL (and assigned the 2.0 version number). The changes planned for WS-BPEL have been made publicly available on the OASIS Web site..." [source PDF; see the message]

  • [October 13, 2005] WS-BPEL Extension for Sub-processes — BPEL-SPE. A Joint White Paper by IBM and SAP AG. September 2005. 17 pages. Authors: Matthias Kloppmann (IBM), Dieter Koenig (IBM), Frank Leymann IBM), Gerhard Pfau (IBM), Alan Rickayzen (SAP), Claus von Riegen (SAP), Patrick Schmidt (SAP), and Ivana Trickovic (SAP). "Designing complex and large business processes requires a language that supports modularization and re-use, in a portable, interoperable way. This paper 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 this 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..." [archive/cache]

  • [October 13, 2005]   IBM and SAP AG Release WS-BPEL Extension for Sub-Processes (BPEL-SPE).    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."

  • [September 2005] "Available BPEL Runtime Environments, Evaluation Criteria and Evaluation Results." By Richard Green. Repository Metadata and Management project (RepoMMan) Project Deliverable D-D1. September 2005. RepoMMan aims to "assess the feasibility of automated population of object metadata within an authenticated environment by (a) the extraction of descriptive metadata from simple digital objects, and (b) drawing contextual metadata from existing institutional sources such as a portal profile or an enterprise directory via a Personal Metadata Profile and related profiles mapped to appropriate metadata schema." As of September 2005, the team completed work to identify the BPEL engine and tools to be used in the project. Provisionally, the they selected Active Endpoints. Fedora is a "general purpose repository service devoted to the goal of providing open-source repository software that can serve as the foundation for many types of information management systems. Fedora software demonstrates how distributed digital information management can be deployed using web-based technologies, including XML and web services. Fedora Version 2.0 features include the ability to represent and query relationships among digital objects, a simple XML encoding for Fedora digital objects, enhanced ingest and export interfaces for interoperability with other repository systems, enhanced administrative features, and improved documentation. Fedora is capable of serving as the foundation for many types of information management applications, including institutional repositories, digital libraries, records management systems, archives, and educational software." See: "Fedora Version 2.0 Open-Source Repository Supports XML and Web Services." [cache]

  • [August 26, 2005]   IBM and SAP AG Propose WS-BPEL Extension for People (BPEL4People).    An informal specification describing a proposed extension to the Web Services Business Process Execution Language (WS-BPEL) has been released by IBM and SAP AG in the form of a white paper WS-BPEL Extension for People — BPEL4People. The paper describes business scenarios where users are involved in business processes and defines appropriate extensions to WS-BPEL to address these. The joint authors from IBM and SAP maintain that in order to support a broad range of scenarios that involves people within business processes, a WS-BPEL extension is required. BPEL4People "is defined in a way that it is layered on top of the BPEL language so that its features can be composed with the BPEL core features whenever needed"; additional BPEL extensions may be also be introduced which may use the BPEL4People extensions introduced in the white paper. According to the paper Abstract, "Human user interactions are currently not covered by the Web Services Business Processes Execution Language (WS-BPEL), which is primarily designed to support automated business processes based on Web services. In practice, however, many business process scenarios require user interaction. The spectrum of activities that make up general purpose business processes is much broader than simply activities of which can be assumed to be interactions with Web services with no additional prerequisite behavior. People often participate in the execution of business processes introducing new aspects, such as human interaction patterns. Workflow tools already cater for the orchestration of user interactions." For example, "people can be involved in business processes as a special kind of implementation of an activity — a communication step which may be called people activity. In some scenarios it is desirable to define which people are eligible to start a certain business process. During the lifetime of a long-running business process, conditions that require human involvement can occur; a process may be stuck because no one has been assigned to perform a particular task. In addition to simple task selection and execution actions, there are more complex patterns in the way humans interact with the process instances, and these need to be handled by BPEL4People. Sometimes it is not clear who should perform the task in hand. Escalation takes place if a task does not meet its modeled time constraints. If this occurs, a notification is sent to one or several people specified as escalation recipients using a people assignment definition." A companion article authored by Ivana Trickovic (SAP) provides additional rationale for creating the BPEL4People extension: "Currently there is no standard that spans both the service orchestration and user interactions. Rather then developing a new specification that particularly covers user interactions, SAP and IBM determined that it is most suitable to extend the existing BPEL specification, or more precisely, version 2.0... The BPEL4People extension is layered on top of the BPEL language so that its features can be composed with the BPEL core features. It is envisaged that additional BPEL extensions may be introduced that may in turn use the BPEL4People extension. In this way it can be avoided to build a monolithic specification that would contain numerous features and rather be pursued a more modular approach by building separate extensions on top of the BPEL core features.

  • [March 24, 2005] Dancing with Web services: W3C Chair Talks Choreography." By Nitin Bharti. From SearchWebServices.com (March 09, 2005). "As companies embrace service-oriented architecture, the Business Process Execution Language (BPEL) continues to gain traction as a means to weave Web services into meaningful business processes. While BPEL allows existing services to be orchestrated into composite services, the Web Services Choreography Description Language (WS-CDL) goes a step further and describes the relationships between services in a peer-to-peer scenario. In this interview, Steve Ross-Talbot, co-chair of the W3C Web Services Choreography Working Group, describes choreography and how it differs from orchestration in the context of Web services. He compares the WS-CDL and BPEL specifications, looks at how the two can work together and describes four tools that will be needed to work with WS-CDL. Ross-Talbot: "Any real business transaction isn't just one function call, it's a sequence of function calls and it may be lots of things in parallel between different services that occur. BPEL is about 'how do I construct Web services out of existing Web services.' In other words, BPEL is about the orchestration of existing services to yield another service. Choreography is completely complementary to that. WS-CDL is an unambiguous way of describing the relationships between the services in a peer-to-peer collaboration without necessitating any orchestration at all. That's very important because if my business and your business are talking together, I can guarantee you that neither of us would accept orchestrating the other's services. On the orchestration side of it, which is what BPEL does, that comes in on your side of the firewall and my side of the firewall in order for me to reuse my services. Now I might include in my orchestration, one of your services but then present it as my service; however, I'm really calling out to your service. So with BPEL I'm the conductor in the pit. In any dance, however, you never see somebody on stage telling the dancers what to do. The dancers have a choreography description. I know this because my daughter's a dancer. They learn their dance and they learn the 'touch points' where they interact with others, the same way you do in a choreography description... Orchestration has more to do with the recursive composition of services so that it will yield another service. Orchestration gets realized as an executable, so you can identify the conductor in the pit and realize that he's as much an actor as the violinist. Choreography, on the other hand, is a description. The choreographer writes the descriptions down and gives it to the dancers and works with them to make sure they learn their parts, but he's not there as an 'executable actor' when it's happening. So choreography is purely a description, but it's a description that can be used to generate the behavior of the dancers. You can use it to generate, but it is not executable..."

  • [December 06, 2004] "BPMI.org: 'Not Rivaling' BPEL." By [Jason Stamper]. In Computer Business Review Online (December 06, 2004). "OASIS claimed that fellow standards body BPMI.org's plan to develop BPXL should be seen as complementary to BPEL rather than a rival. Last week ComputerWire broke the news that BPMI.org is planning a new raft of capabilities to extend the power of business process execution language (BPEL), a standard from the OASIS standards group. BPMI.org board member Derek Miers confirmed in an interview with ComputerWire that the standards body is working on what it is calling Business Process eXtension Layers (BPXL), described as a standard that would help to enable interoperability between process modeling tools and process management engines. But in an interview with ComputerWire late last week, OASIS president and CEO Patrick Gannon said that BPXL would complement BPEL, and in no way conflict with it. He said BPEL was never intended to solve every issue in process management: 'The charter for the BPEL work was laid out very explicitly; it was very clear what the work would be. It was not designed to solve all of the problems in the process management space. We are focusing on the core specification first, then we will later produce extensions or profiles, which will be voted on. We will take input from a variety of areas.' Gannon said that work on BPEL had been progressing as planned since it was handed to the group by Microsoft and IBM for ratification. 'BPEL is on track,' he said. 'We have made steady progress since the beginning, and have the support of over 150 participants. It's an 18-24 month process. We started with the initial spec BPEL4WS and we need to make that into an OASIS standard.' It is thought that BPEL will be approved as an OASIS standard around the middle of 2005. Meanwhile Jeanne Baker, chair of BPMI.org, also insisted that the BPXL work is in no way intended to derail or rival BPEL: 'We endorse BPEL and we endorse OASIS,' said Baker. 'The industry needs a single standard, not a confusion of standards.' But she added that BPMI.org's planned Business Process eXtension Layers (BPXL) standard will add capabilities not inherent in BPEL..."

  • [November 29, 2004] "BPMI.org Confirms Plans to Expand BPEL." By Jason Stamper [ComputerWire], in Computer Business Review Online (November 29, 2004). [Clarification on this report of the BPMI.org plan: see preceding bibliographic entry.] "Standards Organization the Business Process Management Initiative (BPMI.org) has confirmed it is planning work on a whole new raft of capabilities to extend the power of business process execution language (BPEL), a standard from the OASIS standards group... BPMI.org board member Derek Miers confirmed in an interview with ComputerWire that the standards body is working on what it is calling Business Process eXtension Layers (BPXL), a standard that would help to enable interoperability between process modeling tools and process management engines. 'We need to do this because it is clear that going through the OASIS Technical Committee process that developed BPEL would be too much of a long, drawn-out process,' said Miers. 'We're hoping to get a number of technical architects together to work on the eXtension Layers, to get a concerted effort across the group, perhaps with each member doing four or five days work on this per month.' Miers said that he does not yet have a final list of the vendors likely to come together to work with BPMI.org on the BPXL extensions layer. As reported by ComputerWire, BPMS vendor CommerceQuest has thrown its support behind the initiative. Miers said the likely candidates would be fellow BPMS companies like Tibco/Staffware, FileNet, Pegasystems, Chordiant, and 'even IBM'. IBM is perhaps a less likely supporter, because IBM and Microsoft were the driving forces behind BPEL. Miers said he is hoping that interested parties will attend the Think Tank event to find out more and come to some consensus of what needs to be done to take BPEL to the next level..." See the BPM Think Tank and Member Meeting, scheduled for March 1-3 2005, Miami, FL. Working Day (March 3, 2005) will cover Business Process Extension Layers (BPXL) [human collaboration, transactions, roll- back, mobility etc] and Business Process Query Language (BPQL) [ability to query and report on the status of business process instances, incorporating appropriate security]...; also, "BPMI.org Phase 2: Insight, Innovation, Interoperability" (BPMI.org Board of Directors, June 9, 2004), pages 9-10: The 'Standard BPM Stack' includes an overview of BPXL [Business Process eXtension Layers] which "extends BPEL4WS 1.1 to cover Transactions, Business Rules, Task Management, Human Interactions; BPXL is a Standard Set of Extensions for BPEL, Covers Transactions, Business Rules, Task Management, etc.; Defined using BPEL's standard extension mechanisms..."

  • [October 27, 2004] "New Members Join JAVA Business Integration Specification Effort." - "Sun Microsystems, Inc., the creator and leading advocate of Java technology, today joined with Java technology leaders to announce the availability of the Early Draft Review of the Java Business Integration (JBI) specification, Java Specification Request (JSR) 208. The group also announced that Apache Group, IONA and JBoss have joined the effort dedicated to developing an open standard for business integration on the Java platform. The specification extends the Java platform to incorporate standardized integration capabilities, and marks an important milestone in enabling Java technology use based on service-oriented architecture (SOA). The JSR 208 project, which is chaired by Sun, is being jointly developed through the Java Community Process (JCP) program by over 22 prominent vendors, and individual developers of Integration and Java 2 Enterprise Edition (J2EE) technology, including Novell, Oracle, SAP AG, SeeBeyond, Sonic Software, Sybase Inc., TIBCO Software, and webMethods Inc. Today Apache, JBoss, and IONA announced they have joined the JSR 208 Expert group. 'The goal of the Java Business Integration initiative is to do for the integration space what J2EE did for the field of Java application development and deployment; namely, deliver the benefits of choice, flexibility, interoperability, code reuse, reduced complexity, and lower cost', said Mark Bauhaus, vice president of Java, Web Services at Sun. 'The Early Draft Review of JSR 208 shows our commitment to develop this technology in an open and standards-based way through the Java Community Process.' Implementations based on JBI will help to provide IT organizations with higher levels of portability and reuse of integration technologies not achievable with many of today's integration products. Java Business Integration components such as business process engines based on the BPEL specification, rules engines, and routing and transformation engines from multiple vendors can be easily combined into a single solution, reducing the cost of application integration and enabling best-of-breed solutions... The Early Draft of the JSR 208 specification is available today at http://www.jcp.org for industry comment. It defines a unified, pluggable architecture for building integration technology on the Java platform and specifies standard interfaces for integration components like BPEL engines, transformation engines, or routing engines, to be plugged seamlessly into an integration container. JBI gives customers the ability to assemble a best-of-breed solution, or to extend their integration solutions by adding new integration components..." See also: (1) JSR 208: Java Business Integration (JBI); (2) "Business Process Execution Language for Web Services (BPEL4WS)."

  • [July 05, 2004] "An Approach to Extract RBAC Models from BPEL4WS Processes." By Jan Mendling, Mark Strembeck, Gerald Stermsek, and Gustaf Neumann (Department of Information Systems, New Media Lab, Vienna University of Economics and BA, Austria). Presented at the Second International Workshop on Distributed and Mobile Collaboration (DMC 2004), June 14, 2004. Published in Proceedings of the Thirteenth IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises (WET ICE 2004), Modena, Italy). 6 pages (with 23 references). "The Business Process Execution Language for Web Services (BPEL) has become the defacto standard for Web Service composition. Yet, it does not address security aspects. This paper is concerned with access control for BPEL based processes. We present an approach to integrate Role-Based Access Control (RBAC) and BPEL on the meta-model level. Moreover, we show that such an integration can be used to automate steps of the role engineering process. In particular, we extract RBAC models from BPEL processes and present an XSLT converter that transforms BPEL code to the XML import format of the xoRBAC software component. Our work is motivated by two main facets. First, BPEL does not address access control measures although access control is an important and integral aspect of business processes. Second, role engineering is a time-consuming task and can be made more efficient through an integration with business process modeling. We use the mappings between RBAC and BPEL to automate steps of the scenario-driven role engineering process presented in A Scenario-driveen Role Engineering Process for Functional RBAC Roles (2002)... With our approach we aim to enhance the security features of Business Process Management Systems that operate via Web Services. Moreover, our approach provides for more efficient role engineering as it automates steps of the scenario-driven role engineering process. Finally, as RBAC and process models are highly interrelated, automation in role engineering also facilitates consistency between the deployed business processes and corresponding RBAC policies. In our future work we implement an RBAC-aware BPEL engine that reflects the findings of this paper. In particular, the implementation will build on an integrated metamodel of BPEL and RBAC. Another interesting aspect for future work is the continued integration of role engineering activities with BPEL-based processes..." [cache]

  • [June 30, 2004]   Oracle BPEL Process Manager Provides SOA and Integration Platform Support.    At the JavaOne 2004 Conference, Oracle announced the immediate availability of the Oracle BPEL Process Manager, provided free on the Oracle Technology Network for download and evaluation. The Business Process Execution Language (BPEL) is being developed within the OASIS Web Services Business Process Execution Language Technical Committee, chartered to continue work on the business process language published in the April 2002 Business Process Execution Language for Web Services (BPEL4WS) specification. Based upon Oracle's acquisition of Collaxa Inc. and the Collaxa BPEL Server, the Oracle BPEL Process Manager provides a "complete Service Oriented Architecture (SOA) and integration platform, makeing it easier for organizations to coordinate Web services and automate business processes." The Oracle BPEL Process Manager "is a new addition to the Oracle product portfolio, enabling enterprises to model, deploy and manage BPEL processes. It comprises an easy-to-use BPEL modeler, a scalable BPEL engine, an extensible WSDL binding framework, a monitoring console and a set of built-in integration services (transformation, user task, java embedding). It offers native and comprehensive BPEL support, ease-of-use, and cross-platform support." The Oracle BPEL Process Manager, "hailed as the best BPEL implementation on the market, enables organizations to easily implement adaptive transactions and collaborative business processes based on composite applications. The solution includes an engine for executing business processes, a console to monitor, manage and debug business processes and a rich graphical interface to design and build business processes. With its native BPEL engine, Collaxa provided organizations such as the European Space Agency, SAIC and British American Tobacco the most open means for executing business processes written in BPEL. When coupled with Oracle Application Server 10g, this native BPEL engine completes Oracle's comprehensive SOA and integration platform."

  • [June 28, 2004] "Analysis of Interacting BPEL Web Services." By Xiang Fu, Tevfik Bultan, and Jianwen Su (Department of Computer Science, University of California, Santa Barbara, CA). Pages 621-630 (with 27 references) in Proceedings of the Thirteenth World Wide Web Conference (WWW 2004) held in New York City, May 17-22, 2004. "This paper presents a set of tools and techniques for analyzing interactions of composite web services which are specified in BPEL and communicate through asynchronous XML messages. We model the interactions of composite web services as conversations, the global sequence of messages exchanged by the web services. As opposed to earlier work, our tool-set handles rich data manipulation via XPath expressions. This allows us to verify designs at a more detailed level and check properties about message content. We present a framework where BPEL specifications of web services are translated to an intermediate representation, followed by the translation of the intermediate representation to a verification language. As an intermediate representation we use guarded automata augmented with unbounded queues for incoming messages, where the guards are expressed as XPath expressions. As the target verification language we use Promela, input language of the model checker SPIN. Since SPIN model checker is a finite-state verification tool we can only achieve partial verification by xing the sizes of the input queues in the translation. We propose the concept of synchronizability to address this problem. We show that if a composite web service is synchronizable, then its conversation set remains same when asynchronous communication is replaced with synchronous communication..."

  • [May 01, 2004] "BPEL Unleashed: Putting a Modern Business Process Execution Standard to Work." By Doron Sherman (CTO, Collaxa, Inc). In Web Services Journal (April 30, 2004). "BPEL (Business Process Execution Language) makes business processes and composite Web services first-class citizens of the Java and .NET platforms, while preventing vendor lock-in. The result is a drastic reduction in the complexity, delivery time, and cost associated with implementing workflow, BPM (business process management), and related business integration projects. BPEL is a new standard for implementing business processes in an emerging service-oriented architecture world. As such, applying BPEL introduces new considerations, challenges, and pitfalls for delivering process-aware applications based on a service-oriented architecture (SOA)... Customer inquiries indicate that a growing number of end users are evaluating the use of BPEL for mission-critical projects. Such evaluations typically involve a technical hands-on product evaluation, a proof of concept, and sometimes an initial production deployment to prove the maturity and ROI of the approach. At this stage of adoption, many prospects are still discovering the proper criteria for evaluating BPEL tools and engines and treating their early implementations using BPEL as a stepping stone to more mission-critical applications... BPEL is on its way to becoming the cornerstone of SOA implementations in an enterprise environment, responsible for coordinating disparate resources and services into end-to-end business processes. The explicit XML-based representation of the BPEL process allows for extensive management, reporting, and analysis functions to be added on top of the process execution layer. These functions can be provided by the BPEL engine vendor of choice, or by ISVs who provide value-add components that can enhance an overall solution structured around a BPEL engine. While some of these value-added functions are available in commercial BPEL implementations today, we believe that this is just the tip of the iceberg. The next 12 months should be very interesting and offer significant ROI opportunities for the companies that are ready to move to business process management with BPEL..." Earlier article: "BPEL: Make Your Services Flow. Composing Web Services into Business Flow."

  • [April 27, 2004]   W3C Publishes Web Services Choreography Description Language (WS-CDL).    An initial Public Working Draft of the Web Services Choreography Description Language Version 1.0 has been released by W3C. This document, the first in a series of WS-CDL working drafts, has been produced by members of the W3C Web Services Choreography Working Group as part of the Web Services Activity. The WS-CDL XML-based language "describes peer-to-peer collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior, where ordered message exchanges result in accomplishing a common business goal. The Web Services Choreography specification is targeted for composing interoperable peer-to-peer collaborations between any type of Web Service participant regardless of the supporting platform or programming model used by the implementation of the hosting environment." According to the W3C announcement, the Web Services Choreography Description Language is a "necessary complement to end point languages such as BPEL and Java. WS-CDL provides them with the global model they need to ensure that end point behavior — the 'rules of engagement' — is consistent across cooperating services. Business transactions, especially those envisioned by Web services, grow from complex interactions. These interactions can be viewed from a variety of points in the transaction chain, not simply the start or the expected endpoint. Modeling these interactions from a global viewpoint allows software developers to take into account the distributed race conditions (unexpected dependence on the sequence of events) that may exist — in much the same way they exist in non-Web business processes. Choreography provides the set of rules that explains how different components may act together, and in what sequence, giving a flexible systemic view of the process."

  • [April 26, 2004] "Countdown to BPEL Begins - A Dev's FAQ." By Vance McCarthy. In Integration Developer News (April 26, 2004). "Controversy may be giving way to simple heads-down hard work when it comes to BPEL4WS, the proposed orchestration standard for web services supported by both Java and .NET vendors. Leading J2EE app server vendors BEA and IBM have jointly proposed extensions to BPEL (Business Processing Execution Language) to make the standards implementable within Java/J2EE environments. BPELJ is 'a reflection that BPEL will happen, and we hope it will happen this year. Too many vendors want it to happen,' Stephen Hood, BEA product manager for WebLogic Integration, told Integration Developer News. Further, Hood told IDN, 'BEA will write and provide a reference implementation of BPELJ. Depending on demand and the evolution of the specification, we will also consider making this implementation open source and royalty-free. We're very serious about it. We want this to be very portable across the Java platform.' To get more perspective in BPELJ, IDN spoke in depth with BEA's Hood. He addresses the genesis of BPELJ, how it will help developers implement BPEL, and what assurances are in place to make sure that BPELJ doesn't undo any interoperability between Java and .NET orchestration... BPELJ is a joint submission from IBM and BEA that will amend JSR 207 within the Java Community Process (JCP). The proposed extensions in BPELJ will enable Java and BPEL to cooperate by allowing sections of Java code, called Java snippets, to be included in BPEL process definitions. Snippets are expressions or small blocks of Java code that can be used for things such as, but not limited to, the following: Loop conditions; Branching conditions; Variable initialization; Web service message preparation; and Logic of business functions. In addition, BPELJ enables J2EE developers to create business processes that include both web services and currently existing traditional J2EE business components..."

  • [April 21, 2004] "Universal Application Network and Siebel Business Integration Applications Help Leading Organizations Achieve Unprecedented Success. UAN Unlocks Departmental Information and Creates End-to-End Business Processes for Improved Customer Satisfaction and Business Efficiency." - "Siebel Systems, a leading provider of business applications software, today announced at Siebel User Week 2004 significant customer successes, increased partner momentum, a continued demonstrated commitment to open standards, and expanded industry-specific business integration applications for Universal Application Network (UAN). UAN is a standards-based architecture for business integration that eliminates the cost and complexity associated with traditional integration methods by delivering pre-packaged business integration applications that run on leading integration servers. With UAN, companies can leverage their existing IT investments; deploy best-in-class applications; and streamline their business processes across departments, partners, vendors, and IT systems — unlocking customer data and distributing it throughout the enterprise. 'Business application integration is a significant issue for organizations with IT infrastructures that, on average, are chartered with supporting from 50 to 100 different technology systems,' said Nimish Mehta, Group Vice President, Universal Application Network, Siebel Systems. 'Due to the cost and complexity associated with integration, companies have historically been unable to integrate systems that would result in providing better and more aligned customer service and sales support. Siebel Systems and its partners share a vision of providing integration as a customer-centric, out-of-the-box solution with pre-built, industry-specific functionality. We are pleased that many leading global organizations have realized firsthand the business benefits gained by deploying UAN.' To support this growth and drive superior business performance, Siebel Systems and its partners today announced that its library of UAN-compliant Siebel Business Integration Applications (BIAs) now includes 165 cross-industry and industry-specific processes. Siebel Systems has also continued to demonstrate its commitment to open XML and Web Services standards by ensuring that UAN and Siebel BIAs support the latest version of Business Process Execution Language (BPEL 1.1). Siebel Systems is among the first enterprise software companies to express processes based on the BPEL 1.1 specification..."

  • [April 15, 2004] "Using BPEL4WS in a UDDI Registry." By Claus von Riegen and Ivana Trickovic (SAP). OASIS UDDI Spec Technical Committee. Draft Technical Note. Document identifier: 'uddi-spec-tc-tn-bpel-20040415.doc'. April 15, 2004. 24 pages. "BPEL4WS abstract processes complement abstract WSDL interfaces describing behavioral aspects of Web services and providing data needed for integration with business partners. Abstract processes are used to specify the order in which business partners may invoke operations. Therefore it may be also of interest to exchange abstract processes between business partners. Software companies and standards bodies may use a UDDI registry to publish different types of services and business users may populate the registry with descriptions of services they support. BPEL4WS and WSDL may be used to describe service types, protocols that are supported and other deployment details. While it is certainly possible to publish BPEL4WS process definitions in a UDDI registry, no guidelines are available as of today, which specify a common approach for doing that. Without such a common approach, the certainty that users find BPEL4WS process definitions or Web services that implement a given part of such a definition is limited. This technical note provides guidelines for publishing BPEL4WS abstract processes in UDDI. The primary goals of mapping BPEL4WS artifacts to the UDDI model are to: (1) enable the automatic registration of BPEL4WS definitions in UDDI; (2) enable optimized and flexible UDDI queries based on specific BPEL4WS artifacts and metadata; (3) provide composability with the mapping described in the Using WSDL in a UDDI Registry, Version 2 Technical Note document..." See also "Universal Description, Discovery, and Integration (UDDI)." [source .DOC]

  • [April 12, 2004] "BPELJ: BPEL for Java. A Joint White Paper by BEA and IBM." March 2004. By Michael Blow (BEA), Yaron Goland (BEA), Matthias Kloppmann (IBM), Frank Leymann (IBM), Gerhard Pfau (IBM), Dieter Roller (IBM), and Michael Rowley (BEA). Copyright (c) BEA Systems, Inc. and International Business Machines Corp 2004. 24 pages. With overview. "The Web Services Business Process Execution Language (BPEL) is a programming language for specifying business processes that involve Web services. BPEL is especially good at supporting long-running conversations with business partners. Even before the standard is formally released it is becoming clear that BPEL will be the most widely adopted standard for business processes involving Web services. BPEL is geared towards 'programming in the large', which supports the logic of business processes. These business processes are self-contained applications that use Web services as activities that implement business functions. BPEL does not try to be a general-purpose programming language. Instead, it is assumed that BPEL will be combined with other languages, which are used to implement business functions ('programming in the small'). This white paper proposes a combination of BPEL with Java, named BPELJ, that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best. BPELJ enables Java and BPEL to cooperate by allowing sections of Java code, called Java snippets, to be included in BPEL process definitions. Snippets are expressions or small blocks of Java code that can be used for things such as: loop conditions, branching conditions, variable initialization, Web service message preparation, logic of business functions etc. BPELJ introduces a few minor changes to BPEL as well as several extensions in order to fit BPEL and Java conveniently together; the changes to BPEL are listed in the appendix. However, if any of these changes are not accepted, BPELJ will use existing features of BPEL, with a somewhat more awkward result. BPELJ extensions are introduced via extension points defined in the BPEL standard to provide the new functionality. A BPELJ process will execute on any platform that supports the BPELJ extensions to BPEL. Note especially, that BPELJ does not include any extensions that are required for all BPELJ processes, so any BPEL process is a valid, executable BPELJ process. In addition to making it possible to use Java to do the computational work of a business process, BPELJ also makes it possible to use BPEL to orchestrate long-running interactions with J2EE components. There is a lot of business logic that is currently deployed in Java components and BPELJ makes it possible to create business processes that include these components as well as Web services within the same business process..." [cache]

  • [April 12, 2004] "Java, BPELJ Hailed. J2EE 1.4 Boosters to Gather." By Paul Krill. In InfoWorld (April 09, 2004). "Java is getting promotional boosts in the form of a gathering of vendors touting the latest Java specification and a whitepaper pertaining to BPELJ (Business Process Execution Language for Java), which links Java and Web services business processes. Java proponents will hold a unity-driven 'J2EE 1.4 Kickoff' media and analyst event in San Francisco on April 26, 2004, featuring speakers from Sun Microsystems, IBM, and even JBoss, which had been at odds with Sun over licensing of Java. he event is designed to showcase unity in the J2EE marketplace around J2EE 1.4, which has been cited as the Web services-based version of Java. J2EE 1.4 was approved in November. Scheduled to appear at the event are John Fowler, Sun CTO; Mark Bauhaus, vice president of Java Web services at Sun; George Paolini, vice president and general manager of Java solutions at Borland; Ted Farrell, chief architect and senior director of strategy for application development tools at Oracle; Steve Harris, vice president of the Java Platform Group at Oracle; and Mark Fleury, CEO and founder of open source Java application server provider JBoss. Also slated to attend are Mike McHugh, vice president of engineering at WebLogic Server at BEA Systems, and Mark Heid, program director for WebSphere at IBM. Sun and JBoss had had their differences pertaining to JBoss' licensing of the Java certification test suite and the expense involved. The two have since settled their differences. In addition to appearing at the J2EE 1.4 event, JBoss also will make a first-ever appearance at the JavaOne conference in San Francisco in June. BEA Systems and IBM, meanwhile, have published a white paper on BPELJ, which enables Java and BPEL to be used together to build business process applications..."

  • [March 15, 2004] "Specification and Validation of the Business Process Execution Language for Web Services." By Roozbeh Farahbod, Uwe Glässer, and Mona Vajihollahi. SFU-CMPT-TR-2003-06 (revised). Draft version 2.5. February 27, 2004. "We formally define an abstract executable semantics for the Business Process Execution Language for Web Services in terms of a distributed ASM. The goal of this work is to support the design and standardization of the language. 'There is a need for formalism. It will allow us to not only reason about the current specification and related issues, but also uncover issues that would otherwise go unnoticed. Empirical deduction is not sufficient.' from Issue #42, OASIS WSBPEL TC. The language definition assumes an infrastructure for running Web services on some asynchronous communication architecture. A business process is built on top of a collection of Web services performing continuous interactions with the outside world by sending and receiving messages over a communication network. The underlying execution model is characterized by its concurrent and reactive behaviour making it particularly difficult to predict dynamic system properties with a sufficient degree of detail and precision under all circumstances... The next revision of this technical report will further extend the current model by including additional aspects of BPEL, beyond the key aspects of the language core, as well as a number of improvements on the overall organization of the formal model."

  • [September 05, 2003] "IBM Exec Touts Need for BPEL Support, SOAs." By Barbara Darrow and Elizabeth Montalbano. In CRN (September 02, 2003). "Now that many plumbing issues have been sorted out, it's time to bring business process integration, transaction support and systems management into the Web services realm, according to one IBM executive. Toward that end, IBM is building BPEL (Business Process Execution Language) support--as well as WS-Security support--into its WebSphere application server, Tivoli systems management and other IBM products, said Bob Sutor, director of WebSphere Infrastructure Software for IBM Software. IBM already supports SOAP, WSDL and UDDI in most of its middleware software. BPEL is an emerging specification that would give programmers a way to formally describe processes underlying business applications so that they can be exposed and linked to processes in other applications. IBM and Microsoft submitted the spec to the Organization for the Advancement of Structured Information Standards (OASIS) for approval. For a while it appeared that BPEL was on a collision course with another specification effort backed by Oracle and others and winding its way through the World Wide Web Consortium (W3C) but those two efforts now appear to be converging. IBM is not the only vendor beating the BPEL drum. Microsoft has said that BPEL support will be built into upcoming BizTalk Server... 'In the next six months, I see a big focus on transactions and systems management, not just a lot of yelling and screaming,' Sutor said. Vendors, customers and solution providers now have to sort out where traditional in-house systems management ends and Web services management begins, Sutor told CRN. Sutor also said he sees a growing need for BPEL support and the adoption of service-oriented architectures, a move to more modular, loosely coupled application development. Service Oriented Architectures, or SOAs, are the latest incarnation of the distributed object architectures, exemplified by the older heterogeneous CORBA (Common Object Request Broker Architecture) and Microsoft-centric DCOM (Distributed Component Object Model) worldviews... IBM insists that its game plan will preserve existing investments in legacy applications, and claims that Microsoft's .Net worldview requires companies to rip and replace older applications and infrastructure. Instead of junking things, why not replace 'green screens' with Web interfaces, Sutor said. 'CICS has worked great for 35 years, why throw it out? Microsoft's model is to yank everything out even if it's [just] three or four years old. Well now they're seeing resistance to that from customers.' Of course, IBM, unlike Microsoft, stands to reap huge services revenue from knitting together diverse systems. IBM Global Services (IGS) makes billions doing just that..." See: "Integrating CICS Applications as Web Services. Extending the Life of Valuable Information."

  • [August 27, 2003] "BPEL and Business Transaction Management: Choreology Submission to OASIS WS-BPEL Technical Committee." By Tony Fletcher, Peter Furniss, Alastair Green, and Robert Haugen (Choreology Ltd). Copyright (c) Choreology Ltd, 2003, subject to OASIS IPR Policy. Working paper presented to the OASIS Web Services Business Process Execution Language Technical Committee. "An overall motivation for this submission is given in an article by one of the authors, Alastair Green, in the September issue of Web Services Journal (see following bibliographic entry). From the 27-August-2003 posting of Peter Furniss: "... [WRT] the announcements of a raft of issues on "business transaction management". These all relate to the long-promised submission from Choreology on how to handle transactions in BPEL... The submission gives the background and context for the BTM issues and proposes syntax constructs as solutions for [items] 54 to 59" in the issues list... "BTM Issue A (BPEL issue 53), Desirable for WS-BPEL to include Business Transaction Management (BTM) programming constructs which are compatible with WS-T, BTP and WS-TXM, "There are three multi-vendor specifications which address the needs of business transaction management for Web Services: Business Transaction Protocol 1.0 (OASIS Committee Specification, June 2002); WS-Transaction (proprietary consortium, August 2002), and the very recently published WS-TXM (proprietary consortium, August 2003). In our view BTP Cohesions, WS-T Business Activity, and WS-TXM Long-Running Actions are the most relevant aspects of these specifications for WS-BPEL. These aspects overlap to a very high degree, each effectively utilizing a two-phase (promise/decide) outcome protocol. (We should emphasize that there has been little time to analyze or assimilate WS-TXM, so this is a provisional conclusion with respect to that specification). WS-BPEL should be equipped with the ability to create and terminate business transactions, and to define process participation in such transactions, in a way which is compatible with the intersection of these three capabilities. This will minimize dependence on future standardization efforts in the BTM area... It is should be noted that a 'business transaction' is normally performed in support of some economic transaction -- that it coordinates actions that have an effect on the parties and their relationships that go beyond the lifetime of the transaction itself. Since a BPEL process cannot directly manipulate data with a lifetime longer than the process, but always delegates to a web-service, the invoked web-services will either themselves be participants in the business transaction (strictly, the invocation will trigger the registration of participants) or the BPEL process will register as a participant and then make non-transaction invocations on other web-services. In the former case, the invoked web-services are 'business-transaction aware'; the BPEL process will export the context to it and the web-services will implement the transactional responsibilities internally. Similarly, a BPEL process, as an offerer of a web-service, may import a context from a non-BPEL application -- in which case it is itself a business-transaction aware web-service from the perspective of its caller -- and either registers as a participant or passes the context on in its own invocations..."

  • [August 26, 2003] "Transacting Business with Web Services, Part I. The Coming Fusion of Business Transaction Management and Business Process Management." By Alastair Green (Choreology Ltd). In WebServices Journal Volume 3, Issue 9 (September 2003), pages 32-35. "Business transaction management (BTM) is a promising new development in general-purpose enterprise software. Most large companies are devoting significant resources to the problem of reliable, consistent integration of application services. BTM offers previously inaccessible levels of application coordination and process synchronization, radically simplifying the design and implementation of transactional business processes. Business process management (BPM) needs to be enriched by BTM for users to see the potential value of BPM realized in practice. XML is already widely deployed as a useful lingua franca enabling the creation of canonical data standards for particular industries, trading communities, and information exchanges. The extended family of Web services standards (clustered around the leading duo of SOAP and WSDL) is gaining growing acceptance as an important way of providing interoperable