Build Your Business
Apps With BPEL
Examine a collection of commercial and open source tools to support the full lifecycle of BPEL development.
by Avi Borthakur and David Shaffer

December 13, 2004

The goal of software development tools is to increase productivity by simplifying and automating tasks while exposing concepts at a level users can easily understand. Over the years, these tools have evolved from simple code editors, compilers, and debuggers to integrated development environments (IDEs) that provide developers with a single environment to develop, debug, and test their programs. Collaborative development is available through integration with a source-code control system, and traditional tools focused on support for coding have been evolving to support high-level modeling.

The Business Process Execution Language (BPEL) for Web services provides a standard, portable language of business-process automation and development of "composite applications"—business applications—based on a set of multiple interacting services. BPEL builds on a decade of progress in the areas of business process management (BPM), workflow, and integration technologies and is supported on both the .NET and Java platforms.

Although it relies on traditional tool features, BPEL programming has more specific requirements, chiefly because business processes involve not just software systems but also entities such as people and wireless devices. This factor has made it necessary to converge complementary tools from portal, modeling, workflow, and integration worlds into a single toolset for comprehensive support for BPEL development. Also, software-development patterns become more prominent as the languages get specialized; you can now use a metalanguage to express what was earlier expressed in code. Therefore, the metalanguages of the Web services generation, such as BPEL and Extensible Stylesheet Language Transformations (XSLT), are much easier to work with using highly graphical drag-and-drop environments instead of standard code editors. In this article, we cover these and other tools required for effective BPEL development.

BPEL in Practice
To understand and appreciate BPEL development tools, let's consider a real-world problem. In the following sections, we explain how the tools address the problem's specific areas.

An order-management process at a large hardware manufacturer accepts wholesale orders from many sources and responds immediately with an order-tracking number. However, it has a long-running flow in the back end to process and track orders, and it calls clients back when invoices are ready. Specifically, this flow needs to invoke services, such as looking up payment terms in an enterprise resource planning (ERP) financial system, as well as submitting the order to a mainframe system. XML data is exchanged between the systems, and the manufacturer must process several hundred transactions a day at peak loads (see Figure 1).

Modeling Tools
We start the development of our order-management process (see Figure 2) with a business analyst modeling the flow of the process, the end systems, and the interactions with those systems using these high-level modeling tools. (The model, at this point, is at an abstract level.) BPEL is then generated from this model and made available to the developer to fill in implementation details.

Visual modeling tools, which have been around for several years, are used primarily during the software-design phase. These tools, including those that enable business modeling, workflow modeling, simulation, and object-oriented modeling with UML, are staples in the world of analysts, architects, and experienced developers. Typically, coding to fill in the "stubs" follows up this initial design work.

The power of a standard such as BPEL for business process management is that modeling tools directed at business analysts, like those from Popkin, ProActivity, and IDS Scheer, can now generate BPEL that can be edited further with BPEL developer tools and executed on BPEL engines. These tools also have simulation capabilities.

Though this method might seem analogous to object-oriented code being generated from UML models, with BPEL, similar to high-level modeling, the visual modeling paradigm carries on during the implementation phase, as opposed to writing code. BPEL has made it simpler to express logic diagrammatically instead of using code, which means BPEL development tools must provide users with a richer, more intuitive, and highly graphical environment. The developer fills in the BPEL implementation details by dragging and dropping BPEL activities from a palette onto a canvas and draws transitions between activities.

XML Tools
Now we are in the BPEL development stage. Our order-management process responds to order requests with tracking numbers. Suppose you want to copy a customer's name, which is in the original wholesale order request, into this response message. Also, the wholesale order that comes into the process needs to be modified into another format before the legacy back-end system can process it. Both these requirements demand that the tools have the ability to query data from, and transform, the order request.

In a BPEL process, all elements are in XML, including the messages passed into and returned from the BPEL process, those exchanged with external services, and any local variables the flow itself uses. The types for all these messages and variables are defined with XML Schema, usually in the Web Services Description Language (WSDL) file for the flow itself or in the WSDL files for services it invokes. Therefore, developers will spend time manipulating XML, XSD, XPath, and other XML-based standards. This task includes modeling data transformations between representations required for different services, as well as defining data types.

