Enterprise Integration With Web Services and BPEL
Businesses looking to consolidate and modernize their applications have an alternative to EAI.
by Adam Kolawa, Ph.D.

March 14, 2005

Many companies spend enormous sums of money and collect huge amounts of data maintaining their legacy systems. Therefore, it is crucial that companies find a quick and efficient way to preserve and reuse these legacy systems rather than throwing them by the wayside. Traditionally, companies wanting to provide communication and integration across various disparate applications and operating systems have turned to enterprise application integration (EAI).

However, due to the high cost and proprietary nature of EAI solutions, companies are looking for easier and more flexible ways to consolidate and modernize their applications. In order to offer services and share data with business partners, customers, and other information systems, businesses must update their legacy systems with current technologies. A solution lies in Web services and Business Process Execution Language (BPEL). These technologies offer open, standards-based integration that provides interoperability by combining messaging technology with XML and various Web services standards. Once Web service interfaces are developed, you can use BPEL to define and orchestrate business transactions and ultimately bring the old world of legacy systems to the new world of modern information systems (see "Build Your Applications With BPEL").

This article addresses the issues that arise when integrating legacy systems with Web services, and how BPEL will play a vital role in companies' integration projects.

Integration Issues With Legacy Systems
Many of today's large businesses have existing legacy systems written in a variety of disparate languages, such as COBOL and C++. In addition, different legacy systems might be in place even where there are common interests, lending to a chaotic, decentralized IT infrastructure that makes it difficult for future integration.

For example, a typical enterprise is often composed of numerous distributed disparate departments, each department having its own processes intended to fulfill specific responsibilities. Consider a large hotel chain that offers travel services consisting of multiple information systems between businesses, departments, and applications. Each hotel has its own unique ticketing system that allows customers to perform certain actions such as viewing hotel descriptions and rates, and making and canceling reservations. However, because of each unique system, the company has difficulty maintaining and exchanging relevant data across the enterprise such as information that must be connected to an accounting system.

In the past, companies might have turned to proprietary solutions to remedy communication problems and to integrate across systems. As a result, after years of proprietary integration efforts, various integration tools and solutions exist in the enterprise today. Although it is possible to integrate isolated systems using proprietary communication (i.e., CORBA, EDI, or other message-passing technologies), companies become locked in to vendors. Expansion and growth, therefore, become increasingly difficult due to the additional amount of resources needed to maintain proprietary standards and protocols.

Creating a Web Services Interface
Businesses need scalable, reliable applications. Because so much data is involved and a large amount of resources is needed, the hotel chain in our example simply cannot start from scratch and build anew. It must find a way to extend its legacy systems and build upon them. In today's fast-moving, forward-thinking world, companies must modernize and consolidate their existing information systems. They must also ensure that, once integrated, these systems are able to provide for long-term future growth. To meet these demands, organizations must establish a flexible, standards-based architecture rather than confine themselves to proprietary fixes.

This makes the implementation of Web services an ideal choice for enterprises where multiple vendor solutions are deployed and where existing systems need to be utilized with newer applications. Web services are gaining industry-wide acceptance and usage. They are moving from proof-of-concept deployments to actual usage in mission-critical enterprise applications.

Due to the proliferation of Web service standards, such as XML, SOAP, Web Services Description Language (WSDL), and UDDI, a standardized integration interface is available that promotes and encourages interoperability and system reuse. Therefore, legacy systems can be consolidated and modernized along with newer technologies—making rapid integration possible without vendor lock-in. By building a Web services interface, you can begin to expose and build upon your legacy systems, rather than replacing them and starting from scratch. Such an architecture, therefore, provides the basis for future growth and expansion in that new applications can be easily added or plugged in due to a flexible, standards-based interface.

Orchestrate Business Processes With BPEL
For enterprises to maximize the benefits of Web services, they need a way to use these services within automated business processes that mimic their actual business processes. The order in which business transactions will occur must be orchestrated to streamline the enterprise's day-to-day operations. BPEL, originally called BPEL4WS (Business Process Execution Language for Web Services), was specifically designed to define and automate these types of Web service–enabled business processes.

