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 connectivity between heterogeneous systems. Many organizations are also examining the use of BPM technologies, exemplified by the current OASIS initiative, Web Services Business Process Execution Language (WS BPEL). Increasingly, attention is turning to the special problems associated with building transactional business processes and reliable, composable services. This is where BTM technology comes into its own. In this article I'm going to look at the rationale for and current status of BTM, and how vendors and users are thinking about the integration or fusion of BTM with BPM, particularly in the OASIS BPEL standardization effort. BPEL, as a special-purpose programming language designed to make processes portable across different vendors' execution engines, can become a very useful standard programming interface for business transactions in the Web services world... Full-scale BTM software needs to implement interoperable protocols that define three phases of any transactional interaction, whether integrating internal systems, or automating external trades and reconciliations: (1) Phase One: Collaborative Assembly: The business-specific interplays of messages that assemble a deal or other synchronized state shift in the relationship of two or more services. A useful general term for such an assemblage of ordered messages is collaboration protocol. Examples include RosettaNet PIPs, UN/Cefact trade transactions, and the FIX trading protocol. In the future, BPEL abstract processes should help greatly in defining such protocols. Reliable messaging has an important role in this assembly phase, but as a subordinate part of a new, extended concept of GDP (guaranteed delivery and processing). (2) Phase Two: Coordinated Outcome: The coordination of an outcome that ensures that the intended state changes occur in all participant systems, consistent with the business rules or contracts which govern the overall transaction. Examples of relevant coordination protocols are WS-Transaction (Atomic Transaction and Business Activity, supplemented by WS-Coordination) and BTP (the OASIS Business Transaction Protocol) and the recently released WS-TXM (Transaction Management, part of the WS-Composite Application Framework). A coordination protocol requires three related sub-protocols: a control protocol, which creates and terminates a coordination or transaction (present in BTP); a propagation protocol, which allows a unique transaction identity to be used to bind participating services to a coordination service (this sub-protocol is mostly defined by WS-Coordination); and an outcome protocol, which allows a coordination service to reliably transmit the instructions of a controlling application to the participants, even in the event of temporary process, processor or network failures. WS-T, BTP, and WS-TXM, contain very similar outcome protocols... (3) Phase Three: Assured Notification: Notification of the result of the transaction to the parties involved, ensuring that they're all confident of their final relationship to their counterparties. Ideally, this requires a reliable notification protocol, which allows the different legal entities or organizational units to receive or check the final outcome, including partial or complete failures..." [alt URL]

  • [August 25, 2003] "Goals of the BPEL4WS Specification." By Frank Leymann, Dieter Roller, and Satish Thatte. Working document submitted to the OASIS Web Services Business Process Execution Language TC. See the posting from Diane Jordan and the original posting, with attachment. The memo articulates ten (10) overall goals of the "original" BPEL4WS Specification, presented as a record of the "Original Authors' Design Goals for BPEL4WS." It covers: Web Services as the Base, XML as the Form, Common set of Core Concepts, Control Behavior, Data Handling, Properties and Correlation, Lifecycle, Long-Running Transaction Model, Modularization, and Composition with other Web Services Functionality. "This note aims to set forward the goals and principals that formed the basis for the work of the original authors of the BPEL4WS specification. The note is set in context to reflect the considerations that went into the work, rather than being presented as a set of axioms. Much of this material is abstracted from comments and explanations embedded in the text of the specification itself. This is intended to be informative and a starting point for a consensus in the WSBPEL TC for the work of the TC. The goals set out here are also reflected in the charter of the WSBPEL TC... BPEL4WS is firmly set in the Web services world as the name implies. In particular, all external interactions occur through Web service interfaces described using WSDL. This has two aspects: (1) the process interacts with Web services through interfaces described using WSDL and (2) the process manifests itself as Web services described using WSDL. We concluded that although the binding level aspects of WSDL sometimes impose constraints on the usage of the abstract operations, in the interests of simplicity and reusability we should confine the exposure of process behavior to the 'abstract' portType (i.e., 'interface') level and leave binding and deployment issues out of the scope of the process models described by BPEL4WS. The dependence is concretely on WSDL 1.1, and should remain so, given the timeline for the WSBPEL TC, and the likelihood that WSDL 1.1 will remain the dominant Web service description model for some time to come. At the same time we should be sensitive to developments in WSDL 1.2 and attempt to stay compatible with them..." Note from Satish Thatte's post: "As promised, the goals document is attached. As I said during the last phone meeting, this document only covers high level design points... If TC members feel that there are any important aspects not yet covered here please let us know and we will try to address those concerns..."

  • [July 29, 2003] "Introducing BPEL4WS 1.0. Building on WS-Transaction and WS-Coordination." By Dr. Jim Webber and Dr. Mark Little (Arjuna Technologies Limited). In Web Services Journal Volume 3, Issue 8 (August 2003), pages 28-33. With source code and 3 figures. "The value of BPEL4WS is that if a business is the sum of its processes, the orchestration and refinement of those processes is critical to an enterprise's continued viability in the marketplace. Those businesses whose processes are agile and flexible will be able to adapt rapidly to and exploit new market conditions. This article introduces the key features of Business Process Execution Language for Web Services, and shows how it builds on the features offered by WS-Coordination and WS-Transaction. The BPEL4WS model is built on a number of layers, each one building on the facilities of the previous. The fundamental components of the BPEL4WS architecture consists of the following: (1) A means of capturing enterprise interdependencies with partners and associated service links; (2) Message correlation layer that ties together messages and specific workflow instances; (3) State management features to maintain, update, and interrogate parts of process state as a workflow progresses; (4) Scopes where individual activities (workflow stages) are composed to form actual algorithmic workflows. We'll explore the features of this stack, starting with the static aspects of the application -- capturing the relationship between the Web services participating in workflows -- and on to the creation of workflows using the BPEL4WS activities... BPEL4WS is at the top of the WS-Transaction stack and utilizes WS-Transaction to ensure reliable execution of business processes over multiple workflows, which BPEL4WS logically divides into two distinct aspects. The first is a process description language with support for performing computation, synchronous and asynchronous operation invocations, control-flow patterns, structured error handling, and saga-based long-running business transactions. The second is an infrastructure layer that builds on WSDL to capture the relationships between enterprises and processes within a Web services-based environment. Taken together, these two aspects support the orchestration of Web services in a business process, where the infrastructure layer exposes Web services to the process layer, which then drives that Web services infrastructure as part of its workflow activities. The ultimate goal of business process languages like BPEL4WS is to abstract underlying Web services so that the business process language effectively becomes the Web services API. While such an abstract language may not be suitable for every possible Web services-based scenario it will certainly be useful for many, and if tool support evolves it will be able to deliver on its ambition to provide a business analyst-friendly interface to choreographing enterprise systems..." See also: "Introducing WS-Transaction Part II. Using Business Activities," in Web Services Journal Volume 3, Issue 7 (July 2003), pages 6-9. [alt URL]

  • [July 08, 2003] "In the Service of Cooperation." By Kendall Grant Clark. From O'Reilly WebServices.xml.com (July 08, 2003). "When considering what the top of the web services stack might eventually look like, it becomes clear that the higher one goes, the closer one gets to 'the user' or 'the business process' and the further away one gets from the network and the machine. But the idealized web services stack is not only describable in terms of spatializing metaphors (viz., height and depth) but also in terms of stratifying ones (viz., layers and levels)... we are entering a period during which the various layers of the top of the web services stack are starting to be shuffled into place. I date the inauguration of this period from the point at which BPEL (BPEL4WS) was moved into an OASIS TC for formal standardization... The comment most frequently made in the wake of OASIS taking BPEL into its fold was that BPEL had already won the battle in this period of high-level web services shakeout. But that comment is as wrong as it is glib. And it's wrong for a variety of reasons: first, it's not clear that there has to be a single winner, since this part of the web services stack is likely to be as layered and variegated as every other part of the stack; second, it's not clear that the existing efforts are competing directly. If one assumes, as most commentators have so far, that the market is unified and cohesive and that the dominant factor is institutional backing, then BPEL seems like a clear, easy winner. BPEL is a fairly mature specification, with at least two nontrivial implementations (IBM's BPWS4J and Collaxa's Orchestration Server), and its main backers (the IBM-BEA-Microsoft troika) jointly own a market segment not easily distinguished from the entire market itself. In other, blunter words: in the area of 'enterprise computing and application integration,' what IBM-BEA-Microsoft want, they very often get... One broadening assumption is that the top of the web services stack is likely to be a variegated space. Under this assumption, it becomes very unlikely that BPEL could 'win' in such a way as to crowd out every other technology. It is unlikely that BPEL could crowd out all others because it is unlikely that any single technology could adequately fill every niche of such a variegated space..."

  • [July 03, 2003] "BPEL: Make Your Services Flow. Composing Web Services into Business Flow." By Doron Sherman (CTO, Collaxa, Inc). In Web Services Journal Volume 3, Issue 7 (July 2003), pages 16-21. With 5 figures. "The current phase of the evolving Web services stack is orchestration; i.e., coordinating interactions among published Web services and composing them into long-running flows. Orchestration is comprised of three pillars: asynchronous conversations, flow coordination, and exception management. In support of these pillars, and building on its foundation, the Web services stack adds: (1) WS-ReliableMessaging: to guarantee once and only-once delivery of messages; (2) WS-Addressing: to define correlation semantics to properly match requests and replies in the context of asynchronous messaging; compensation semantics for undoing of actions in the case of faults, as commanded by application logic; (3) BPEL4WS: an execution language for defining service composition and coordinating interactions into business flows... Support for asynchrony is essential for enabling 'business quality' Web services that need to take part in integration scenarios. Asynchrony is also mandatory for allowing optimal use of 'business time' (e.g., allowing for user intervention within the course of an executing business flow or deferred batch processing for better distribution of processing load). Asynchrony improves scalability by decoupling requests for service from their corresponding responses, thereby avoiding a cascade of execution bottlenecks from spreading throughout the application. The formalism for asynchronous conversations includes WS-Addressing, WS-ReliableMessaging, and BPEL Service Link. WS-Addressing specifies correlation and callback information. WS-Addressing provides transport-neutral mechanisms for addressing Web services and messages by defining XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in transmitted messages. WS-ReliableMessaging allows messages to be delivered reliably between interacting Web services in the presence of software component, system, or network failures. Its primary goal is to create a modular mechanism for reliable message delivery. BPEL Service Link defines the callback interface... Flow coordination is comprised of the WSDL interface, XML variables, partners, flow activities, and compensation handlers. BPEL4WS relies heavily on WSDL descriptions of the services involved in order to refer to exchanged messages, the operations being invoked, and the portTypes they belong to... According to some analysts, nearly 80% of the programming effort in automating business processes is spent in exception management. In BPEL, a local fault handler associated with the Web service, is invoked subsequent to the signaled exception. Exception management also includes WS-Coordination and WS-Transaction. These specifications provide cancellation requests across a network of services to ensure coordination of interacting services in case of failures, as well as guaranteeing the integrity of the overall execution... The BPEL server supports orchestration logic provided in BPEL form for execution of business flows. Although not a mandatory requirement, a BPEL server runtime can utilize a J2EE application server for its underlying execution environment (rather than reinventing the wheel with respect to multithreading, database connection pooling, etc.). It also provides native J2EE integration by leveraging the J2EE application server runtime environment. To ensure reliability of long-running business flows involving asynchronous conversations with Web services and loosely-coupled business transactions, it uses context dehydration for executing flows. The dehydration mechanism uses a persistent store, such as a relational database, to safely store, and subsequently retrieve, flow instances... BPEL, a standard process flow grammar, provides a new foundation for integration. It empowers developers to tie transactional services, events, and user tasks into easy-to-adapt business flows. This new genre of process-driven applications moves enterprises closer to the realization of the agile real-time enterprise." [alt URL]

  • [July 03, 2003] "Using BPEL: What IT Managers Need to Know." By Derick Townsend (COO, OpenStorm Software), Ryan Cairns (CTO, OpenStorm Software), and Christoph Schittko (Momentum Software). In Web Services Journal Volume 3, Issue 7 (July 2003), pages 26-28. "Web services technology is rapidly evolving to meet the complex needs of the enterprise customer. The ability to integrate and assemble individual Web services into standards-based business processes is an important element of the service-oriented enterprise and the overall Web service technology 'stack.' These loosely coupled business processes, commonly referred to as orchestrated Web services, will be designed, integrated, executed, and managed similar to how proprietary enterprise application integration (EAI) and Business Process Management (BPM) tools operate today. However, business process execution standards and Web services will greatly reduce vendor lock-in to dramatically reduce costs and provide broader interoperability benefits... To address these needs, the Business Process Execution Language for Web services (BPEL4WS or BPEL) has quickly become the dominant specification to standardize integration logic and process automation between Web services... The most important case for BPEL is that proprietary EAI and BPM solutions are just too expensive. They are expensive to develop, maintain, and extend across a diverse, heterogeneous environment. Proprietary integration links are often brittle, and the cost to maintain them as organizations continually evolve is a significant burden. The specialized skills required to support these proprietary solutions often create their own cost and availability concerns. The frequent result is that constrained IT budgets end up shifting the majority of their funds toward maintenance issues, with precious little left over to satisfy the needs for innovation and improved flexibility... Within the corporate firewall, BPEL has the potential to standardize application-to-application integration and extend integration to previously isolated systems. As a result of years of proprietary integration efforts, a variety of integration tools and solutions exist in the enterprise today. This remains true in organizations that adopt high-end EAI products, as the cost-benefit analysis of some integration needs cannot justify the use of custom EAI adapters. In contrast, BPEL holds promise as a 'lowest common denominator' integration technology that delivers a ubiquitous, platform-neutral solution for lower cost. Outside the firewall, BPEL can enable a whole new level of corporate agility as it relates to integrating and switching external vendors and services. By using BPEL to define business processes, companies are empowered to select best-of-breed processes and services to incorporate into their operations ... BPEL remains an emerging technology, with challenges awaiting those interested in near-term deployment. Fortunately, the initial vacuum of BPEL-based development tools has been filled. Many software vendors have recognized the considerable market opportunity and responded quickly with solutions. Vendors like IBM, Collaxa, and OpenStorm offer BPEL-compliant orchestration engines, and a variety of design and development tools have been announced by industry leaders such as Microsoft and BEA." [alt URL]

  • [July 03, 2003] "Web Services Orchestration and Choreography. A Look at WSCI and BPEL4WS." By Chris Peltz (HP Developer Resources Organization). In Web Services Journal Volume 3, Issue 7 (July 2003), pages 30-35. With 4 figures. "The two standards discussed here -- the Web Service Choreography Interface (WSCI) and Business Process Execution Language for Web Services (BPEL4WS) -- are designed to reduce the inherent complexity of connecting Web services together. Without them, an organization is left to build proprietary business protocols that shortchange true Web services collaboration. Recently, the terms orchestration and choreography have been employed to describe this collaboration: Orchestration refers to an executable business process that may interact with both internal and external Web services. Orchestration describes how Web services can interact at the message level, including the business logic and execution order of the interactions. These interactions may span applications and/or organizations, and result in a long-lived, transactional process. With orchestration, the process is always controlled from the perspective of one of the business parties. Choreography is more collaborative in nature, where each party involved in the process describes the part they play in the interaction. Choreography tracks the sequence of messages that may involve multiple parties and multiple sources. It is associated with the public message exchanges that occur between multiple Web services. Orchestration differs from choreography in that it describes a process flow between services, controlled by a single party. More collaborative in nature, choreography tracks the sequence of messages involving multiple parties, where no one party truly 'owns' the conversation. In this article, I'll highlight key technical requirements for Web services orchestration and choreography, and point out key standards used to meet these needs... While BPEL4WS supports the notion of 'abstract processes,' most of its focus is aimed at BPEL4WS executable processes. BPEL4WS takes more of an 'inside-out' perspective, describing an executable process from the perspective of one of the partners. WSCI takes more of a collaborative and choreographed approach, requiring each participant in the message exchange to define a WSCI interface. At the same time, WSCI and BPEL4WS both meet many of the technical requirements outlined earlier. They both provide strong support for persistence and correlation to manage conversations. WSCI and BPEL4WS also describe how exceptions and transactions should be managed. From a usability standpoint, WSCI does have a somewhat 'cleaner' interface than BPEL4WS. Some of the difficulties in using BPEL4WS are attributed to the fact that the language includes artifacts from both XLANG and WSFL, each of which took a different approach to workflow... Orchestration and choreography are terms related to connecting Web services in a collaborative fashion. The capabilities offered by the available standards will be vital for building dynamic, flexible processes. The goal is to provide a set of open, standards-based protocols for designing and executing these interactions involving multiple Web services. Many vendors have announced support for BPEL4WS in their products, and the OASIS technical committee is looking to move this specification going forward. WSCI is being considered by the W3C for Web services choreography. While BPEL4WS has defined a notion of choreography through abstract processes, it is still unclear whether this will be accepted over the W3C work. Clearly, market adoption will be driven by the direction taken by vendors and their support of the standards in their product implementations. As these standards take shape, it will be important to pay close attention to the direction taken by standards bodies such as the W3C and OASIS..." See also "Web Service Choreography Interface (WSCI)." [alt URL]

  • [June 03, 2003] "Iopsis Unveils Web Services Assembly Product for ebXML and Business Process Orchestration. Iopsis iNsight Provides Architecture and Modeling Tools for Web Services Applications." - "Iopsis Software, an innovator in production grade Web services development tools and infrastructure, today announced version 2.1 of its iNsight application assembly product. Iopsis iNsight is the industry's first tool that lets developers use standard UML notation to define and orchestrate Web services, and it has pioneering support for OASIS ebBPSS and BPEL4WS modeling. Working as a supplement to the Sun ONE Studio and NetBeans Integrated Development Environments from Sun Microsystems, Iopsis iNsight provides modeling, code generation, choreography, and assembly of Web services for use in business processes and end-user applications. 'Iopsis's iNsight 2.1 is an ideal complement to Sun ONE Studio 4 Enterprise Edition for Java, providing a complete platform for businesses to rapidly develop enterprise class Web services applications,' said Ashwin Rao, Senior Product Manager for SunONE Studio... Iopsis iNsight allows developers to rapidly assemble Web services from existing Java code. Unlike previous tools that blindly generate WSDL and XML from low-level Java interfaces, iNsight helps developers use rich business logic interfaces (e.g., 'reserve inventory') in long-running Web services transactions. 'Until now, tools generated WSDL files that merely reflected internal interfaces that were often useless for application-level contracts,' said Rajesh Pradhan, CTO of Iopsis. 'Iopsis iNsight works at a higher level and automatically handles versioning, object naming and interoperability issues, creating Web services that are useful in a real business context.' Iopsis will be showcasing iNsight in booth 406 at San Francisco's JavaOne next week. The demonstrations will show modeling Web services interfaces, choreographing their actions in long-running business processes, and deploying working applications to the standard environments of .NET, Apache and J2EE's JaxRPC... Iopsis iNsight has always worked as a seamless extension to the SunONE Studio IDE, providing ease of use and automation to Java developers working in Web services. iNsight has added a series of packs that lower the costs and time involved with developing Web services applications: (1) Foundation Pack: The core components that extend the SunONE IDE with new windows and code generators for XML and WSDL, plus functionality for repurposing existing software assets in SAP R/3 and XML data sources. (2) Basic Pack: Creates Web Service Interfaces that conform to the WS-I Basic profile, extending the IDE capabilities with UML based modeling of WSDL interfaces. (3) Orchestration Pack: Creates choreography interfaces based on BPEL4WS 1.1 and ebXML BPSS 1.05 modeling, facilitating deployment to IBM's BPWS4J, Collaxa's Orchestration server, and ebMSH 2.0-compliant servers. (4) Mobile Access Pack: The Configuration and deployment tools for wireless web service applications using the Iopsis iNfinite multi-channel application framework... Iopsis iNsight 2.1 will be available for free download, evaluation and purchase in June 2003 at www.iopsis.com. iNsight runs on Solaris 8 + 9, Windows 2000 + XP, and RedHat Linux 7. Iopsis iNsight 2.1 is typically $1000-2000 per developer seat, depending on the number of packs used..."

  • [May 31, 2003] "Business Flows with BPEL4WS." By Doron Sherman (CTO, Collaxa). In Web Services Journal. May 2003. With 5 figures. "BPEL4WS is now moving rapidly into becoming the de facto standard for Web service orchestration with most platform vendors following in IBM and Microsoft footsteps after the submission of the specification to OASIS. This increased momentum and visibility will drive a great need for educating developers on how to put BPEL to work. This article illustrates a payment flow example coded using BPEL, highlighting some of the main constructs of the language and demonstrating how the flow can be monitored and managed once it is deployed. The example can be extended in various ways to include more advanced language constructs. Such extensions will be illustrated in subsequent articles... The PayFlow business flow example illustrated in this article is comprised of a client initiating a request to a BPEL process and ending with the process calling back the client with the result of the payment request (receipt). The process includes use of <receive> and <invoke> activities for interacting with the outside world which includes the client (request) and a partner (payment processor service). XML Variables are used for holding messages exchanged between the process and the partners. To make this example interesting, the payment processor service is asynchronous and can take anywhere from several minutes to several days before the service calls back the process. Another interesting element demonstrated by this example is the handling of exceptions and managing of timeouts. These constructs are instrumental to enable a BPEL process to deliver reliable business flows..." See also from Collaxa: Fast facts on BPEL4WS 1.1, BPEL 101 Tutorial, and Sample BPEL Scenarios. [alt URL]

  • [May 20, 2003] "Business Process with BPEL4WS: Learning BPEL4WS, Part 8. Using Switch, Pick, and Compensate." By Rania Khalaf and Nirmal Mukhi (Software Engineers, IBM TJ Watson Research Center). From IBM developerWorks, Web services. May 2003. ['This article illustrates the use of three more BPEL activities: switch, pick, and compensate. In addition to showing how you can branch on conditionals using <switch>, we show how you can use <pick> to branch based on incoming messages or timeouts. A simple explicit compensation example is also presented to show how committed actions may later be undone.'] "In the previous articles we took a simple flow that can invoke one Web service, and added another partner, control logic through links and conditions, data manipulation using assignment, nested activities and scopes, and finally correlation sets and fault handlers. In this article, we take our loan approval example and present three different scenarios showing the use of the compound activities <switch> and <pick>, as well as a simple compensation handler... In these scenarios, we have brought together most of the main concepts of BPEL4WS. As the last tutorial-type article in this series, it provides you with a better feel for how to bring activities together to create simple as well as complex processes. Feel free to do what we have done here to further your understanding of the language: take the resulting .bpel file and play around with the syntax to try out the different constructs in the language and see how they affect the flow of control as well as the complexity of what you would like to express in your Web services compositions. You can use the Eclipse editor available with BPWS4J on alphaWorks, and graphically substitute an activity for another or change its properties without having to worry about the rest of the process. For example, you can take a nested activity and request that it be wrapped in a scope and then add handlers to it..." [Note: this article refers to BPEL4WS v1.0, not to v1.1.] Article also available in PDF format. See the previous parts in the series.

  • [May 12, 2003] "Business Process with BPEL4WS: Learning BPEL4WS, Part 7. Adding Correlation and Fault Handling to a Process." By Rania Khalaf and William A. Nagy (Software Engineers, IBM TJ Watson Research Center). From IBM developerWorks, Web services. April 22, 2003. ['In the previous article we examined correlation and fault handling in BPEL4WS. Now, we are going to extend the simple BPEL4WS process that we have been working with in the previous articles by adding the ability to communicate with a pre-existing process instance and to capture faults which may occur during its execution.'] "Having explained correlation and fault handling in BPEL4WS in the previous column of this series, we now add these capabilities to the loan approval sample we have been working with to illustrate their use. In the scenario shown here, if a client is approved for a loan he may send a request to actually obtain that loan. Correlation is used to make sure that the second request goes to the correct process instance. Fault handling will be added to catch an explicitly thrown error that signals that the client is trying to obtain a loan for an amount larger than the one that was approved. If such a fault is caught, a reply is sent back describing the problem. We also show the effect of error handling with nested scopes and its effects on the links that leave a scope that has handled its error, as well as one that was not able to do so and had to rethrow the fault to its enclosing scope... In the next article in this [BPEL4WS] series, we will look at the switch and pick activities, and at compensation..." ['Note that this articles refers to version 1.0 of the BPEL4WS specification. The latest version, BPEL4WS 1.1, is now available, and an article describing the key differences between the two specifications will be available shortly.'] Also in PDF format.

  • [April 29, 2003] "OASIS Members Form Web Services Business Process Execution Language (WSBPEL) Technical Committee." - "Members of the OASIS Open standards consortium will advance a specification to formally describe interoperable business processes and business interaction protocols for Web services orchestration. The new OASIS Web Services Business Process Execution Language (WSBPEL) Technical Committee will continue work on the Business Process Execution Language for Web Services (BPEL4WS) specification, an XML-based language that allows users to describe business process activities as Web services and define how they can be connected to accomplish specific tasks. BEA, IBM, Microsoft, and SAP intend to formally submit BPEL4WS version 1.1 under royalty free terms to the new OASIS Technical Committee at its first meeting on 16 May 2003. The committee is open to submissions of other in-scope contributions and will establish liaison relationships with related Web services efforts within OASIS and other standards organizations including the World Wide Web Consortium (W3C)... 'To solve real-life business problems, companies may need to invoke multiple Web services applications inside their firewalls and across networks to communicate with their customers, partners, and suppliers,' said Diane Jordan of IBM, co-chair of the OASIS WSBPEL Technical Committee. 'BPEL4WS allows you to sequence and coordinate internal and external Web services to accomplish your business tasks. Thus, the result of one Web service can influence which Web service gets called next, and successful completion of multiple Web services in a process can be coordinated.' John Evdemon of Microsoft, co-chair of the OASIS WSBPEL Technical Committee, added, 'The participants in this Technical Committee are committed to building and delivering standards-based interoperable Web services solutions to meet customer requirements. Business processes are potentially very complex and require a long series of time- and data-dependent interactions. However, BPEL4WS allows companies to describe sequential interactions and exception handling in a standard, interoperable way that can be shared across platforms, applications, transports and protocols.' OASIS WSBPEL Technical Committee members include Booz Allen Hamilton, BEA Systems, Commerce One, E2open, EDS, IBM, Microsoft, NEC, Novell, SAP, SeeBeyond, Sybase, Tibco Software, Vignette, Waveset, and others. Participation remains open toall organizations and individuals, and OASIS encourages both vendors of business process automation software as well as end users interested in automating and integrating their internal or external business processes to join this effort. OASIS will host an open mail list for public comment..."

  • Business Process Management and Choreography. General reference document for Business Process Execution Language for Web Services (BPEL4WS), Business Process Management Initiative Specifications (BPML, BPMN, BPQL), ebXML Business Process Specification Schema (BPSS), OASIS Business Transaction Protocol (BTP), OMG Business Process Definition, W3C Web Services Choreography Working Group, Web Service Choreography Interface (WSCI), Web Services Conversation Language (WSCL), Web Services Flow Language (WSFL), Workflow Management Coalition (WfMC) Specifications, XLANG: Web Services for Business Process Design, etc.

  • [April 18, 2003] "IBM, MS Streamrolling W3C and Web Services?" By David Berlind. In ZDNet Tech Update (April 18, 2003). ['Hiding behind a puppet standards group called OASIS, these two 800-pound gorillas appear well on their way to usurping the promise of Web services and flattening the World Wide Web Consortium into irrelevancy. It's time for Tim Berner-Lee's group to take off the gloves.'] "Those who are following the development of Web services standards have been holding their breath, waiting to see how the controversy over choreography and workflow specifications will resolve itself. Most people who are intimately familiar with the issue have been telling me for some time now that a peaceful resolution is likely. But, now that Business Process Execution Language for Web services (BPEL4WS) co-authors BEA, IBM, and Microsoft have announced the submission of specification to the Organization for the Advancement of Structured Information Standards (OASIS), the controversy is about to evolve into an industry-splitting fracas. On the surface, it looks like just another skirmish among vendors over a standard. But under the covers, it's nothing of the sort. Whereas most such skirmishes take place behind the closed doors of a single consortium, this one pits OASIS, which is emboldened by the combined muscle of IBM and Microsoft, against the de facto leader of Web standards setting -- the World Wide Web Consortium (W3C)... For those of you not up to speed on this controversy, the promise of Web services--that of a series of specifications unanimously adopted by all vendors -- is on the verge of becoming a train wreck. The lack of consensus over how to handle Web services workflow, choreography, and transactions has devolved into a bifurcation of the industry into two camps -- one that's behind the Web services choreography interface (WSCI) and another that's supporting BPEL4WS. For a fleeting moment, it looked like a potential resolution was in the works when Microsoft surprised everyone by joining the W3C's working group for Web services choreography. That membership lasted little more than a day. Before the news of Microsoft joining the group had even been reported, Microsoft withdrew its membership, within hours of attending its first meeting... The non-royalty-free Web Services Interoperability Organization (WS-I), whose self-proclaimed but easily questioned mission is to guarantee interoperability through the provision of recommendations and test suites, is another IBM-Microsoft joint venture that's contributing to the theft of the W3C's thunder. It's a disturbing and unfortunate trend. The W3C's insistence on a royalty-free intellectual property policy was a gut-wrenching move for the consortia that demonstrated the thought leadership of W3C director Tim Berners-Lee. If the bleeding is to be stopped, the W3C can no longer confine itself to taking the moral high ground..." Earlier article from Berlind's ZDNet Tech Update series: "Web Services in Serious Jeopardy."

  • [April 17, 2003] "Product Plans Afoot for BPEL4WS Spec. W3C Fears Fragmented Standards Efforts." By Paul Krill. In InfoWorld (April 17, 2003). "Major backers of the BPEL4WS specification for Web services business processes are preparing products to implement the technology, which is being submitted for consideration by OASIS as an industry standard. But a spokeswoman for the World Wide Web Consortium (W3C) expressed fears that Web services standardization could be fragmented, with both Organization for Advancement of Structured Information Standards (OASIS) and W3C now pondering Web services business process, or choreography, standards. BPEL4WS, or Business Process Execution Language for Web Services, also has been known as just BPEL. Developed by IBM, Microsoft, and BEA Systems and introduced in August 2002, the specification is intended as a way to describe business processes constructed as a collection of Web services, which is sometimes referred to as choreography, said John Kiger, director of Web services strategy at BEA in San Jose, Calif. 'By this fall, you'll see real products delivered that use BPEL4WS to do business processes between these heterogeneous systems,' said Steven Van Roekel, Microsoft director of Web services, in Redmond, Wash. Microsoft, for example, plans to support BPEL4WS in its BizTalk Server application integration platform, Van Roekel said... BEA will add BPEL4WS to its WebLogic platform later this year to enable business processes to be exchanged across heterogeneous environments, Kiger said. Siebel Systems, meanwhile, has been working with IBM, Microsoft, and BEA on using the specification in the Siebel Universal Application Network offering for multi-application integration, said Hitesh Dholakia, senior manager for Universal Application Network at Siebel, in San Mateo, Calif. SAP by the end of this year plans to implement BPEL4WS in various products, including its Exchange Infrastructure, which is a messaging platform for integrating SAP and non-SAP systems, said Sinisa Zimek, director of technology and standards at SAP, in Palo Alto, Calif. Despite supporters' ambitious plans for BPEL4WS, a spokeswoman for W3C, which also is deliberating Web services technologies including choreography, expressed fears that the dual OASIS and W3C efforts would lead to fragmentation and hinder standardization for Web services..."

  • [April 17, 2003] "Commentary: The Right Web Services Process Standard." By Ted Schadler (Principal Analyst, Forrester Research). In CNET News.com (April 15, 2003). "Applications heavyweights SAP and Siebel Systems have joined BEA Systems, IBM and Microsoft as co-authors on the BPEL4WS business process specification -- and given it to OASIS under royalty-free terms. It's good news for companies focused on Web services. Forrester spoke with executives from those software makers about their plans to submit BPEL4WS, or Business Process Execution Language for Web Services, to OASIS with 22 other co-submitters. We believe that the standards body will extend that specification with the best parts of competing specifications Web Service Choreography Interface (WSCI) and Business Process Modeling Language (BPML) to create a single process standard. Companies should bet on BPEL4WS today because commitments from SAP and Siebel will tip the balance in its favor. BEA, IBM and Microsoft already support the specification. Now SAP and Siebel say they'll implement it in their integration products later this year and will use it for internal application integration as well. Meaning? WSCI and BPML will fade away, and users can start coding to BPEL4WS today, safe in the knowledge that their application links will migrate to the standard when it's ratified... The track record for IBM's and Microsoft's Web service standard is unblemished. Moving from proposal to widely adopted standard is never easy. But recent cases lead Forrester to conclude that the effort will be successful--witness, for example, the successful transition of WS-Security from specification to OASIS standard to WS-I supported standard. The bottom line? Companies should feel confident that real standards for reliable messaging, security and work flow will appear in products by 2004..." Note: The characterization "under royalty-free terms" may be grounded in good authority, but the 2003-04-16 CFP and Charter do not actually address this topic.

  • [April 15, 2003] "OASIS to Get BPEL4WS Jurisdiction. Web Services Specification Finally Goes to Standards Body." By Paul Krill. In InfoWorld (April 15, 2003). "Microsoft, IBM, and BEA Systems plan to submit their Web services choreography and business process specification, initially proposed in August 2002, to a standards body later this week. The Business Process Execution Language for Web Services (BPEL4WS) specification is expected to be submitted to Organization for the Advancement of Structured Information Standards (OASIS), Carol Geyer, spokeswoman for OASIS, confirmed. 'We anticipate it will probably be tomorrow and a charter will be submitted tomorrow or maybe Thursday,' Geyer said. The proposing companies still are making modifications to the charter for BPEL4WS that they submit to OASIS, she said. According to a source familiar with the announcement, SAP and Siebel are joining the original developers of BPEL4WS, IBM, Microsoft, and BEA, in the submission. BPEL4WS is intended to provide for more automated Web services, which is considered crucial to spread the use of Web services for back-end integration for applications such as e-commerce. The submission of BPEL4WS to a standards organization such as OASIS or World Wide Web Consortium (W3C) has been awaited. A technical committee is to be formed to deliberate on the specification at OASIS, with an initial meeting to be held May 15, the source said. Co-submitters of the technical committee charter include the following: Accenture, Akazi, CGEY, Collaxa, CommerceQuest, EDS, Vignette, FiveSight, Handysoft, HP, i2, JDEdwards, NEC, Novell, OpenStorm, SeeBeyond, SourceCode, TeamPlate, Tibco, Unisys, Ultimus, and WebV2, according to the source. One issue, whether the specification would be submitted royalty-free, apparently has been resolved, as all submitters have agreed to not seek royalties, or financial compensation, for their contributions to the specification used in any implementations, according to the source... BPEL4WS also is being upgraded to Version 1.1, although details on improvements were not immediately available..." See related references in "Business Process Management and Choreography."

  • [April 15, 2003] "Web Services Standards Facing a Split?" By Martin LaMonica. In CNET News.com (April 15, 2003). "IBM, Microsoft and BEA Systems plan to submit a high-profile Web services proposal to the OASIS standards body, company executives said, despite an ongoing effort by the World Wide Web Consortium to sort through similar proposals. Led by the three powerhouse companies, about 20 businesses will propose the creation of a technical committee within the OASIS standards body to standardize the Business Process Execution Language for Web Services (BPEL4WS), which is a language for automating complex business processes. The companies, which include SAP and Siebel, will make the submission to OASIS as early as Tuesday, according to the IBM executive. An official announcement from OASIS is expected in about a week... The group of companies backing BPEL also plans to publish an update to the BPEL specification when it is submitted to OASIS. BPEL was originally authored by IBM, Microsoft and BEA. The submission of BPEL to OASIS is the latest move in a series of maneuvers among information technology providers around Web services standards. By using XML-based Web services standards, businesses can more easily share information between disparate systems. The ability to automate a multistep business process using Web services -- called choreography or orchestration -- is an important capability to drive broader adoption of Web services, according to analysts. The World Wide Web Consortium (W3C) last month created a choreography working group to sort out several overlapping standards proposals. The W3C group has garnered membership from several companies, including industry heavyweights Oracle, Sun Microsystems and Hewlett-Packard. The W3C requested that IBM, Microsoft and BEA participate in the choreography working group and submit the BPEL specification for consideration. Microsoft representatives attended the first meeting but decided to break with the working group after one day. IBM and Microsoft executives said they decided to submit BPEL to OASIS because it has been active in recent Web services standards efforts, including WS-Security, that the two companies have spearheaded. Although members of the OASIS technical committee will monitor the work done at the W3C's choreography group, there are no plans to officially interact with the W3C, IBM and Microsoft executives said. 'We're hopeful that the choreography field is big enough that there are complementary areas that the (W3C choreography) group can work on, rather than focusing on areas that don't allow us to build momentum,' said Karla Norsworthy, director of e-business technology at IBM..."

  • [April 11, 2003] "Web Services Specification Still Not Ready for Standardization. BPEL4WS Remains in Founders' Jurisdiction." By Paul Krill. In InfoWorld (April 11, 2003). "A specification for Web services choreography and business processes introduced by Microsoft, IBM, and BEA Systems last August remains under its founders' jurisdiction, despite repeated assurances of its pending submission to an industry standards organization... The specification, Business Process Execution Language for Web Services (BPELWS), is gaining momentum in the industry as a way to automate Web services back-end interactions for Web-based integration of applications such as e-business. Companies such as Collaxa and BEA have offered details of product plans for supporting BPEL4WS. The specification's founders have pledged to submit the proposal to a standards organization such as OASIS or W3C for consideration as an industry standard... [IBM's Bob] Sutor said there are political issues that have come about pertaining to differences of opinion on the specification. Asked if the issues had to do with intellectual property rights, pertaining to royalty rights for BPEL4WS founders, Sutor said IBM would not seek any royalties on BPEL4WS, as he has pledged before..."

  • [April 05, 2003] "Business Process with BPEL4WS: Learning BPEL4WS, Part 6. Correlation, Fault Handling, and Compensation." By Rania Khalaf and William A. Nagy (Software Engineers, IBM TJ Watson Research Center). From IBM developerWorks, Web Services. April 2003. ['The previous articles have covered the fundamentals of BPEL4WS, providing you with an understanding of the activities defined and how they can be combined together using structured activities and the <link> construct. In this article, we cover the advanced properties of the language that are essential to the definition and execution of a business process. BPEL uses correlation to match returning or known customers with a long-running business process, fault handling to recover from expected as well as unexpected faults, and compensation to "undo" already committed steps in case something goes wrong in the middle of the process or, for example, a client wishes to explicitly cancel a transaction.'] "Message correlation is the BPEL4WS mechanism which allows processes to participate in stateful conversations. It can be used, for example, to match returning or known customers to long-running business processes. When a message arrives for a Web service which has been implemented using BPEL, that message must be delivered somewhere -- either to a new or an existing instance of the process. The task of determining to which conversation a message belongs, in BPEL's case the task of locating/instantiating the instance, is what message correlation is all about. In many distributed object systems, one component of the routing of a message involves examining the message for an explicit instance ID which identifies the destination. Although the routing process is similar, BPEL instances are not identified by an explicit instance field, but are instead identified by one or more sets of key data fields within the exchanged messages. For example, an order number may be used to identify a particular instance of a process within an order fulfillment system. In BPEL terms, these collections of data fields which identify the process instance are known as correlation sets. Each BPEL correlation set has a name associated with it, and is composed of WSDL-defined properties. A property is a named, typed data element which is defined within a WSDL document, and whose value is extracted from an instance of a WSDL message by applying a message-specific XPath expression. In WSDL, a propertyAlias defines each such mapping. The mappings are message specific, hence a single property can have multiple propertyAliases associated with it. For example, a WSDL document might say that property name corresponds to part username of WSDL message loginmsg and to part lastname of ordermsg. Together, the properties and propertyAliases provide BPEL authors with a way to reference a single, logical piece of information in a consistent way, even if it might appear in different forms across a set of messages... The next article will provide a runnable example that illustrates both the use of correlation for matching messages to the appropriate instances, as well as the use of a fault handler to catch and take care of errors in the process."

  • [March 18, 2003] "Microsoft Dips Toe in Choreography Waters. Software Giant Surprise Attendee at W3C Meeting." By Paul Krill. In InfoWorld (March 14, 2003). "Microsoft on Thursday [2003-03-13] participated in an industry effort to standardize Web services choreography. Despite initial indications that it would not attend, two Microsoft representatives attended the first meeting of the World Wide Web Consortium's (W3C) Web Services Choreography Working Group held Thursday and Friday at Oracle headquarters in Redwood Shores, Calif. , an Oracle representative said. Microsoft, in a prepared statement pertaining to its attendance, provided little detail on specific goals of its participation and confirmed it still will not formally join the campaign. 'We are interested in following and, when appropriate, participating in working groups. As such, we had two employees attend part of the meeting in order to understand its scope better. No decisions have been made regarding joining. Moving forward, Microsoft continues to stay actively involved on the many different fronts, with varying degrees of participation and input, relative to the standardization process,' the company said. Oracle's representative said that Microsoft is seeking a single standard that that finds a middle ground between the BPEL4WS (Business Process Execution Language for Web Services) specification, authored by Microsoft, IBM, and BEA Systems, and the Sun Microsystems-led WSC (Web Services Choreography Interface) specification. Microsoft wants to have the W3C effort complement BPEL4WS, according to Oracle. Web services choreography is intended to automate interaction between Web services and is considered critical to enabling the integration promise of Web services. Attending on behalf of Microsoft were Alan Brown, who serves as one of the company's W3C representatives, and Greg Meredith, who is in Microsoft's research organization, according to Oracle... Microsoft, IBM, and BEA have not formally submitted BPEL4WS to a standards organization for consideration, unlike WSCI, which is now being considered by W3C. Despite Microsoft's willingness to work with the W3C working group, BPEL4WS still is not being submitted to the organization, according to the Oracle representative. However, BPEL4WS is gaining industry support despite not being under the jurisdiction of any standards organization. It is being implemented in products from companies such as Collaxa and BEA, who are not including WSCI in their systems, despite BEA also being a co-author of WSCI. A Sun representative said it is still too early to see much WSCI support at the product level..."

  • [March 13, 2003] "Collaxa Readies Web Services Tool. Software Backs IBM-Microsoft-BEA Specification." By Paul Krill. In InfoWorld (March 10, 2003). "Collaxa within two months plans to release a Web services deployment tool that utilizes the Business Process Execution Language for Web Services (BPEL4WS) specification backed by IBM, Microsoft, and BEA Systems. Collaxa Orchestration Server 2.0, which is now available in an evaluation release, is intended to enable developers to publish asynchronous and synchronous Web services and utilize them for transactional business flows, according to Redwood Shores, Calif.-based Collaxa. A console based on BPEL4WS provides for reporting, auditing, and debugging capabilities. The product offers the industry's first implementation of a BPEL4WS-based orchestration server, said Doron Sherman, Collaxa CTO. The primary intention of Orchestration Server is to develop reliable business flows using XML, Web services, and J2EE, Sherman said. The tool provides support for publishing asynchronous Web services and composing Web services for use in long-running business transactions, according to the company. 'Basically, an orchestration server coordinates Web services,' said Sherman . The product backs two proposed standards from IBM, Microsoft, and BEA: BPEL4WS and WS-Transaction. By supporting these, Collaxa can provide a standard way for developing business flows without having to utilize proprietary EAI mechanisms, Sherman said. Developers also do not need to build their own custom architecture, he added. BPEL4WS competes with a Sun-proposed specification, Web Services Choreography Interface (WSCI), although Sherman said there is not complete overlap. BPEL4WS supports both orchestration, for private implementations of interactions between Web services, and choreography, which serves as an external interface for Web services interactions, Sherman said. WSCI only covers choreography, he said. Collaxa anticipates BPEL4WS will become an industry standard, Sherman said. 'We believe IBM, Microsoft, and BEA [are] the industry heavyweights [and they have] the critical mass necessary for making BPEL4WS the de facto standard in the industry,' Sherman said..."

  • [March 11, 2003] "Business Process with BPEL4WS: Learning BPEL4WS, Part 5. Adding Links and Manipulating Data." By Matthew J. Duftler (Software Engineer, IBM TJ Watson Research Center), Francisco Curbera (Manager Component Systems Group, IBM TJ Watson Research Center), and Rania Khalaf (Software Engineer, IBM TJ Watson Research Center). From From IBM developerWorks, Web Services. ['The previous example in Part 2 of this series showed how to build a simple BPEL4WS process that invokes a web service. This article takes that example and expands it into the loan approval process that is included in the BPEL4WS specification and the BPWS4J samples, illustrating the use of links, conditions, and the <assign> activity. Links connect activities together, and allow the specification of a condition on each that determines whether or not that link should be followed. Conditions in BPEL4WS are XPath expressions, and this article shows how they can incorporate the process's container data. The <assign> activity can be used to copy data into a container when the data is not copied directly as the result of an <invoke>.'] This article develops a "loan approval sample that is in the BPEL4WS specification and the BPWS4J samples. It illustrates two core capabilities for defining choreographies: defining flow of control using guarded links, and manipulating data with the <assign> activity. We assume that you have read and understood the prior example, and we take you forward from there. As with the earlier example, we will conclude by describing how the process will run, and the results of running it in the BPWS4J engine. We will show you a process that handles the same loan request -- a customer sends a request for a loan, the request gets processed, and the customer finds out whether the loan was approved. Initially, the middle step consisted of simply invoking a financial institution's Web service and sending its reply back to the customer. Instead of this basic step, you want to employ some additional logic in the handling of the application. You can perform the following sequence of steps to try to determine whether you can grant the loan without going to the financial institution (the loan approver) for a full review; if the requested amount is high, it is always sent to the financial institution for review. If the amount is low, you invoke a new Web service, called the loan assessor, to determine the risk. If the assessor determines there's low risk giving the applicant the loan, then it can be approved. Otherwise, send it to the financial institution for a full review... As with our earlier articles, if you want to run the process, you'll need to download and install the BPWS4J engine available from alphaWorks..." Also in PDF format.

  • [March 07, 2003] "Web Services in Serious Jeopardy. [Reality Check.]" By David Berlind. In ZDNet Tech Update (March 06, 2003). Includes sections: 'BPEL4WS vs. WSCI' and 'Penchant for patents?' "APIs are the basis of Web services. Microsoft and IBM played a critical role in making sure that the first Web services protocol necessary to get the ball rolling -- the Simple Object Access Protocol (SOAP) -- was compatible with both of their solutions. Sure, the promise of interoperability and cost savings via Web services is intriguing to IT shops. But the vendors have another motive in establishing a standard set of insulating APIs. Creating a more level playing field in the cost of switching vendors is less hazardous, and potentially favors those companies with the most market clout... Unfortunately for the vendors who want to steal each other's customers and the customers who want to benefit from that war, there's a small problem. And, if the problem is not resolved soon, the entire Web services plan could end up being scuttled. The bandeleros, whose assistance is imperative, were on board with the preliminary plans--the first few Web services APIs (XML, SOAP, WSDL, etc.). Those basic APIs are essential for dissimilar systems to hold hands, but another set of APIs is essential to making sure that those systems can go to the next level--dance. In particular, to the extent that multiple systems are involved in the processing of a transaction or series of transactions, the order of execution of every step is imperative, as is the application's response if one of those steps fails. Whereas enterprise databases have long been capable of tracking transactions and rolling back data to its pre-transaction state should an error occur, choreographing a business process that involves multiple dissimilar systems, and then building in a similar degree of fault tolerance, is far more complex. These dissimilar systems -- dance partners, if you will -- would need a common API if the dance were to result in an award-winning performance (successful transaction execution or roll-back) each and every time. It is this API and the current disagreement over it that is threatening the future of Web services. In one corner is the Business Process Execution Language for Web Services (BPEL4WS, but most often pronounced 'bee-pell'). BPEL4WS is a business process and choreography API that was co-authored by IBM, Microsoft and BEA. Although it is completely proprietary and hasn't even been submitted to a standards-setting body, all three companies already have plans to support the specification in their solutions as though it were a standard. At the very least, IBM and Microsoft will be able to continue focusing on picking off each other's customers as well as BEA's. Unfortunately, while the three companies steam forward on BPEL4WS, the rest of the world is standing in the other corner with a competing specification--the Web Services Choreography Interface (WSCI, pronounced 'whiskey). Unlike BPEL4WS, WSCI has taken the first step towards standardization through a submission to the World Wide Web Consortium (W3C)... Let's suppose that BPEL4WS becomes the de facto standard, by virtue of BEA's, Microsoft's, and IBM's support for BPEL4WS in their application servers, which happen to be the application server market's three leading products. The three intellectual property owners would be in the driver's seat not only when it comes to Web services, but for a portion of the Web itself. It will be exactly the scenario that I've warned about, where the intellectual property owners of one critical protocol could end up in control of an important part of the Internet. At the very least, if you end up being seduced by the promise of standards by using the two Web services protocols (SOAP and WSDL) that IBM and Microsoft shoved down the W3C's throat, it may not be long until you find out that your investment in open standards has locked you into using a proprietary technology. As I have posited before, following a path where you eventually find yourself locked into a proprietary technology puts the intellectual property owner in control of a lot of things, including cost..."

  • [March 05, 2003] "BEA Shows Web Services Allegiance. Suite Backs IBM-Microsoft Proposal, But Not Rival Sun Plan." By Paul Krill. In InfoWorld (March 04, 2003). "Although BEA Systems has been in the somewhat-peculiar position of backing rival Web services choreography efforts, aligning with IBM and Microsoft on one proposal and Sun Microsystems on another, details of the company's new product suite, WebLogic Platform 8.1, reveal that BEA is moving closer to the IBM-Microsoft camp. WebLogicPlatform 8.1, the company's Java applications platform suite unveiled at the BEA eWorld conference here Monday, supports the IBM-Microsoft-BEA Web services choreography proposal, known as Business Process Execution Language for Web Services (BPEL4WS), said company CTO Scott Dietzen, in an interview this week. Version 8.1, however, does not support the rival Sun-driven effort, Web Services Choreography Interface (WSCI), which also has had BEA's endorsement. Web services choreography involves automation of Web services and is considered crucial for applications such as Web services-based transactions. An implementation of BPEL4WS is included in WebLogic Platform 8.1, Dietzen acknowledged. 'We're supporting BPEL4WS [in Version 8.1] because big customers, like Siebel, want it. We haven't had the same demand for WSCI,' so it is not in the Version 8.1 container, said Dietzen. Dietzen, however, noted that BPEL4WS is not a finalized proposal and that BEA hopes a single standard for choreography can be forged... Although Version 8.1 was just unveiled this week, a BEA official during a keynote presentation at eWorld Tuesday provided brief glimpses into the direction of future versions of WebLogic Platform. Key areas of focus include management, deployment, and automating changes, specifically deploying changes in a distributed environment, said Olivier Helleboid, president of the BEA Products Organization... BEA also is focusing on extending security in a general enterprise environment and adding simple tools for developers to move development closer to business operations. Improving basic performance, scalability, and management also remains a priority, Helleboid said. 'We are a year or two years ahead of IBM in that space and we absolutely intend to stay that way,' said Helleboid. WebLogicPlatform 8.1 features new versions of products such as the WebLogic Server application server and WebLogic Workshop development environment. The platform is available in beta version now, with general availability planned for this summer..."

  • [February 21, 2003] "Sun Trumpets Royalty-Free Web Services Specs. Company Challenges Microsoft, IBM." By Paul Krill. In InfoWorld (February 20, 2003). "Royalty-free industry specifications are needed to enable Web services to fulfill its potential as a mechanism for business process integration on a massive scale, Sun officials stressed during a Sun 'Chalk Talk' session in San Francisco on Thursday. Any requirement that specific vendors be paid royalties for use of their technologies in standardized Web services specifications could stifle the growth of Web services, said Mark Bauhaus, Sun vice president of Java Web services. Sun wants its royalty-free position to be accepted by other members of the Web Services Interoperability Organization (WS-I) and is running for election to a seat on the WS-I governing board in March. Specifically, Microsoft and IBM need to embrace royalty-free Web services, specifications, according to Bauhaus. With the vast increase in devices accessing the Internet, which could eventually number into the billions, and the low cost of Internet access, Web services are poised for dramatic growth as a business process integration mechanism for a variety of applications, Bauhaus said, but Web services must be royalty-free and based on open standards, and specifications must be converged. 'The headlines that we're writing now are about Web services. Is it going to be royalty-free or is someone going to hijack it?' Bauhaus said. He noted that IBM and Microsoft have produced a proposed specification for automating interaction between Web services, called Business Process Execution Language for Web Services (BPEL4WS). This proposal has not yet been submitted to a standards organization. Sun has a competing proposal, Web Services Choreography Interface (WSCI), being examined by the World Wide Web Consortium (W3C)..."

  • [February 19, 2003] "BPEL Learning Guide." By SearchWebServices.com Editorial Team. From SearchWebServices.com (February 19, 2003). "Java developers need to publish synchronous and asynchronous Web services and compose them into reliable and transactional business flows. Web service orchestration standards (SOAP Conversation, BPEL4WS and WS-Transaction) are emerging and need to be packaged into a reliable and easy-to-manage software solution. So we've gathered a wealth of information to get you up-to-speed quickly."

  • [February 12, 2003] "Intalio Ships Intalio|n³ 2.0. New End-user Interactivity Combines with Productivity, Performance, Standards Enhancements to Reinforce Dominance of Company's BPMS." - "Intalio, Inc., the business process management company, today announced immediate availability of Intalio|n³ 2.0, the company's trailblazing Business Process Management System (BPMS). The move reinforces Intalio's leadership position in BPM arena by adding support for complex workflow interactions with end-users while enhancing Intalio|n³ 2.0 support for industry standards, amplifying its enterprise-class performance, and boosting user productivity. 'Intalio|n³ 2.0 benefits from more than three years of research and development as well as experience acquired through successful deployments by early adopters,' said Ismael Ghalimi, co-founder and chief strategy officer of Intalio. 'The groundbreaking architecture of Intalio|n³ 2.0 takes BPM to the next level as the only BPMS that can support any block-structured process modeling languages such as BPML and BPEL4WS. Perhaps more significant, Intalio|n³ 2.0 leverages organizations' existing IT assets and infrastructure, including application servers, message brokers, packaged applications, heritage systems and Web Services.' With Intalio|n³ 2.0, organizations now have the power to completely and seamlessly manage the entire life cycle of their business processes, from design to execution to optimization. Highlighting Intalio|n³ 2.0 is the introduction of a new platform component, Intalio|n³ Director, as well as standards support, enterprise-readiness, and productivity enhancements to established Intalio|n³ Server and Intalio|n³ Designer components. Intalio|n³ Director allows employees, customers, and partners to seamlessly direct the execution of business processes and perform business activity monitoring tasks through any existing workforce software, including groupware systems, workflow engines, and enterprise information portals. Key to Intalio|n³ Director is XPage, a new XML-based language developed by Intalio, for creating highly-interactive user interface components. XPage replaces the use of up to seven different languages that are required today for the development of interactive Web-based user interfaces (JSP, Java, JavaScript, XML, XSLT, HTML, CSS). In combination with BPML, XPage can reduce the development cost of end-to-end processes by up to 75 percent. Intalio|n³ Director's tight integration with Intalio|n³ Designer lets users visually bind UIs with processes thereby eliminating the need to manually code. Intalio|n³ Director also features an easily customizable BPML-based workflow engine for role-based task management and LDAP integration for user management. Intalio|n³ Director runs on any application server with a servlet engine..."

  • [January 14, 2003] "W3C to Ponder Web Services Choreography." By Paul Krill. In InfoWorld (January 14, 2003). "The World Wide Web Consortium on Tuesday agreed to form a working group to draft an industry-wide recommendation on implementing Web services choreography, to enable Web services to better interact with each other for more automated transactions. The Web Services Choreography Working Group, which will be co-chaired by Oracle's Martin Chapman and Enigmatec's Steven Ross-Talbot, at this juncture will consider two choreography proposals submitted to W3C, including Hewlett-Packard's Web Services Conversation Language (WSCL) and Sun Microsystems' Web Services Choreography Interface (WSCI). The WC3 effort is to be built on WSDL 1.2, according to W3C spokeswoman Janet Daly... a rival choreography proposal by Microsoft, IBM, and BEA Systems, called Business Process Execution Language for Web Services (BPEL4WS), is not now being considered by W3C because it has not been submitted to W3C and lacks a royalty-free condition of its use, Daly said... "It's questionable whether we could even use [BPEL4WS]," Daly said. "We're hoping that the owners of the document will make it available." She noted that the three companies that authored the document all are active in the W3C. IBM and BEA have pledged a royalty-free stance on BPEL4WS, but Microsoft has not made any public statement. IBM's Bob Sutor, director of Web services technology at the company, said last week that BPEL4WS would be submitted to a standards body within one to two months... Deliverables of the working group include a requirements document for choreography, usage scenarios, specifications of choreography languages, and an XML Schema as well as a test suite. The multitude of choreography specifications for Web services prompted Oracle last year to ask the W3C to consider forming a committee to ponder choreography..." See details in the 2003-01-14 news item "W3C Creates Web Services Choreography Working Group."

  • [December 30, 2002] "Pattern Based Analysis of BPEL4WS." By Petia Wohed (Department of Computer and Systems Sciences, Stockholm University/The Royal Institute of Technology, Sweden), Wil M.P. van der Aalst (Department of Technology Management, Eindhoven University of Technology, The Netherlands), Marlon Dumas (Centre for Information Technology Innovation, Queensland University of Technology, Australia), and Arthur H.M. ter Hofstede (QUT). Technical Report FIT-TR-2002-04, QUT. 20 pages (with 17 references). Table 1 provides a comparison of BPEL4WS against XLANG, WSFL, Staffware, and MQSeries Workflow using both workflow and communication patterns. "Web services composition is an emerging paradigm for enabling application integration within and across organisational boundaries. A landscape of languages and techniques for web services composition has emerged and is continuously being enriched with new proposals from different vendors and coalitions. However, little or no effort has been dedicated to systematically evaluating the capabilities and limitations of these languages and techniques. The work reported in this paper is a first step in this direction. It presents an in-depth analysis of the Business Process Execution Language for Web Services (BPEL4WS). The framework used for this analysis is based on a collection of work flow and communication patterns... The reported analysis is based on a framework composed of a set of patterns: abstracted forms of recurring situations found at various stages of software development. Specifically, the framework brings together a set of workflow patterns documented in 'Workflow Patterns' available via the Workflow Patterns website [QUT Technical ReportFIT-TR-2002-2] and a set of communication patterns documented in [Ruh/Maginnis/Brown Enterprise Application Integration: A Wiley Tech Brief, 2001]. The workflow patterns (WPs) have been compiled from an analysis of existing workflow languages and they capture typical control flow dependencies encountered in workflow modelling. More than 12 commercial Workflow Management Systems (WFMS) as well as the UML Activity Diagrams, have been evaluated in terms of their support for these patterns. The WPs are arguably suitable for analysing languages for web services composition, since the situations they capture are also relevant in this domain. The Communication Patterns (CPs) on the other hand, are related to the way in which system modules interact in the context of Enterprise Application Integration (EAI). They are structured according to two dichotomies: synchronous vs. asynchronous, and point-to-point vs. multicast. They are arguably suitable for the analysis of the communication modelling abilities of web services composition languages, given the strong overlap between EAI and web services technologies..." See also "Pattern Based Analysis of BPML (and WSCI)" [TR] and "Don't Go With The Flow: Web Services Composition Standards Exposed. Web Services - Been There Done That?" [IEEE Intelligent Systems Jan/Feb 2003]. [source supplied by the authors]

  • [December 18, 2002] "Business Process with BPEL4WS: Learning BPEL4WS, Part 4. Creating Processes With the BPWS4J Editor." By Nirmal Mukhi (Software Engineer, IBM). From IBM developerWorks, Web services. November 2002. ['BPWS4J is an implementation of the BPEL4WS specification that includes a run-time engine and an editor (which is an Eclipse plugin) for creating BPEL4WS processes. In this article Nirmal describes design approaches to creating BPEL4WS processes, and how the BPWS4J editor is used to create, modify, and validate such processes.'] "The Business Processes in Web Services for Java (BPWS4J) software package offers an implementation of a run-time engine that supports the Business Process Execution Language for Web Services (BPEL4WS) specification, which defines workflow and business processes for Web services. This package, was released on alphaWorks in August to provide a run-time engine and a workflow editing tool for creating flows. This article focuses on an implementation exercise of a simple echo process flow, where one process receives the message and the other party reflects an identical copy of the message back to the sender... A complete, deployable unit for the BPWS4J runtime consists of: (1) The BPEL4WS file describing the process; (2) a WSDL file describing the messages, operations, port types and other information (service link types, correlation properties, etc.) that are referenced by the process definition (known as the process WSDL), and (3) the WSDL definitions for each partner involved in the process, unless the process does not make use of any WSDL operations provided by the partner. Of these, the BPWS4J editor allows you to create the BPEL4WS file describing the process. To edit WSDL files required for deploying a BPEL4WS process, you can use other tools. However, these will not support non-standard WSDL extensions that have been proposed within the BPEL4WS specification, such as service links, correlation properties, etc. Those definitions will have to be added in by hand; the samples in BPWS4J should serve as a sufficient guide for this. I will explain what the BPWS4J editor looks like and how it functions while developing the echo process example..." For other installments in the series, see the Summary. Also in PDF format.

  • [December 11, 2002] "IBM, BEA Take Royalty-Free Stance on BPEL4WS." By Paul Krill. In InfoWorld (December 11, 2002). "Removing a potential barrier to Web services choreography standards efforts, an IBM official on Wednesday pledged that the vendor will not seek royalties for its contributions to the BPEL4WS (Business Process Execution Language for Web Services) proposal. BEA Systems, a co-author of BPEL4WS, released a statement with a similar pledge shortly thereafter. Still remaining to be heard from is Microsoft, also a BPEL4WS co-author, pertaining to its stance on royalties related to the proposal. Bob Sutor, director of Web services strategy at Armonk, N.Y.-based IBM, said he could not speak for the positions of the two co-authors of BPEL4WS pertaining to royalties. 'As far as IBM is concerned, we will license BPEL4WS on a royalty-free basis,' Sutor said during a presentation at the CNet Networks 'Building a Web Services Foundation' conference... BEA released a statement that it would submit its technologies for BPEL4WS sans royalties if the other two vendors do as well. 'BEA has been on record for a long time now advocating that all standards be royalty-free and have committed that any standard we have control over will be offered royalty-free. However, BPEL4WS is a standard backed by three companies, so all three have to agree on the royalty-free position. BEA has long pushed for it to be royalty-free -- so if IBM and Microsoft also come on board agreeing with that position, then we will of course continue to advocate it be submitted as a royalty-free standard,' said San Jose, Calif.-based BEA. Sutor cautioned that observers should not become simplistic in regards to royalty-free proposals in general. IBM, for example, could have conditions such as requiring that other vendors provide their technology royalty-free if IBM does. Web services choreography standardization pertains to defining industrywide mechanisms and formats for interaction among Web services. An example where this would come into play would be an e-business transaction that requires multiple Web services to interact on matters such as filling orders, checking inventory, and performing credit checks, according to Sutor. Choreography is considered a major factor in furthering use of Web services, and it is the subject of both BPEL4WS, which has yet to be submitted to an industry standards organization, and Web Services Choreography Interface, a Sun Microsystems-led proposal already under consideration by the World Wide Web Consortium (W3C). Although the BPEL4WS authors plan to submit the plan to a standards organization, no decision has yet been made on which one, and that is not expected for a month or two, Sutor said..."

  • [October 15, 2002] "Asynchronous Operations and Web Services, Part 3: Add Business Semantics to Web Services. Three new specifications open a world of e-business possibilities." By Holt Adams (Engagement Manager and Solutions Architect, IBM jStart). From IBM developerWorks, Web services. October 2002. ['In previous installments of this series, Holt Adams explained the relevance of asynchronous operations for Web services and saw some patterns for building asynchronous services. Now he tackles three new specifications -- Business Process Execution Language for Web Services, Web Services Coordination, and Web Services Transaction -- and explains how they open up a world of possibilities for Web services developers. You'll see how these three specifications can support asynchronous operations and create an operational programming environment that mirrors real-life business interactions.'] "The development of the Business Process Execution Language for Web Services, Web Services Coordination, and Web Services Transaction specifications is a critical step toward enabling enterprises to leverage Web services in modeling their real-world processes. With BPEL, you can describe a long-running, multistep process of a business transaction using activities to encompass atomic transactions for individual process steps. Once a process is described using the BPEL XML flow language, a business process engine must interpret the process description in order to execute and manage the business transaction. The business process engine will provide the infrastructure services and resources for enabling long-running stateful business transactions that require interactions between the process, internal services, and external partner services (which themselves could be individual services exposed by the partners' process flows). However, at this time, before enterprise processes can be fully realized in an operational programming environment, IBM and other vendors will need to update their business process engines to interpret the BPEL XML flow language and to support the coordination and transactional facilities outlined in the WS-C and WS-T specifications. Likewise, these three critical specifications will need to be moved into a standards organization and approved as open standards. Currently, IBM, Microsoft, and BEA are working towards that goal. Once business process engines generally support BPEL, WS-C, and WS-T, the IT staff of any enterprise that seeks to automate steps in its business processes by leveraging Web services technology and the new specifications will need to: (1) Describe the enterprise's processes using the BPEL XML flow language; (2) Provide the business logic for the activities; (3) Provide the Web services interfaces for legacy applications -- for example, transaction resource managers -- that will be utilized in the process flow activities for realizing the business transaction; (4) Inform the business process engine how to locate the Web services utilized within the process flow activities..."

  • [October 07, 2002] "Business Process with BPEL4WS: Learning BPEL4WS, Part 3. Activities and the in-memory model." By Matthew Duftler and Rania Khalaf (IBM). From IBM developerWorks, Web services. October 2002. Series: "Business Process with BPEL4WS." ['The recently released Business Process Execution Language for Web Services (BPEL4WS) specification is positioned to become the Web services standard for composition. This series of articles aims to give readers an understanding of the different components of the language, and teach them how to create their own complete processes. The previous parts of the series gave an overview of the language, and took readers through creating their first simple process. This part will cover each of the activities in more detail. We will also cover how the various BPEL4WS constructs may be represented and manipulated in memory.'] "Now that we've gone over the language basics (Part 1), and we have created a simple example (Part 2), let's go over how to use each of the activities in more detail. In this article, we will provide detailed descriptions of each of the BPEL4WS activities. We will also describe the in-memory representation employed by BPWS4J to represent BPEL4WS processes, and give an example illustrating the model's use... Basic activities are the simplest form of interaction with the outside world. They are non-sequenced and individual steps that interact with a service, manipulate the passing data, or handle exceptions. There are three activities a process can use for interacting with the outside world: <invoke>, <reply>, and <receive>. As we saw in the previous articles, the interactions occur with the partners of the process using these three activities. By specifying a portType, operation, and partner, each of these activities identifies the Web services call it belongs to. The <invoke> activity is used by a process to make invocations to Web services provided by partners. In addition to the portType, partner, and operation, the invoke specifies input and output containers, for the input and output of the operation being invoked. An invocation can be either synchronous (request/response) or asynchronous (one-way). In the latter case, only an input container is required. A business process provides services to its partners through a pair of <receive> and <reply> activities. The receive represents the input of a WSDL operation provided by the process. If the process needs to send back a reply to the partner who sent the message, then a reply activity is necessary. Multiple reply activities may be defined in the process to answer that partner's call; however, only one matching <reply> may become active at any one time. The matching of the appropriate reply activity is done at runtime, when the process looks for such an activity that is ready to run and has the same portType, operation, and partner as the <receive>..."

  • [September 28, 2002] "A Comparison of XPDL, BPML, and BPEL4WS." By Robert Shapiro (President and Chief Technology Officer, Cape Visions). Published by ebPML.org. 'Rough Draft' version 1.4, August 27, 2002. 17 pages. "The Business Process Modeling Language (BPML) is representative of a new family of process definition languages intended for expressing abstract and executable processes that address all aspects of enterprise business processes, including in particular those areas important for webbased services. Microsoft's XLANG is another member of this family, as is IBM's Web Services Flow Language (WSFL). These latter two have now been combined in BPEL4WS. In this paper we focus on a comparison of BPML with XPDL, the WfMC proposed standard for an XML-based process definition interchange language. Comments in red have been added to extend the comparison to BPEL4WS, hereafter abbreviated to BPEL... Our primary objective is to clarify the differences between the BPML and XPDL (and BPEL) paradigms. We are interested in exposing what can be done with one language and cannot be done, or done only with difficulty in the other. When simple extensions are possible, we propose them. We are also concerned about the work being done by the three standards organizations: WfMC, OMG, and BPMI..." Note: "ebPML.org promotes a new vision for IT infrastructures shared by many and based on the convergence of several technologies and standards, including but not limited to: Business Process Management Systems, ebXML, Web services, and Content standards such as OAGIS the standard of the open application group, or RosettaNet." [source .DOC 2002-09-28, fetch from www.ebpml.org/ for update]

  • [September 23, 2002] "Comparison of DAML-S and BPEL4WS." By Sheila McIlraith and Dan Mandell (DAML Research Project, Knowledge Systems Lab, Stanford University). Initial Draft. September 05, 2002 (or later). With 9 references. "... DAML-S and BPEL4WS have broad and somewhat complementary objectives. DAML-S's ServiceProfile complements and extends ideas in UDDI. DAML-S's ServiceGrounding connects the application level content description of a service to communication level descriptions in WSDL. It is the ServiceModel (aka ProcessModel) in DAML-S that relates most closely to the business process model in BPEL4WS. Both provide a mechanism for describing a business process model. With so many candidate formalisms for describing a business process (e.g., XLANG, WSFL, BPMI, BPML, now BPEL4WS, etc.) DAML-S was designed to be agnostic with respect to a process model formalism. Rather, it aimed to provide the vocabulary and agreed upon (necessary) properties for a process models. In so doing, we hoped to remain compatible with what we anticipated would eventually be an agreed upon standard for process modeling. If such a standard did not come to pass, DAML-S would provide a way of talking about different process models, in keeping with the approach and spirit of NIST's Process Specification Language (PSL). Here are some of the features that distinguish/differentiate DAML-S from BPEL4WS..." [Posting to W3C list]

  • [September 19, 2002] "Model Programs. Business Process Modeling Tools Help Put the Enterprise In Perspective." By Kevin Jonah. In Government Computer News Volume 21, Number 27 (September 09, 2002), pages 52-54. "The main benefits to government of BPM tools are clear. They help agencies make better spending decisions and comply with regulations, and provide a road map for cross-agency collaboration. But the corresponding arrival of BPM religion in the government and a new wave of application technologies has offered another benefit: the opportunity to reuse all that modeling information to devise new automated processes, which reduces software development costs and speeds the response of agencies to e-government requirements... IDEF [a key set of standards for most government data and process modeling] was created in the 1970s by the Air Force's Program for Integrated Computer Aided Manufacturing. It was extended by the National Institute of Standards and Technology with support from the Defense Department's Office of Corporate Information Management and issued as a Federal Information Processing Standard... IDEF now consists of 16 specifications for various types of information modeling. The specification most relevant to business process modeling is the IDEF3 Process Description Capture Method. IDEF3 is a format for capturing information about the relationship between events -- the steps in a process -- and the situations, or states that occur within the process... new standards for describing the underlying information in models have been developed, making it possible to more easily move model data from one type of analysis tool to another, and to quickly generate automated processes with models. The most important of these new modeling languages are the Unified Modeling Language (UML) and Business Process Modeling Language (BPML)... While UML doesn't correspond directly to IDEF3, some modeling tools can bridge the gap. Popkin Software's System Architect, for example, can move models from IDEF3 to UML use cases and back. BPML is a different animal from UML and IDEF3. It is a dialect of XML designed for the world of asynchronous distributed systems -- in other words, Web services. The first draft of BPML was made public on March 8 last year. While IDEF3 and UML are used to capture information about processes, BPML is intended to actually drive automated processes, according to the Business Process Modeling Initiative, a consortium of companies that is developing BPML and a related standard, the Business Process Query Language. BPML connects automated processes across applications through Web services and application messaging standards such as the Simple Object Access Protocol, Electronic Business XML, RosettaNet and Microsoft BizTalk. It incorporates data flow, event flow and control of the process, along with providing for business rules, transaction requirements and security roles within a process. While many companies have announced that they will support BPML, few have implemented it. BPML is still something of a work in progress. But major infrastructure companies like IBM Corp., Hewlett-Packard Co. and Sun Microsystems Inc. have thrown their support behind BPML. Middleware and application vendors, and even major corporate customers like General Electric and insurer Swiss Re, also are on board, so BPML eventually will have a major impact... Microsoft, BEA Systems Inc. and IBM recently announced the Business Process Execution Language for Web Services (BPEL4WS), which is closely related to BPML. Popkin said he sees the two converging..."

  • [September 19, 2002] "The WfMC Heralds BPEL4WS Standards for Business Process Management Industry." - "The Workflow ManagementCoalition (WfMC) is pleased to note the activity of major vendors such as IBM and Microsoft in the development of process definition languages and tools that are critical to workflow and other system technologies. Both IBM and Microsoft are funding members of the WfMC and were early contributors to the workflow standards including those involving process definition. The recently announced Business Process Execution Language for Web Services (BPEL4WS) is a platform for executing business processes so that they can be more easily reused and integrated with other processes. The specification enables simple execution of such processes in a web services environment. The first review of BPEL4WS suggests that the proposal is compatible with IBM and Microsoft products and therefore the proposed standard may receive de-facto support through adoption of these vendors' products. It is also apparent that almost all the features of BPEL4WS are already represented in the WfMC XPDL specification. However, there are numerous additional capabilities in the WfMC standards, such as Wf-XML, which is the process execution standard, that were not found in the specification announced by Microsoft and IBM... The WfMC has identified five functional interfaces to a workflow service as part of its standardization program. The XPDL (XML Process Definition Language) specification forms part of the documentation relating to 'Interface one' -- supporting Process Definition Import and Export. This interface includes a common meta-model for describing the process definition (this specification) and also an XML schema for the interchange of process definitions. The WfMC is committed to support the users of workflow technology for all purposes. Workflow has evolved to move work between organizations including those in separate enterprises, beyond its initial role of managing the distribution of work between people. The Coalition focuses on both the function and content of those communications as well as the tools and languages (such as XML). Work will continue on the Coalition standards as well as liaison with organizations working in related technology areas such as BPMI (collaboration announced in June 2002). The WfMC will continue to be sensitive to the wider needs of the industry and if the new BPEL4WS facilities become a significant industry direction, the Coalition will extend its focus to include that approach..."

  • [September 10, 2002] "Business Process with BPEL4WS: Learning BPEL4WS, Part 2. Creating a Simple Process." By Rania Khalaf (Software Engineer, IBM TJ Watson Research Center). From IBM developerWorks, Web services. August 2002. ['The recently released Business Process Execution Language for Web Services(BPEL4WS) specification is positioned to become the Web services standard for composition. It allows you to create complex processes by creating and wiring together different activities that can, for example, perform Web services invocations, manipulate data, throw faults, or terminate a process. These activities may be nested within structured activities that define how they may be run, such as in sequence, or in parallel, or depending on certain conditions. This series of articles aims to give readers an understanding of the different components of the language, and teach them how to create their own complete processes. The first part of the series will take readers through creating their first simple process. Subsequent parts will extend the example in different ways to illustrate and explain the key parts of the language, including data manipulation, correlation, fault handling, compensation, and the different structured activities in BPEL4WS.'] "In order to demonstrate how activities may be created and aggregated with BPELWS, I will describe a simple example that processes loan requests. This article will illustrate the main aspects of a composition, as well as show how the WSDL descriptions of services relate to and are used by the BPEL4WS process definition. A complete process is created while explaining the use of partners for interaction, containers for holding messages, and the activities for interacting with the outside world, namely <receive>, <reply>, and <invoke>. In addition to describing how the process will run, I also show how to deploy and run it using the BPWS4J engine available on alphaWorks... In the next part of this article, I will go through some more parts of the BPEL4J language and illustrate their usage by adding more activities to the loan approval example. In order not to be confusing, the additions will keep bringing the sample closer to the one in the specification and BPWS4J release. In the meantime, you may want to read the other articles available about the language and the runtime..." Also in PDF format.

  • [September 10, 2002] "Business Process with BPEL4WS: Understanding BPEL4WS, Part 1. Concepts in Business Processes." By Sanjiva Weerawarana and Francisco (Paco) Curbera (Research Staff Members, IBM TJ Watson Research Center). From IBM developerWorks, Web services. August 2002. ['The recently released Business Process Execution Language for Web Services (BPEL4WS) specification is positioned to become the Web services standard for composition. It allows you to create complex processes by creating and wiring together different activities that can, for example, perform Web services invocations, manipulate data, throw faults, or terminate a process. These activities may be nested within structured activities that define how they may be run, such as in sequence, or in parallel, or depending on certain conditions. This series of articles aims to give readers an understanding of the different components of the language, and teach them how to create their own complete processes. The first part of the series will take readers through creating their first simple process. Subsequent parts will extend the example in different ways to illustrate and explain the key parts of the language, including data manipulation, correlation, fault handling, compensation, and the different structured activities in BPEL4WS.'] "Today Web services can communicate with each other, advertise themselves, and be discovered and invoked using industry-wide specifications. However, until last week, linking these services together into a business process or a composition gave the user a number of conflicting specifications to choose from -- as was the case with WSFL from IBM and XLANG from Microsoft. The Business Process Execution Language for Web Services (BPEL4WS) represents the merging of WSFL and XLANG, and with luck, will become the basis of a standard for Web service composition. BPEL4WS combines the best of both WSFL (support for graph oriented processes) and XLANG (structural constructs for processes) into one cohesive package that supports the implementation of any kind of business process in a very natural manner. In addition to being an implementation language, BPEL4WS can be used to describe the interfaces of business processes as well -- using the notion of abstract processes. We will elaborate further on this is future articles... Ee briefly explain the main underlying concepts of BPEL4WS. We consider the overall view of what BPEL4WS is about and then about partners, faults, compensation, and lifecycle. In the future articles of this series we expect to discuss various specific aspects of BPEL4WS in detail..." Also available in PDF format.

  • [August 21, 2002] "Dynamic e-Business Using BPEL4WS, WS-Coordination, WS-Transaction, and Conversation Support for Web Services." By Santhosh Kumaran and Prabir Nandi (IBM T. J. Watson Research Center). Presented with the (downloadable) IBM alphaWorks application "Conversation Support for Web Services." "IBM, MS, and BEA have just announced a set of Web services standards for automating business processes on the Web: BPEL4WS for executable specification of business processes, WS-Coordination for specifying an extensible framework for the coordination of actions of distributed applications, and WS-Transaction for coordination types that are used with the framework described in WS-Coordination. Additionally, IBM is making available through alphaWorks a technology called 'Conversation Support for Web Services' for supporting conversational model of interaction between distributed, autonomous systems. The goal of this document is to articulate a vision in which these complementary technologies work together enabling dynamic e-Business. We begin with a very brief overview of the technologies. Then we introduce a travel reservation scenario and use various levels of sophistication of this scenario to motivate the use of various technologies. We conclude with a summary of the complementary features that the conversation model brings to the table... Conversation Support for Web Services (CS-WS) proposes a set of specifications to support a conversational model of component integration using Web Services. The specifications include a XML dialect to describe a conversation interaction, called Conversation Policy (CP). CPs are preprogrammed interaction patterns or protocols and is used to specify the message formats, sequencing constraints, and timing constraints that define the interaction protocol. The other set of specification extends the Java Connector Architecture APIs, both at the system and application level to provide a standard runtime framework to execute CPs on a J2EE Application Server... BPEL4WS, WS-Coordination, and WS-Transaction, along with WSDL and UDDI, provide the basis for the programming model for dynamic e-Business. Below we summarize the significant and complementary features that Conversations bring to this model as explained in 'Travel Reservation Scenario: Stage 3': (1) Dynamic and flexible interaction patterns as shown by the ability of the conversation technology to support complex interactions between Acme and customers. (2) Adaptable, open-ended, and extensible B2B integration capability as demonstrated in the ability of the conversation module to account for interface changes. (3) Conversation module serves as a process broker layer dealing with multiple business protocols that the partners employ to provide the business services the BPEL processes expect. For example, different car companies may have different protocols for making a reservation; the conversation module supports the selection of the right protocol while utilizing the same BPEL processes. (4) Message handling based on explicit conversation state. A very good example is shown in the travel reservation example, in which there could be several loops and state changes at the conversation level before a transaction is completed. (5) Executable business protocols, nested protocols, and protocol switching as demonstrated in the travel scenario..." See: (1) "Web Services Specifications for Business Transactions and Process Automation" and (2) "IBM alphaWorks Releases Conversation Support for Web Services."

  • [August 20, 2002] "Automating Business Processes and Transactions in Web Services. An Introduction to BPELWS, WS-Coordination, and WS-Transaction." By James Snell (IBM Emerging Technologies). From IBM developerWorks, Web Services Zone. August 2002. ['The new Business Process Execution Language for Web Services, WS-Transaction, and WS-Coordination specifications provide a comprehensive business process automation framework that allows companies to leverage the power and benefits of the Web Services Architecture to create and automate business transactions. Here we present a high level executive overview of what the three new specifications provide.'] "The role of dynamic e-business within the enterprise is to simplify the integration of business and application processes across technological and corporate domains. The relatively recent advent of Web service technologies such as SOAP, WSDL, and UDDI has helped to evolve our thinking about how distributed applications can connect and work together in an increasingly dynamic way, yielding a more dynamic economic environment. None of these core Web service specifications (SOAP, WSDL, UDDI, etc) were designed to provide mechanisms by themselves for describing how individual Web services can be connected to create reliable and dependable business solutions with the appropriate level of complexity. The technology industry has not yet produced a single standardized Web services view of how to define and implement business processes so that such connections can be described. To address the concerns and needs of our customers, IBM again teamed with Microsoft and others to develop and propose a Business Process Execution Language for Web Services, a new specification that replaces and offers additional functionality and greater flexibility over previous individual efforts on the IBM Web Services Flow Language (WSFL) and Microsoft XLANG grammar. The Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) is a XML-based workflow definition language that allows businesses to describe sophisticated business processes that can both consume and provide Web services. In this document we will introduce the fundamental principles of BPEL as well as two significant and complementary specifications, WS-Coordination and WS-Transaction, also developed jointly by IBM and Microsoft. These deal with how one coordinates the dependable outcome of both short- and long-running- business activities. This issue is central to the successful implementation of a distributed business process. To illustrate the function and benefits of the BPEL, WS-Transaction, and WS-Coordination specifications, we will explore the application of those technologies to a real-world business scenario..."

  • "Tech Giants Drive New Web Services." By Wylie Wong. In ZDNet News (August 08, 2002).

  • "IBM, Microsoft, BEA Target Web Services Reliability." By John Fontana. In Network World Fusion. August 08, 2002.

  • "New Web Services Specs on Horizon." By Darryl K. Taft. In eWEEK (August 9, 2002).

  • "IBM, BEA, Microsoft Team Up On New Web Services Specs." By Elizabeth Montalbano. In CRN (August 08, 2002).

  • "Microsoft, IBM, BEA to Unleash Trio of Web Services Specs." By Carolyn A. April. In InfoWorld (August 08, 2002).
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/bpel4ws.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org