Therefore, a primary tool for BPEL support is an XML editor, a specialized schema-driven tool for editing XML, including XSLT and BPEL. Because BPEL and XSLT are basically programming languages, the editor needs to support features such as syntax highlighting, tag/code insight, and auto-completion. Validation support and graphical displays of structures are also nice features in most tools.

In many ways, the kinds of tools developers want to support BPEL might be similar to the tool requirements for HTML. Just as Macromedia Dreamweaver combines maximum power with productivity by allowing HTML designers to switch back and forth between an HTML source view and a WYSIWYG-style representation of an HTML page, BPEL designers want dual-editing capabilities for both a BPEL source (XML) view and a visual process representation (see Figure 3).

In addition, XPath plays a large part in manipulating XML data in BPEL: XPath queries, expressions, and functions are used for lookup and manipulation of data in BPEL. Therefore, XML tools need specialized support for XPath, such as path-tree navigation or displaying function prototypes, and assisting in entering arguments. XPath can be tool friendly (see Figure 4), but it would be quite painful for developers to write by hand.

XSLT and XQuery editors are also looking like basic tools required for BPEL development. As BPEL is used in integration implementations, one reality it can't escape is that various systems represent data in different ways. Data must be transformed from one structure to another, and XSLT and XQuery are the primary solutions. Such editors have become more than simple XML editors: They provide drag-and-drop mapping capability, auto-mapping, mapping-analysis and documentation generation, and debugging and testing features.

Web Service Tools
As we develop the order-management solution, we realize the ERP financial system does not support Web services natively, but rather exposes application programming interfaces (APIs) in a proprietary format. In this case, we need the ability to create Web service wrappers around the APIs so we can invoke them from our BPEL process.

Sophisticated tools in the market such as iWay's SOAPSwitch offer wizard-based approaches to creating and deploying Web services from existing back-end enterprise applications, thereby providing an easy way to reuse existing assets by making them Web-service enabled. Comprehensive tools also provide similar support for exposing Enterprise JavaBeans, Java objects, APIs such as JCA, JMS, and JDBC, and transports like FTP, SMTP, and JMS as Web services. An integrated development environment can be invaluable if these services need to be modified further. The output of these tools is a WSDL document used to describe and locate those Web services.

Although this approach might be sufficient in the case of an enterprise application in which the service definition is fixed, if a user needs to modify the service definition, a simple text or XML editor is not the simplest interface. A more sophisticated editor that visualizes the WSDL more intuitively provides support for validation, documentation generation, and editing of the WSDL's parts, and publishes to registries is needed.

After you set up the Web services, you must be able to look them up and modify your BPEL process to invoke them. In addition, your order-management process should be available as a Web service for clients to send order requests to.

Universal Description, Discovery, and Integration (UDDI), a Web-based registry of Web services definitions, is one of the key technologies associated with Web services. UDDI provides simple APIs for Web service registration and discovery; BPEL development tools provide access to UDDI registries so developers can easily search and select Web services of interest, and Web service developers publish their services to public or private UDDI registries directly from their BPEL development tools (see Figure 5).

A Web Services Inspection Language (WSIL) document—similar and complementary to UDDI—allows service clients to discover Web service definitions from a specific service provider. The key differences are that WSIL is not as centralized as UDDI and that WSIL documents can link to others of their kind, thereby creating a hierarchy. Furthermore, WSIL can provide references to UDDI entries for services, thereby interoperating with it.

WSIL benefits the development cycle by providing a simple, local, and reliable registry of Web services. Developers should be able to easily add and manage services in the registry by looking up services from a UDDI registry, or development tools can automatically register services as they are created. For example, a developer models a JCA interaction to a back-end ERP system as a Web service, and the service is automatically registered in a local WSIL. From then on, the developer can model the invocation of this service from the BPEL process by simply searching and selecting it through a single interface, the WSIL "browser." The same WSIL can then be used to invoke the service.

Testing Tools
Our order-management process is now coded, and we need to build, deploy, and test it; we'll accomplish the latter step by simulating a client request. We start by testing the various components (e.g., the ERP Web service we created earlier). We then want to monitor the SOAP requests and responses as they go to and from the BPEL process instance and the test client. Because of the high load requirements, we also want to stress test our implementation. In the end, we want to automate running these tests as part of a regression-test suite.

