Workflow management with BPEL

Trial and Error

After creating the process, you can test it in the simulator. To do so, run the process by selecting Run | Simulate Process on the internal engine. This command manually sets parameter data via the Process Variables tab to simulate the values passed in by another web service in production use.

If the process works as designed, the BPEL user then creates a deployment archive (see Figure 4). This BPR file is a JAR archive that contains all the files required for the process to run on the open source engine. The file is created by selecting File | Export | Orchestration | Business Process Archive File and choosing File as the deployment type. This step writes the BPR file to disk initially. Optionally, you can pass the deployment directly to a running engine via a web service.

If you prefer to work with Ant and without the designer later on, you can create a BPRD file. A deployment descriptor describes how a process definition finds its way into a workflow engine and configures what were previously abstract parameters. These details are compiled in travelbooking.pdd.

The developer now needs to stop the designer and start Tomcat with the ActiveBPEL engine in it. To introduce the new process to the engine, you just need to copy the BPR archive to the bpr deployment directory below the Tomcat installation. After a couple of seconds, the servlet container identifies the archive. You can monitor this process in http://localhost:8080/BpelAdmin/deployment_log_detail.jsp, the administration interface deployment log.

The log lists the installed processes below Deployed Processes. If a user launches a travelbooking type process via a SOAP request, the admin front end shows its state and variable content in .../BpelAdmin/active_processes.jsp. The process visualization in the web front end is similar to the display in the designer.

Good Connections

Any SOAP client can issue a SOAP request; SoapUI is a good choice for quick tests [7]. The WSDL definition for travelbooking() can thus be loaded directly with the running engine: .../activebpel/services/TravelbookingPartnerLinkService?-wsdl. If you import the definitions in this way, and set the real HTTP service address for the engine, you can jump right in and integrate the process with your own applications.

Because of the many abstraction layers, workflow management with BPEL is non-trivial. Multiple approaches to process modeling on a business level, different notations, permitted variants in implementation of the standard, the many layers of an SOA, and the variety of software products make it hard for architects to keep track of the solution. Specialist literature on the subject would fill a small library; The Packt Press book Business Process Execution Language for Web Services provides a pragmatic approach [8]. None of the examples require the BPEL Designer because the authors work directly in XML.

Developers Still Have Work To Do

BPEL's answer to the many competing methods of process modeling is to provide a universal approach. BPEL is so universal that it can handle the lion's share of business workflows. This outlook keeps developers flexible and means they can support several modeling methods. But you should not underestimate the complexity: A WFMS based on BPEL requires sound working knowledge of SOA technology by the developer and an unequivocal "yes" to process technology from the business divisions.

Despite all this standardization, BPEL has a couple of pitfalls. For example, the standard is unclear in some areas, or it leaves loopholes that many BPEL engine vendors exploit for proprietary extensions. Although it requires XPath as the language for variable and value manipulation, for instance, it allows for extensions such as XQuery or JavaScript. Although this approach might facilitate modeling, it means that the process definitions are not intelligible to every workflow engine.

The description language is not suitable as a tool for the marketing department or management team to define business workflows on their own. On the contrary: A process designer has to understand the technical underpinnings of the underlying SOA. SOAP skills and a sound understanding of the WSDL standard are useful.

The vision of letting the boss do all the work turns out to be an illusion. But end-user friendliness was never the purpose of this technology: BPEL is a technical integration platform for any kind of business process definition. If you have the perseverance to create a structure with BPEL, you can relax and watch your business workflows perform later as your business processes evolve.

Infos

  1. OASIS, "Web Services Business Process Execution Language Version 2.0." http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
  2. Apache Tomcat: http://tomcat.apache.org/
  3. ActiveBPEL, Community Edition Engine: http://www.activevos.com/community-open-source.php
  4. Documentation and tutorials for ActiveBPEL: http://www.activevos.com/community-educationcenter.php
  5. ActiveBPEL Designer: http://www.active-endpoints.com/download-trial.php
  6. Booking a business trip, sample process: http://www.linux-magazine.com/Resources/Article-Code
  7. Web service Browser SoapUI: http://www.soapui.org
  8. Juric, Matjaz B., Benny Mathew, and Poomachandra Sarang. Business Process Execution Language for Web Services BPEL and BPEL4WS, 2nd ed. Packt, 2006

The Author

Michael Kleinhenz has a degree in technology informatics and is the head of software development with Tarent GmbH in Bonn, Germany. He is also a founding member and deputy chair of LinuxTag.

Read full article as PDF:

Related content

comments powered by Disqus

Direct Download

Read full article as PDF:

News