Wednesday April 10 2002

Business Process Standards for Web Services

The candidates

David O'Riordan

The convergence of two major trends is creating a rapidly growing demand for a new breed of software that facilitates automation of business processes both between enterprises and within the enterprise.

The first of these trends is Web Services technology: a collection of XML-based standards that provide a means for passing information between applications using XML documents. The ability of Web Services to reach beyond the firewall, the loose coupling between applications encouraged by Web Service interfaces, and the wide support for core Web Service standards by major enterprise software vendors are the key reasons why Web Services technology promises to make integration of applications both within the enterprise and between different enterprises significantly easier and cheaper than before.

The second of these trends is a business driver. In order to increase an organization's agility in responding to customer, market, and strategic requirements, the information flow between the IT systems that carry out these business operations must be streamlined. This includes not only the organization's own IT systems but also those of its partners. It is the task of electronic business integration to automate this information flow as much as possible in order to streamline operations.

A whole new set of tools has arisen to facilitate the integration and automation of business processes. These include graphical process modeling tools, middleware technologies such as CORBA and JMS, integration brokers, Business Process Management Systems (BPMS), and B2B servers. Unfortunately, until recently the investment required by organizations to integrate the IT systems both inside their organization and across the firewall has been very high, due to many different proprietary interfaces.

Web Services technology promises to change this by replacing proprietary interfaces and data formats with low-cost, ubiquitously supported standards for interfaces and data that work as well across the firewall as within it. The first generation of Web Services technology, though, has largely focused on the messaging foundation supported by SOAP and WSDL. While this foundation is sufficient for some internal application integration needs, it is not sufficient to support the complete automation of critical business processes. This requires the ability to specify workflow, security requirements, transaction management, and other critical information related to the business process context. Such information is generally specified in a business process model.

The need for business process standards

We require standards for business process models that are built on Web Service architectures. These would enable processes to be modeled, deployed, executed, and managed by software from various vendors. Without such standards, a number of undesirable consequences arise. These include:

• Vendors are likely to offer support for such features as proprietary extensions to Web Service standards, leading to vendor lock-in.
• Collaborating enterprises may choose incompatible means of defining the shared process models, leading to inefficiencies and error-prone operations.
• Reuse of proven processes and patterns across products from different vendors is difficult if these can't be specified in a standard way.
• The emergence of best-of-breed tools for modeling and for execution of processes will be hampered.

Business Process Features

A business process standard that provides comprehensive support for both public and private processes should consider the following features:

• Collaboration-Based Process Models
  Experience in both EAI and B2B process modeling has led to the increasing adoption of collaboration-based process models, usually based on UML. In collaboration-based process models, processes are described as a set of collaborations between various participants, including organizations, applications, employees, and other business processes. Usually participants can be abstracted in model descriptions using roles. The ability to recursively decompose process models is generally required.
• Workflow
  The workflow defines how the participants in a process work together to execute a process from start to finish, and is also called choreography or orchestration. Most workflow standards support sub-processes, which allow activities within a workflow to be implemented as another workflow. Workflow descriptions can be generated from collaboration models, or specified independently. Recursively decomposed process models can be mapped to workflow descriptions using sub-processes.
• Transaction Management
  Transactions are crucial building blocks of any business process and a comprehensive business process standard must provide a means for specifying how transactions are managed. Long-running transactions that may take hours or weeks to complete must be supported. If an enclosing transaction fails after an enclosed transaction is completed, some compensating actions may be needed. For example if a hotel reservation is cancelled after a payment has been authorized, a compensating action may be required to cancel the payment. Time constraints for receiving responses or acknowledgements may also be required.
• Exception Handling
  If an exception is raised during the course of a business process, then it is important that the model allow appropriate recovery actions to be taken.
• Service Interfaces
  Web Services provide a basis for passing messages between participants in collaboration-based processes. Some recent proposed business process standards such as WSFL and XLANG use WSDL interfaces to describe the loosely coupled services exposed by participants to each other.
• Message Security and Reliability
  For mission-critical processes, reliable and secure message delivery is required. Additionally, B2B messages may need to be digitally signed and authenticated. These quality-of-service semantics may vary for different transactions.
• Audit Trail
  It is generally very important for legal purposes in B2B processes that an audit trail of certain business transactions is kept. This means that a trading partner is unable to claim that a transaction was not accepted when in fact it was; that is, it ensures non-repudiation of the transaction by the partner. Digitally signed receipt acknowledgements of messages may be demanded.
