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: October 15, 2004
Standards for Business Process Modeling, Collaboration, and Choreography

Provisional reference document for business process definition, process modeling, choreography, orchestration, collaboration, workflow, etc. See also the collection of references for specifications and standards activities related to coordination of messages/transactions, especially in the Web Services arena: "Messaging and Transaction Coordination."

Business Process Execution Language for Web Services (BPEL4WS)

Version 1.1 of Business Process Execution Language for Web Services was published 31-March-2003 (and in a slightly different format 20-March-2003). A website notice from Microsoft 2003-04-16 read: "Business Process Execution Language for Web Services (BPEL4WS) Submitted to OASIS. Microsoft Corp., along with IBM, BEA, and SAP, has submitted BPEL4WS version 1.1 to OASIS, adding a more modular structure to the initial specification announced in August 2002 by Microsoft, IBM, and BEA..." See details below.

Version 1.0 of the Business Process Execution Language for Web Services specification was published on July 31, 2002 by BEA Systems, International Business Machines Corporation, and Microsoft Corporation, Inc.

The BPEL4WS specification "defines a notation for specifying business process behavior based on Web Services called Business Process Execution Language for Web Services. 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." [from the Abstract]

References:

Business Process Management Initiative Specifications (BPML, BPMN, BPQL)

BPMI.org (Business Process Management Initiative) "is a non-profit organization that empowers companies of all sizes, across all industries, to develop and operate business processes that span multiple applications and business partners, behind the firewall and over the Internet... The Initiative's mission is to promote and develop the use of Business Process Management (BPM) through the establishment of standards for process design, deployment, execution, maintenance, and optimization. BPMI.org develops open specifications, assists IT vendors for marketing their implementations, and supports businesses for using Business Process Management technologies. "

Specifications: The Business Process Modeling Language (BPML) is a meta-language for the modeling of business processes, just as XML is a meta-language for the modeling of business data. BPML provides an abstracted execution model for collaborative and transactional business processes based on the concept of a transactional finite-state machine. More on BPML. The Business Process Modeling Notation (BPMN) specification provides a graphical notation for expressing business processes in a Business Process Diagram (BPD). The BPMN specification also provides a binding between the notation's graphical elements and the constructs of block-structured process execution languages, including BPML and BPEL4WS. The first draft of BPMN was made available to the public on November 13, 2002... The Business Process Query Language (BPQL) defines a standard interface to forthcoming Business Process Management Systems (BPMS). It allows system administrators to manage the BPMS and business analysts to query the instances of business processes it executes." Note: BPQL has not been released to the public as of 2003-04-04.

[August 29, 2003]   BPMI.org Releases Business Process Modeling Notation (BPMN) Version 1.0.    The BPMI Notation Working Group has announced the release of a public draft for the Business Process Modeling Notation (BPMN Version 1.0). The BPMN specification "provides a graphical notation for expressing business processes in a Business Process Diagram (BPD). The objective of BPMN is to support process management by both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics. As an amalgamation of best practices within the business modeling community, BPMN provides a simple, standardized means of communicating process information to other business users, process implementers, customers, and suppliers. BPMN 1.0 allows different XML-based process languages, e.g., Business Process Execution Language for Web Services (BPEL4WS v1.1) and Business Process Modeling Language (BPML v1.0), to be visualized using common elements. BPMN is a comprehensive notation and points toward the convergence of open standards for business process management by enabling practitioners to more easily exchange business process models between different business process languages using a standardized graphical notation."

References:

ebXML Business Process Specification Schema (BPSS)