The Web service–oriented approach to business process automation that BPEL supports provides a solution to two challenges facing the enterprise today:

• How to automate enterprises in a way that not only minimizes cost but also increases enterprise agility in a fast-moving market environment.
• How to aggregate the growing number of Web services and orchestrate them in a way that automates real business processes.

BPEL also provides a single language that can express processes intended for communicating interaction patterns among multiple parties (business protocols) as well as processes primarily intended to convey internal logic (executable processes); it can also ease the transition from one to the other. BPEL can express both types of processes within a common language, with a small number of extensions to distinguish between the business protocols (called abstract processes) and the executable processes. The distinction between these two types of processes need not be a crisp one. In fact, one of BPEL's key features is that its ability to represent both types of processes makes it easy for process authors to convert one type of process to the other (for example, to expose part of an internal business process to a business partner as an abstract process while excluding any sensitive information).

Another concern of BPEL is how processes are controlled. The two leading control regimes in process modeling are hierarchical control, as found in structured programming languages, and graph-like control, where the execution of activities is primarily controlled through links that indicate explicit dependencies between activities. BPEL supports both types of control regimes and allows them to be used interchangeably within processes. This support for both regimes gives authors a higher degree of flexibility to express processes in whatever way is most natural to the task.

Finally, BPEL addresses the challenges associated with long-running business processes. Most business processes are long-running and thus require a long-running transaction model. BPEL employs a model in which activities can have implicit and explicit compensations, so faults can readily be handled without making unrealistic assumptions about being able to lock transactions for indefinite periods of time. Built-in support for compensation handling and well-defined atomic activities are key to this model.

Build Bridges With BPEL
BPEL includes built-in support for producing and consuming Web services. In fact, every executable BPEL process is exposed to the world as a Web service. Although Web service technologies such as WSDL and XML are designed to be platform-neutral, an integration language that includes some key Web service concepts can save companies a tremendous amount of time and resources. Also, BPEL depends heavily on WSDL and adopts the key abstractions provided by WSDL as its own key abstractions. This makes BPEL a natural language for manipulating Web services. Therefore, the more Web services available in an enterprise, the more valuable BPEL becomes for application integration.

With Web service interfaces in place, BPEL can be used as a bridge to extend legacy systems while also providing a way for new technologies to be implemented and integrated. Multiple applications, new and old, will then be able to leverage existing business processes via this BPEL bridge. By using BPEL to orchestrate business processes, businesses are able to replace or upgrade older parts of a business process without affecting the newer systems that are functioning well.

Therefore, a completely new information loop will eventually be formed to which parts of the legacy system will slowly migrate. Over time, the entire legacy system will migrate into the new loop and will eventually disappear and be consolidated into the modernized BPEL loop. For example, the company in our hotel scenario can utilize BPEL to change processes within its reservation systems without changing its accounting system, even though both might interact together in other business processes. BPEL can scale and modernize the hotel's infrastructure by transforming older business processes.

Flexible, standards-based architectures are emerging as the design model of choice in integrating extended enterprises. Web services and BPEL play an important role by providing powerful means by which business logic can be articulated and executed at an abstraction level designed to provide the services needed for integration tasks.

We have seen a number of properties common to many business process applications, including long-running processes; a need for reliable, asynchronous communication; and heavy usage of Web service technologies. Although any of these properties can be achieved by writing code in a general-purpose programming language, the primary benefit of creating Web service interfaces and using BPEL is that they provide abstractions and infrastructure particularly suited to the often difficult task of legacy systems integration.

About the Author
Adam Kolawa, Ph.D., is the chairman and CEO of Parasoft, which he cofounded with a group of fellow Caltech graduate students in 1987. In 2001, he was awarded the Los Angeles Ernst & Young Entrepreneur of the Year Award in the software category.