Business process standards, Part 1: An introduction

This article discusses three important standards for business processes: WS-BPEL, XPDL and BPMN. It reviews the background and purpose of these standards, and describes how they interrelate.

Share:

Marc Fasbinder, Consulting I/T Specialist, WebSphere Software Technical Sales, IBM

Photo of Marc FasbinderMarc Fasbinder is an I/T Specialist at IBM with the WebSphere Technical Sales team in Southfield, Michigan.



17 October 2007

Business processes overview

A business process is usually defined as a series of activities and logic that form a repeatable pattern. Some processes are very dynamic or ad hoc, never running the same way twice. Others are very well-defined and run exactly the same way every time. Typically, companies will want to apply business process automation where it adds the most value: to a highly repeatable process with high business value. Processes such as insurance claims handling, loan processing or provisioning tend to fall into this category. Automating business processes of this type saves companies time and money. Running these processes the same way each time ensures quality, as well as regulatory compliance through audit log tracking.

For many years, companies attempted to automate business processes using custom code. This led to inflexible processes that were difficult to maintain over time. Each time the business needed a change to the process, code needed to be rewritten. It became clear over time that a middleware solution was needed to attain the full benefits of business process automation.


The importance of standards

When the first wave of workflow-based middleware products arrived on the market, there were no well-defined standards. This meant that whichever tool set a company chose, they were locked in with one single vendor. Interoperability at run-time was only obtained through custom coding, while there was typically no interoperability at all with the tool sets between vendors.

With these first middleware products, a clear pattern of tools and structures emerged:

  • Graphic modeling tools: A process is difficult to define through words alone. A representation such as a flowchart is far better at describing the overall structure of the business process. A visual representation, along with the metadata needed to describe the activities in the process along with the business rules for the decisions in the process, is called a process model.
  • Run-time engines: A model is a representation of a physical process. It can be used by the run-time engine as the template for starting instances of a business process. The run-time engine maintains the state of the business process, typically by using a database. The run-time engine manages the "in flight" processes and choreographs the activities, some of which might be automatic. Most run-time engines had some type of connectors or adapters available to leverage existing business systems. Other activities might involve people. The run-time engines had different ways to assign work to users, manage work lists (sometimes referred to as work queues, or just queues), and make people a part of the business process.

The problems

Several problems emerged from the first wave of workflow products

  • Different ways to represent the business process: Different vendors used different graphic representations of the activities in a process, making it difficult for companies with more than one process engine.
  • Different file formats: Even if two modeling tools used the same graphic representation, each tool used its own proprietary file format, making it impossible to share models across different tool sets.
  • Different execution languages: The run-time representation of a business process was different for every process engine. This meant that one vendor's tool could not produce a run-time artifact for another vendor's run-time engine. In addition, different execution languages made interoperability difficult, unless custom code was used to bridge the two environments.

Solving the problems through standards

Clearly, standards were needed in order to solve these problems. Some early attempts were made at defining standards, such as the pioneering work done by the Workflow Management Coalition (WfMC), but a standard is only useful if it has broad acceptance in the industry. Today, there are three standards that directly address these issues.

In addition, other standards such as Web services have emerged, which make interoperation possible among different vendors.


WS-BPEL

OASIS, the Organization for the Advancement of Structured Information Standards, is a not-for-profit consortium that drives the development, convergence and adoption of open standards. OASIS has over 5000 members, and has developed many familiar standards such as XML.

One standard from OASIS is Web Services Business Process Execution Language (WS-BPEL). The WS-BPEL committee has broad industry support, including IBM®, Microsoft™, BEA®, Adobe®, SAP®, Oracle®, along with others.

Simply put, WS-BPEL is an execution language to describe the behavior of business processes in a standards-based environment. Processes can use Web services to invoke business functions, and the process itself can be exposed as a Web service.

A web service can be described by Web Services Definition Language (WSDL). Web services are stateless and uncorrelated. For example, if a conversation is needed between two systems, a simple Web service has no way to maintain state. And if multiple conversations are occurring at the same time, there is no way to correlate which messages belong to which conversation.

WS-BPEL solves these problems by defining the end-to-end business process. The process allows for stateful long running processes between different business systems. The standard defines a format for an XML document. The language describes the syntax for the elements of a process, such as the partner links, service invocations, data variables, correlation sets, and so forth.

Having a standard execution language means that a process defined by one vendor's tool set can be consumed by the run-time of another vendor. The WS-BPEL standard allows vendors to extend the language with custom activities, assign operations, constructs used in WSDL definitions, such as partner link types. This means that the WS-BPEL from one vendor might need to be modifed before it can be run on another vendor's run-time engine. However, a small amount of rework is better than needing to recreate an entire process from scratch.