"The [OASIS] ebXML Business Process Specification Schema provides a standard framework by which business systems may be configured to support execution of business collaborations consisting of business transactions. It is based upon prior UN/CEFACT work, specifically the metamodel behind the UN/CEFACT Modeling Methodology (UMM) defined in the N090R10 specification. The Specification Schema supports the specification of Business Transactions and the choreography of Business Transactions into Business Collaborations. Each Business Transaction can be implemented using one of many available standard patterns. These patterns determine the actual exchange of Business Documents and business signals between the partners to achieve the required electronic commerce transaction. The current version of the specification schema addresses collaborations between two parties (Binary Collaborations) as well as collaboration involving more than two business partners (Multiparty Collaborations) as a synthesis of binary collaborations. It is anticipated that a subsequent version will address additional features such as the semantics of economic exchanges and contracts, more complex multi-party choreography, and context based content... This document describes the Specification Schema in its UML form and provides the corresponding XML Schema which every Specification Schema instance must conform to. The document first introduces general concepts and semantics, then applies these semantics in a detail discussion of each part of the model. The document then specifies all elements in the UML form, and then in XML form... The ebXML Business Process Specification Schema provides a standard framework for business process specification. As such, it works with the ebXML Collaboration Protocol Profile (CPP) and Collaboration Protocol Agreement (CPA) specifications to bridge the gap between Business Process Modeling and the configuration of ebXML compliant e-commerce software, e.g., an ebXML Business Service Interface." [from the v1.05 draft]

References:

OASIS Web Services Business Process Execution Language TC (WSBPEL)