• Agreements
  The notion of agreements is specifically for B2B processes. An agreement represents a contract between two or more partners to carry out specific functions (identified by roles) in a public business process.
• Execution
  Public processes describe only how information should flow between organizations. In order to be able to fully automate the execution of the business process within an organization, the complete information flow within that organization as well as across its firewalls must be specified. This requires the process models to fully describe the private as well as the public activities of the organization.
  A powerful approach supported by some standards is Web Service aggregation, whereby one Web Service is used in the implementation of another. For example an organizational workflow that handles purchase orders might receive the orders from customers via one Web Service and then call an internal ERP application via another Web Service to help process the order. Such an approach should become significantly less expensive than traditional EAI methods.

The candidates

Now let's 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.

ebXML BPSS

ebXML BPSS (Business Process Specification Schema) is part of the comprehensive ebXML B2B suite of specifications, which also includes core specifications for reliable and secure messaging based on SOAP, collaboration agreements and profiles, a registry/repository, and core components.

BPSS is a relatively simple but effective schema that describes public processes only. In a BPSS model different roles (seller, buyer, etc.) collaborate to carry out a set of transactions. The orchestration of the transactions is defined using a control flow based on UML activity graph semantics. There is no explicit support for describing how data flows between transactions.

The transaction part of the model is based on a proven, robust model for long-lived e-commerce business transactions used by previous B2B standards such as RosettaNet. There is explicit support for specifying quality-of-service semantics for transactions such as authentication, acknowledgements, non-repudiation, and timeouts. For more details, see http://www.ebxml.org/specs/ebBPSS.pdf.

XLANG

XLANG is Microsoft's proposal in this space, and like BPSS is currently focused entirely on public processes.

XLANG uses WSDL to describe the service interfaces of each participant. The behavior is specified with a control flow that choreographs the WSDL operations. There is no means for specifying data flow between operations. Long-running transactions encompassing multiple operations are supported and can be nested. Compensating operations for transactions can be specified. Exceptions can be caught and recovery operations specified. Acknowledgements and timeouts can be flexibly incorporated. Some support for agreements is provided in XLANG by contracts, which defines how to stitch together Web Services of collaborating partners.

XLANG does not define quality-of-service characteristics of Web Services such as non-repudiation and authentication, or guaranteed messaging requirements. For more details, see http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm.

WSFL

WSFL (Web Services Flow Language) is IBM's proposal in this area. It covers both public and private processes. WSFL is primarily focused on describing Web Service compositions, and like XLANG uses WSDL to describe the service interfaces.

A flow model describes the workflow for a process. Both control flow and data flow can be defined using a state-transition model. Transactions and exception handling are not explicitly supported, but some of the semantics can be implemented using conditional transitions. Activities in a workflow can be exported as Web Service operations, and activities can also be implemented by delegation to a Web Service. In this way WSFL supports Web Service aggregation.

A global model defines how the various Web Services are linked together in the process. It is similar therefore to the business process contracts of XLANG.

Quality-of-service characteristics are delegated to a separate specification called WSEL (Web Services Endpoint Language). For more details, see http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

BMPL

BPML (Business Process Management Language) is a specification from the BPMI.org (Business Process Management Initiative) organization. BPML aims to provide a comprehensive means of specifying the processes of an enterprise. It is positioned as complementary to public process standards such as ebXML BPSS - the BPMI FAQ (from the BPMI.org Web site, http://www.bpmi.org/faq.esp) states:

BPMI.org and ebXML are addressing complementary aspects of e-Business process management. While ebXML provides a standard way to describe the Public Interface of e-Business processes, BPMI.org provides a standard way to describe their Private Implementation.

BPML describes comprehensive control flow and data flow constructs. It supports both short- and long-running transactions with compensating activities. It also supports exception handling and timeouts. It does not provide a means to specify characteristics that are important to B2B processes, such as authentication and non-repudiation. For more details, see http://www.bpmi.org/.

Conclusion

It is clear that businesses are increasing moving towards comprehensive automation and integration of their private and public processes, and that Web Services is becoming increasingly popular for use as the integration infrastructure. This scenario drives the demand for Web Services based business process standards. Over the next couple of years we can expect to see continuing activity to address this demand.

This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com

David O'Riordan is co-founder and Chief Architect at Bind Systems (http://www.bindsys.com/) who provide business process software products based on Web Services standards. He has 15 years experience of designing enterprise software systems at companies such as Siemens and IONA Technologies. Before founding Bind Systems in 2000, he was the product architect of the Java CORBA product line at IONA Technologies