Many vendors on the market have run-time engines based on WS-BPEL, which was ratified as a standard in April, 2007. Extensions are being considered in some functional areas.

BPEL4People

The WS-BPEL 2.0 standard does not address the business problem of how people can act as part of a business process. However, a proposed extension to WS-BPEL called BPEL4People defines an approach for extending WS-BPEL to support scenarios where people are required as part of the business process. Another aspect of BPEL4People is WS-HumanTask, which defines how a task for a person can be invoked as a Web service.

BPELJ

In the WS-BPEL 2.0 standard, all of the steps in the business process are invocations of Web services. There are often times when a small program is needed as part of a process. Rather than having to create the program and expose it as a Web service, the proposed BPELJ extension to WS-BPEL enables a process to run Java™ code inline with the process. This enables both BPEL and Java to do what they do best, in the same process.

WS-Business Activity

Another related standard is WS-Business Activity 1.1. If a long-running business process invokes another process as a step, life cycle actions such as canceling the first process need to be addressed by the subprocess. For example, if the first process is cancelled, the subprocess might need to compensate, or undo any activities it has previously performed. The specification provides business activity coordination types that can be used in the WS-Coordination framework, along with two business activity agreement coordination protocols. Developers can use these coordination types and procotols when consistent agreement on the outcome of long-running distributed processes is required.


BPMN

The Object Management Group (OMG™) is an international, open membership, not-for-profit computer industry consortium. OMG task forces develop enterprise integration standards for a wide range of technologies. One specification from OMG is Business Process Modeling Notation (BPMN), authored by IBM.

A process can be visualized through a diagram. BPMN's goal is to provide a standard notation for the process diagram. Using such a notation ensures consistency, so that no matter who created the diagram, the same icons are used to represent the same objects. For example, a decision is always a diamond (called a gateway). This makes it easier to understand the diagram, no matter whether the user is a non-technical business analyst, an I/T programmer, or a system architect.

Figure 1. Example BPMN process
Figure 1. Example BPMN process

A second goal of BPMN is to define how the elements of a BPMN diagram should map to WS-BPEL. A whole appendix in the specification is devoted to the mappings from BPMN elements to WS-BPEL. Not every BPMN element has an equivalent in WS-BPEL, nor is every WS-BPEL construct part of the BPMN notation. After mapping, the WS-BPEL created still requires work before it can be run.


XPDL

Founded in 1993, the Workflow Management Coalition (WfMC) is a global organization of adopters, developers, consultants, analysts, as well as university and research groups engaged in workflow and BPM. The WfMC creates and contributes to process-related standards, educates the market on related issues, and is the only standards organization that concentrates purely on process.

One standard from the WfMC is XML Process Definition Language (XPDL). The working group for XPDL included Global 360, FileNet (subsequently acquired by IBM), Staffware, Prozone, Fujitsu and others.

The purpose of XPDL is to have an XML format for the storage of BPMN diagrams. If different vendors use XPDL as their file format, they can easily exchange process models. For example, Vendor A could be used for initial process modeling, Vendor B for process analysis, and Vendor C for process execution. XPDL is considered to be complimentary to WS-BPEL, rather than a competing standard. Whereas WS-BPEL is an execution language, XPDL is a file format to promote the interoperability of tools. Some process engines run XPDL models, using extensions to add the details necessary for a run-time environment.

XPDL includes the vector coordinates for the objects in a process. It captures all of the attributes of each BPMN object and metadata, storing them in a standards-based format. As with WS-BPEL, XPDL allows vendors to add in their own proprietary extensions. Extensibility means that vendors using XPDL are not limited, and can still have value-add functionality beyond what is represented in the standard itself.


Relationship between the standards

A process development cycle might work as follows:

  • A business analyst creates a process model. He or she uses BPMN as the basis of the visual aspects of the process, ensuring consistency in notation. The file for the model is stored in XPDL format.
  • A technical resource from the I/T department takes the XPDL file, and imports it into his or her modeling tool, even if it is from another vendor. He or she can see the same visual representation in BPMN as the business analyst. The I/T resource exports the model, transforming it to WS-BPEL, then adding in additional technical attributes for execution.
  • The WS-BPEL is imported on the run-time engine.

In other words, BPMN is what it looks like, XPDL is how it is stored, and WS-BPEL is how it is run.


Conclusion

In this article you learned why standards for business processes are important, and learned about three of the most important of these standards. In Part 2, you'll learn how these standards are applied in IBM products and see some practical examples of how they can work together to form a solution.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services, Business process management
ArticleID=260873
ArticleTitle=Business process standards, Part 1: An introduction
publish-date=10172007