BPEL is fundamentally a programming language, so there are the same kinds of testing needs seen for other languages: You need to test all possible paths through a process, and you must avoid regression bugs as new functionality is added to a process.

Unit testing is a key part of developing high-quality code. JUnit, an open-source testing framework that allows development of tests in Java, consists of a GUI that lets developers run tests and view their results. JUnit tests can access objects running inside a J2EE container. When code fails, JUnit provides a clickable stack trace to find the failed code. In addition, some IDEs have debuggers that integrate with JUnit, providing the added capability to run the tests again in debug mode with breakpoints set.

Web service development and testing is currently simplified by a host of tools available free to developers: SOAPClient (see Resources), for example, hosts a list of indispensable tools. Several tools have a Web service test client that allows users to simply point the tool to a WSDL; it then automatically builds a sample payload or HTML form based on the WSDL. Users can then submit the form and view any response.

TCP/SOAP monitors allow viewing of HTTP request and response packets. The sophisticated monitors examine TCP packet content in detail and allow developers to debug network traffic without making programmatic changes. For example, developers can edit and resend the request package of a TCP request/response pair to the same host.

For load and stress testing, there is Apache JMeter (see Figure 6), an extensible open source tool available as a plug-in. Like JUnit, JMeter consists of a GUI that allows developers to run tests and view their results. (Stress testing is key for business processes because they are often deployed into heterogeneous environments where each of the components might have different load capabilities.)

No testing discussion is complete without a reference to Apache Ant, the open source, Java-based cross-platform build and automation tool, which has evolved significantly. Today, Ant is used for compilation, unit testing, deployment, and deployment testing with a single command.

Equivalent tools in the non-Java world that possess similar features exist. We've highlighted the ones described here in particular because of their cross-platform nature, interoperability, and ease of automation, as well as their ability to test different return values of services (for example, if service returns data, service returns fault, or service is unavailable). This kind of testing is much easier if tools support it; otherwise, developers spend a lot of time building service simulations instead of "real" services and flows. Commercially available tools such as Parasoft's SOAPTest provide comprehensive testing of Web services.

Debugger
During the test of the order-management process, we encounter a problem with the implementation, so we go back to our development tools to debug and fix it.

Most debuggers allow developers to set breakpoints, step through code, examine and modify the values of variables on the fly, and examine the execution stack trace; advanced features include showing the status of threads and monitors. One requirement of BPEL is the ability to conduct remote debugging of code deployed on a remote machine. The debugger should be multithreaded and should be able to simultaneously attach to multiple remote processes so the developer can seamlessly debug distributed services.

Another potential difficulty in debugging BPEL processes is the long-running and parallel nature of these processes. For example, BPEL has built-in support for the <flow> activity, which allows several branches to be executed in parallel.

In addition, support for asynchronous services means a BPEL process instance could wait an arbitrary amount of time for a service to respond at various points in the process. This function introduces a requirement for a debugger that can represent a process state blocked in several places at once, waiting for asynchronous callbacks.

We also need the ability to debug XSLT maps, Web services, and other touchpoints in the same context as the BPEL process.

The Integrated, Yet Open Approach
In this article, we highlighted the key stages in the lifecycle of BPEL development and their associated tools. Although the ubiquity of standards means that a best-of-breed tools approach is possible, the cumulative cost and the affect of multivendor tools on developer productivity are negative factors worth considering. You should consider taking an integrated yet open and standards-based approach with a single development environment for all BPEL, XML, and Web services development, with the capability to plug-in tools for niche requirements.

In this way, the tool can maintain a consistent and seamless experience as the developer moves through the various BPEL development stages while at the same time being able to provide easy extensibility and interoperability. And, by staying true to the standards, there is no vendor lock-in through proprietary formats. The net result is that companies can manage their intellectual properties—BPEL processes, XSLT maps, and so on—in a vendor-neutral format, something never before possible.

About the Authors
Avi Borthakur is director of server technology at Oracle, where he is responsible for the development of tools and user interfaces for the company's standard-based integration products. He has an MS in computer science from Stanford University.

David Shaffer has been helping customers use the Oracle BPEL Process Manager since 2001, managing implementation projects, providing technical training, and ensuring successful implementations. Prior to joining Oracle, he was a principal consultant at Collaxa, a managing director at Eleven Acceleration, and manager of professional services group at Apple Computer.