[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.

References:

OASIS Business Transaction Protocol (BTP)

"BTP is an Extensible Markup Language (XML)-based protocol for representing and seamlessly managing complex, multi-step business-to-business (B2B) transactions over the Internet. The protocol allows complex XML message exchanges to be tracked and managed as loosely coupled 'conversations' between and among businesses. BTP goes beyond the problem domain currently being addressed by ebXML and is independent of transport protocols and messaging frameworks. We believe that it can be layered on any underlying transport mechanism including ebXML Messaging, RosettaNet, or XML-PC (SOAP)." [from the TC Charter]

"BTP is designed to allow coordination of application work between multiple participants owned or controlled by autonomous organizations. BTP uses a two-phase outcome coordination protocol to ensure the overall application achieves a consistent result. BTP permits the consistent outcome to be defined a priori -- all the work is confirmed or none is -- (an atomic business transaction or atom) or for application intervention into the selection of the work to be confirmed (a cohesive business transaction or cohesion). BTP's ability to coordinate between services offered by autonomous organizations makes it ideally suited for use in a Web Services environment. For this reason this specification defines communications protocol bindings which target the emerging Web Services arena, while preserving the capacity to carry BTP messages over other communication protocols. Protocol message structure and content constraints are schematized in XML, and message content is encoded in XML instances. The BTP allows great flexibility in the implementation of business transaction participants. Such participants enable the consistent reversal of the effects of atoms. BTP participants may use recorded before- or after-images, or compensation operations to provide the 'roll-forward, roll-back' capacity which enables their subordination to the overall outcome of an atomic business transaction..." [from the spec]

References:

OASIS ebXML Business Process Technical Committee (ebXML BP TC)

In September 2003, a new OASIS ebXML Business Process Technical Committee (ebXML BP TC) was formed to "continue work on a royalty-free technology representation and model compatible with an underlying generic metamodel for business processes, activities, and collaboration. This business collaboration could occur within or between enterprises. The collaboration may be enforceable, easily manageable, and/or traceable. This representation and model will provide a set of guidelines to define the business process-rules, semantics and syntax for both binary and multi-party collaborations. The representation and model will work within the ebXML architecture (for metamodel and model exchange) and will also support standards-based development and exchange of business process definitions. The OASIS ebXML Business Process TC's effort will address and align with vertical industry needs for business process collaboration and focus on ease of use. The specification can be integrated into and bind with existing or emerging technologies. The TC's work should build upon similar, existing standards wherever possible and align with other relevant standards for feature reuse, bindings, guidelines on how to jointly use the specification with other related standards, and addressing requirements from other related standards. The TC will base its work upon the ebXML Business Process Specification Schema Version 1.01 jointly developed by OASIS and UN/CEFACT, and upon derivative work expected to be donated by co-sponsors and participants." The proposed TC Co-Chairs are Dale Moberg (Cyclone Commerce) and Monica J. Martin (Sun Microsystems). The first meeting of the OASIS ebXML Business Process TC will be held on October 20, 2003 as a teleconference. [Full context]

References:

OMG Business Process Definition

The OMG's Business Enterprise Integration (BEI) DTF is seeking to standardize a metamodel for Business Process Definition. RFPs have been issued for a Business Process Definition Metamodel, a UML Profile for Business Process Definition, and a Business Process Runtime Interfaces Platform Independent Model (PIM). Also, in January 2003 a new OMG Business Rules Special Interest Group was chartered; "it will promote standards for modeling of businesses, business requirements, and business rules within OMG."

From the Business Process Definition Metamodel RFP: "Proposals should address the need to specify the choreography of collaborations between business processes. The model should facilitate validation of compliance of a business process or related business processes with the associated choreography. While the primary driver of choreography specifications is the specification of inter-enterprise web services collaborations, the same concepts should be applicable to choreography of interactions between business processes within an enterprise... Business process collaborations may occur within an enterprise or between enterprises. When they occur between enterprises, it is more important that they be formalized and robust. The choreography must clearly define what each participant is expected to do as the collaboration progresses, and the consequences if they fail to meet expectations or the communication between them breaks down. Thus, choreography specifications will be particularly important for more complex business exchanges using web services technology. Choreography is not executed like other business processes. It is accomplished through the independent actions of the participants. The specification of choreography in a business process definition model expresses requirements for the supporting business processes. Generally the modeler will only be concerned with the supporting business process of one participant, but a model could include specifications for business processes of multiple participants. In general, the choreography will describe the states and state transitions of participants as perceived by the other participants, and the messages exchanged as a result of state transitions. A perceived state transition may actually involve a number of actions and state transitions internal to the participant, performed by its internal, executable business processes..."

References:

  • Object Management Group (OMG) website
  • "Business Process Definition Metamodel. Request For Proposal." Object Management Group. OMG Document Reference: bei/2003-01-06. Letters of Intent due: June 16, 2003. Submissions due: August 18, 2003. 33 pages. Contact: Mr. Manfred R. Koethe. "This RFP solicits submissions that specify a business process definition metamodel, which is platform independent with respect to specific business process definition languages. This metamodel will define an abstract language for specification of executable business processes that execute within an enterprise (with or without human involvement); and may collaborate between otherwiseindependent business processes executing in different business units or enterprises. The specification developed in response to this RFP is expected to achieve the following: (1) A common metamodel to unify the diverse business process definition graphical and textual notations that exist in the industry; (2) A metamodel that complements existing UML metamodels so that business processes specifications can be part of complete system specifications to assure consistency and completeness; (3) The ability to integrate process models for workflow management processes, automated business processes, and collaborations between business units; (4) Support for the specification of choreography, describing the collaboration between participating business entities using lightweight collaboration mechanisms (e.g. Webservices); and the ability to reconcile the choreography with supporting internal business processes; (5) The ability to exchange business process specifications between modeling tools, and between tools and execution environments using XMI... [source PDF, reference page]
  • "OMG UML Profile for Business Process Definition. Request For Proposal." Object Management Group (OMG). Draft September 30, 2002. OMG Document Reference: BEIDTF/2002-09-02. Letters of Intent due: April 14, 2003. Submissions due: May 12, 2003. "This RFP solicits submissions that specify a UML profile for business process definitions. These business process definitions may describe managed business processes that are enacted in controlled, recoverable environments, or they may describe collaboration processes that occur through the interaction of two or more business entities, or they may describe complex processes that involve both these types of processes. The specification developed in response to this RFP is expected to achieve the following: (1) Robust representation of business processes; (2) Support for leading business process modeling notations; (3) Business process models that are compatible with existing UML modeling elements; (4) Integration of process models for workflow management processes, automated business processes, and implicit processes performed by collaborating business entities; (5) Support for modeling business processes as components of complete system specifications to assure consistency and completeness of specifications; (6) Support for the specification of web services collaboration processes and the internal business processes with which they interact to perform system-to-system electronic business transactions." [source PostScript]
  • "Business Process Runtime Interfaces (BPRI) Platform Independent Model (PIM). Request For Proposal." OMG Document: bei/2002-06-08. "This RFP is soliciting specifications for a platform-independent model (PIM) of the runtime interfaces to business processes. Business processes include workflow management but address a broader range of applications, including processes supporting electronic commerce and web services. This RFP does not include models to specify business processes, but only interfaces to business processes when they are executed. A business process in this context is a set of activities coordinated and controlled by the execution of a business process definition. The activities may be performed by people, computer applications or other business processes that together accomplish a business objective. Progress and thus the current status of a business process is established by committed states reflecting the initiation and completion of activities and occurrence of other key events in the execution of the process."

W3C Web Services Choreography Working Group

"The Web Services Choreography Working Group, part of the W3C Web Services Activity, is chartered to create the definition of a choreography, language(s) for describing a choreography, as well as the rules for composition of, and interaction among, such choreographed Web services. The language(s) should build upon the foundation of the Web Service Description Language 1.2 (WSDL 1.2).

Background: "Existing specifications for Web services describe the indivisible units of interactions. It has become clear that taking the next step in the development of Web services will require the ability to compose and describe the relationships between lower-level services. Although differing terminology is used in the industry, such as orchestration, collaboration, coordination, conversations, etc., the terms all share a common characteristic of describing linkages and usage patterns between Web services... Some observers predict that if no steps are taken to develop a choreography specification in a vendor-neutral forum, the Web services marketplace may be divided into a number of non-interoperable sub-networks. A vendor-neutral choreography specification which commands consensus and wide support, on the other hand, can make it much easier and cheaper to create composite Web services which integrate services from multiple vendors. Small and medium-sized enterprises will be able to create more complex and more useful Web services. This in turn will help the market grow much more vigorously than would be possible without a vendor-neutral specification for choreography. The problems posed by the lack of a widely adopted choreography specification, the current proliferation of overlapping work, and the time required to complete this effort merit the chartering a new W3C Working Group now. This Working Group should address the choreography space encompassed by the referenced documents. This Working Group should also coordinate with other Working Groups within the Web Service Activity, with the aim of developing an interoperable and open standard for Web service choreography..." [from the Charter]

References:

Web Service Choreography Interface (WSCI)

On June 28, 2002 the WSCI proposal was submitted to W3C by BEA Systems, BPMI.org, Commerce One, Fujitsu Limited, Intalio, IONA, Oracle Corporation, SAP AG, SeeBeyond Technology Corporation, and Sun Microsystems. The submission asks that the W3C "form a new Working Group within the Web Services Activity to continue the evolution of this proposal. This Working Group (WG) would address Web service choreography and coordinate with other working groups within the Activity, such as the Web Services Description WG, with the aim of developing an interoperable and open standard for Web-based service choreography." WSCI is referenced in the W3C Web Services Choreography Working Group Charter.

The Web Service Choreography Interface (WSCI) is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services. WSCI describes the dynamic interface of the Web Service participating in a given message exchange by means of reusing the operations defined for a static interface. WSCI works in conjunction with the Web Service Description Language (WSDL), the basis for the W3C Web Services Description Working Group; it can, also, work with another service definition language that exhibits the same characteristics as WSDL. WSCI describes the observable behavior of a Web Service. This is expressed in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. WSCI also describes the collective message exchange among interacting Web Services, thus providing a global, message-oriented view of the interactions. WSCI does not address the definition and the implementation of the internal processes that actually drive the message exchange. Rather, the goal of WSCI is to describe the observable behavior of a Web Service by means of a message-flow oriented interface. This description enables developers, architects and tools to describe and compose a global view of the dynamic of the message exchange by understanding the interactions with the web service."

References:

Web Services Conversation Language (WSCL)

On February 04, 2002 Hewlett-Packard Company (HP) submitted a WSCL specification to the W3C. The submission was published as a Note. "Web Services Conversation Language (WSCL) allows the abstract interfaces of Web services, i.e., the business level conversations or public processes supported by a Web service, to be defined. WSCL specifies the XML documents being exchanged, and the allowed sequencing of these document exchanges. WSCL conversation definitions are themselves XML documents and can therefore be interpreted by Web services infrastructures and development tools. WSCL may be used in conjunction with other service description languages like WSDL; for example, to provide protocol binding information for abstract interfaces, or to specify the abstract interfaces supported by a concrete service..."

References:

Web Services Flow Language (WSFL)

IBM released the WSFL specification in May 2001.

"The Web Services Flow Language (WSFL) is an XML language for the description of Web Services compositions. WSFL considers two types of Web Services compositions: (1) The first type specifies the appropriate usage pattern of a collection of Web Services, in such a way that the resulting composition describes how to achieve a particular business goal; typically, the result is a description of a business process. (2) The second type specifies the interaction pattern of a collection of Web Services; in this case, the result is a description of the overall partner interactions. In the first case, a composition is created by describing how to use the functionality provided by the collection of composed Web Services. This is also known as flow composition, orchestration, or choreography of Web Services. WSFL models these compositions as specifications of the execution sequence of the functionality provided by the composed Web Services. Execution orders are specified by defining the flow of control and data between Web Services. For this reason, in this document, we will also use the term flow model to refer to the first type of Web Services compositions. Flow models can especially be used to model business processes or workflows based on Web Services..." [from the Introduction]

References:

Workflow Management Coalition (WfMC) Specifications

"The Workflow Management Coalition "is a non-profit, international organization of workflow vendors, users, analysts and university/research groups. The Coalition's mission is to promote and develop the use of workflow through the establishment of standards for software terminology, interoperability and connectivity between workflow products. Consisting of over 300 members, spread throughout the world, the Coalition has quickly become established as the primary standards body for this rapidly expanding software market."

Published specifications include the XML Process Definition Language (XPDL), Workflow Reference Model, Workflow Resource Model, Interoperability Wf-XML Binding, and others.

References:

XLANG: Web Services for Business Process Design

Microsoft published the XLANG specification in May 2001.

Abstact: "Automation of business processes based on web services requires a notation for the specification of message exchange behavior among participating web services. This document specifies such a notation. We call it XLANG. XLANG is expected to serve as the basis for automated protocol engines that can track the state of process instances and help enforce protocol correctness in message flows..."

References:

Other Reference Websites

[Section under construction.]

Articles, Papers, News

  • [October 15, 2004] "A Comparison of XML Interchange Formats for Business Process Modelling." By Jan Mendling and Gustaf Neumann (Vienna University of Economics and BA, Wien, Austria); Markus Nüttgens (Hamburg University of Economics and Politics, Germany). Paper presented at EMISA 2004, "Information Systems in E-Business and E-Government", Workshop organized by the special interest group "EMISA - GI - Development Methods for Information Systems and their Application", Centre de Recherche Public - Gabriel Lippmann, Luxembourg, October 6-8, 2004. This paper addresses heterogeneity of business process metamodels and related interchange formats. The different approaches towards interchange format design and effects of interchange format specification are presented first. In particular completeness is identified as an important design criterion for interchange formats. Afterwards the superset of metamodel concepts is extracted from fifteen (15) currently available XML-based specifications for business process modelling. Furthermore, these concepts are used as a framework for comparing the completeness of the fifteen specifications (BPDM, BPEL4WS, BPML, BPMN, BPSS, EPML, OWL-S, PNML, UML Activity Diagram, WS-CDL, WSCI, WSCL, WSFL, XLANG, XPD). Thirteen metamodel concepts used in the analysis included Task I/O, Task Address, Protocol, Control Flow, Data Handling, Instance Identity, Roles, Quality Attributes, Events, Exceptions, Transactions, Graphic Position, and Statistical Data. The thirteen metamodel concepts were taken as a benchmark to compare the completeness of the 15 business process modelling interchange format proposals. The interchange formats are used in at least four different areas of application: (1) Composition: Composition refers to the definition of the internal implementation of executable business processes; Web Service composition defines executable business processes that are built from a set of Web Services; (2) Choreography: Choreography defines externally observable behavior of a business process; eb Service choreography refers to the correct content and order of messages that two parties exchange in a business process; (3) Business Analysis: Business analysis refers to the presentation of business processes to managers; it builds on visualization of processes and annotation with statistics; (4) Formal Analysis: This application refers to the verification of different formal quality criteria; these include e.g., soundness... With our work we aim to contribute to a better comparison of heterogenous approaches towards BPM which may finally result in a BPM reference metamodel and a related general interchange format for BPM. Yet, the high-level metamodel concepts identified in this paper need further in-depth analysis similar to the workflow pattern analysis reported in van der Aalst et al., 'Workflow Patterns', Distributed and Parallel Databases 14/1, July 2003, pages 5-51. Such analysis will be subject to future research..." [cache]

  • [November 20, 2003]   Event-Driven Process Chain Markup Language (EPML) for Business Process Modeling.    A communiqué from Jan Mendling (New Media Lab, Vienna University of Economics and Business Administration) describes the progress of a standardization initiative within the EPC Community, focused upon development of an Event-Driven Process Chain Markup Language (EPML). Event-Driven Process Chains (EPCs) are a method for representation of business process models, popular especially in Germany. EPML is motivated by the goal of supporting data and model interchange in the face of heterogenous Business Process Modeling tools. The chief design principles in EPML are "readability, extensibility, tool orientation, and syntactic correctness. Readability expects EPML elements and attributes to have intuitive and perspicuous names. This is important because EPML documents will be used not only by applications, but also by humans who write XSLT-scripts that transform between EPML and other XML vocabularies. Extensibility reflects the need to provide different business perspectives and views on a process. EPML will be capable of expressing arbitrary perspectives instead of supporting just a pre-defined set. Tool orientation deals with graphical representation of EPCs. This is a crucial feature because BPM tools provide a GUI for developing the models. EPML will be able to store various layout and position information for EPC elements. Finally, syntactic correctness addresses EPC syntax elements and their interrelation." An initial EPML XML Schema and supporting documentation have been published.

  • [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..."

  • [February 22, 2003] "Web Services Orchestration: A Review Of Emerging Technologies, Tools, and Standards." By Chris Peltz (Hewlett Packard, Developer Resource Organization). Technical Paper from HP Dev Resource Central (January 2003). 20 ages. "Web services technologies are beginning to emerge as a defacto standard for integrating disparate applications and systems using open, XML-based standards. In addition to building web services interfaces to existing applications, there must also be a standard approach to connecting these web services together to form more meaningful business processes. In 2002, a number of new standards were introduced to address this problem, including BPEL4WS and WSCI. The purpose of this paper is to provide a review of these emerging standards, to help the reader better understand how web services orchestration can be accomplished today." [cache]

  • [February 04, 2003] "Business Processes and Workflow in the Web Services World. A Workflow is Only As Good As the Business Process Underneath It." By Margie Virdell (e-business Architect, IBM Developer Relations). From IBM developerWorks, Web services. January 2003. "This article looks at business processes, their relationship to workflow and Web services today, and the challenges that lie ahead... A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable... The standardization of workflow behavior and interoperability is late to this game, trying to standardize everything all at once. Perhaps the standards bodies and their members should focus their efforts on finishing the basic, core workflow standard and not be so distracted by the outer layers..." References several workflow specifications, including: '(1)Wf-XML and Workflow Reference Model from the Workflow Management Coalition (WfMC): Wf-XML is an XML-based encoding of workflow interoperability messages. The Workflow Reference Model is a description of the underlying workflow system architecture. Wf-XML has no binding to SOAP and WSDL at this time. (2) WSFL IBM Web Services Flow Language: Specifies two types of Web services composition A) an executable business process known as a flowModel, and B) a business collaboration known as a globalModel. Compatible with SOAP, UDDI, and WSDL. (3) XLANG Microsoft's XLANG: Business modeling language for BizTalk, which is a component of .NET that enables EAI. BizTalk Orchestration is the workflow engine and BizTalk Orchestration Designer is the visual business process modeling tool based on XLANG. (4) BPEL4WS Business Process Execution Language for Web Services is the cooperative merging of WSFL and XLANG for Web services orchestration, workflow, and composition. It has not yet been submitted to an IT standards organization. (5) ebXML BPSS The eBusiness Transition Working Group carries forward the definition of workflow conversation and orchestration in the Business Process Specification Schema (BPSS) layer of ebXML, which defines many protocols and layers for XML-based e-business. (6) WSCI Sun/BEA/Intalio/SAP consortium's Web Services Choreography Interface 'is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services.' (7) WSCL W3C's Web Services Conversation Language: A submission by Hewlett-Packard to the W3C, it allows defining the abstract interfaces of Web services (that is, the business level conversations or public processes supported by a Web service), the XML documents being exchanged, and the sequencing of those documents. (8) PIPs, RosettaNet's Partner Interface Process: defines business processes between trading partners via specialized system-to-system XML-based dialogs. Many PIPs have been defined for various partner scenarios. (9) JDF CIP4's Job Definition Format is an upcoming workflow industry standard for the Graphics Arts industry designed to simplify information exchange among different applications and systems..."

  • [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.

  • [December 07, 2002] "Multi-Party Electronic Business Transactions." By Bob Haugen (Logistical Software LLC, ebXML and UN/CEFACT TMG Business Process Work Group) and Tony Fletcher (Choreology Ltd, OASIS Business Transaction Protocol Committee and UN/CEFACT TMG Business Process and Architecture Work Groups). Version 1.1. 7-December-2002. "We present a business scenario, the Drop-Dead Order, that is best handled as a multi-party electronic business transaction. We present models of such transactions using the UN/CEFACT Modeling Methodology (UMM) and the OASIS Business Transaction Protocol (BTP). We claim that the two models are sufficiently equivalent that the same runtime software could execute either. We recommend that BTP be considered as an underpinning implementation technology for UMM, thus harmonizing two specifications that have been considered incompatible. We suggest that further efforts be made to harmonize the other major proposals for electronic business processes so as to converge from a confusion of incompatibility to one global standard, or at least good interoperability..."

  • [November 20, 2002] "WS-C+T and BTP: Comments and Comparisons." By Peter Furniss and Alastair Green (Choreology Ltd). 20-November-2002. "As Choreology announced previously, we believe there should be a single standardization approach for web-services transactions, combining the best features of BTP and WS-C+T. This message summarises some of the principal differences and similarities between BTP and WS-C+T, under the headings: Terminology: sub-protocols; Taxonomy: atoms and cohesions; BTP, WS-T: variations on a single outcome protocol; Functionality discrepancies; Optimisation; Scope - web-services only or web-service and more; WS-Coordination - why separate it?; WSDL integration; Synchronization; Security; Transfer of control... This message gives some detail on the first three, especially the issue that BTP and WS-T are just variations on one protocol, and summarises the other issues..."

  • [April 10, 2002] "Business Process Standards for Web Services." By David O'Riordan (Bind Systems). From Web Services Architect. (April 10, 2002). 12 pages. ['Discusses ebXML BPSS, XLANG, WSFL, BPML, OMG EDOC.'] "A business process standard that provides comprehensive support for both public and private processes should consider the following features: (1) Collaboration-Based Process Models; (2) Workflow; (3) Transaction Management; (4) Exception Handling; (5) Service Interfaces; (6) Message Security and Reliability; (7) Audit Trail; (8) Agreements; (9) Execution... we examine those specifications that address the orchestration layer of the Web Services stack, the core layer that describes business process semantics. These are ebXML BPSS, XLANG, WSFL, and BPML. Each supports some subset of the aforementioned features, depending largely on the domain they are addressing..." See also the abbreviated version in HTML format. [alt URL]

  • [April 03, 2002] "Transactional Attitudes: Reliable Composition of Autonomous Web Services." By Thomas Mikalsen, Stefan Tai, and Isabelle Rouvellou (IBM T.J. Watson Research Center, New York, USA). Paper prepared for the June 26, 2002 Workshop on Dependable Middleware-based Systems (WDMS 2002), part of the International Conference on Dependable Systems and Networks (DSN 2002), Washington D.C., June 2002. 10 pages (with 11 references). "The Web services platform offers a distributed computing environment where autonomous applications interact using standard Internet technology. In this environment, diverse applications and systems become the components of intra- and inter-enterprise integration. Yet, transactional reliability, an often critical requirement on such integration, is presently missing from the Web services platform. In this paper, we address this shortcoming and propose the WSTx framework as an approach to Web service reliability. WSTx introduces transactional attitudes to explicitly describe the otherwise implicit transactional semantics, capabilities, and requirements of individual applications. We show how explicit transactional attitude descriptions can be used by a middleware system to automate the reliable composition of applications into larger Web transactions, while maintaining autonomy of the individual applications... See also the project website. [cache]

  • [October 01, 2001] "OAGIS Implementation Using the ebXML CPP, CPA and BPSS Specifications v1.0." OAGI White Paper. By Jean-Jacques Dubray (Eigner US, Inc.). 9/27/2001. Version 1.03. 64 pages.
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/bpm.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org