Working with BPEL and Enterprise Service Bus

PLEASE READ THE TIPS SECTION FOR TIME SAVING POINTERS!

In this assignment we will learn about the SOA architectural style of enterprise service bus (ESB). An ESB provides endpoints to which heterogeneous services can be plugged readily. The burden of interoperability is on the ESB. We will also learn the widely used work flow language BPEL (Business Process Execution Language). Interestingly, a business process itself can be plugged to an ESB as a service. This (look for "Basic ESB Patterns") is a good introduction to the concepts of ESB. Do not worry about the IBM specific details.

The final goal of this assignment is to develop and deploy a travel agent BPEL process that interacts with an air ticket reservation service and a hotel reservaion service for making travel arrangements. We intend to deemphasize the specifics of the travel (city, dates, passengers etc.). Instead, the emphasis is on the concepts of ESB. Specifically, the travel agent process should be exposed as a JMS endpoint, whereas the air reservation and the hotel reservation services are exposed as light weight Web services. Also, the BPEL should be capable of handling faults (failed reservations) returned by the air and hotel services. If only one of the reservation suceeds, then it must be rolled back via compensation (simply by sending appropriate messages to the air or hotel service for cancellation).

The picture below shows the overall ESB configuration for this assignment. You will develop the dark blue boxes. The JMS Client is provided (see below). The JMS client interacts with the JMS endpoint which forwards the messages to the BPEL SU. The BPEL SU interacts with the LW Air and LW Hotel SUs. The air and hotel services do not have any business logic. Instead, they simply return success or failure depending on a control parameter in the requests.

However, there is significant learning and preparation required before this scenario can be solved.

Getting Ready

Maven

Maven is a java project management facility that takes care of shared JAR files and provides primitives for easy ESB project template creation. Read about, download, and install Maven. Especially, this introduction to POM is very useful.

ServiceMix

We will use Apache ServiceMix 3.1.2 for the ESB functionality. Note that the latest version is 3.2.1, but we will use 3.1.2 for compatibility with the Apache ODE BPEL engine (described below). ServiceMix is introduced and motivated along with the related terminology here. Some of the documents apply only to the newest version of ServiceMix, but it is generally easy to adapt the instructions for your version. Most of the times, the web pages have annotation boxes describing what has changed in the latest version of ServiceMix.

  1. Read through the home page of ServiceMix and familiarize yourself with the terminology (such as JBI) and the related ideas.
  2. Go through this Getting Started guide and try out the instructions. At the end of it you would have downloaded and started ServiceMix.
  3. Go through this Quick Start guide to experiment with deploying and using an example application.
  4. Now we are ready to try out developing Service units (SU) and service assemblies (SA) ourselves. Go through these set of exhaustive and largely accurate step-by-step tutorials.

ODE

We will use Apache ODE 1.1.1 JBI distribution as a BPEL engine that is deployed to ServiceMix as an ESB service unit. As we are using ODE only in the context of ServiceMix, we will need the JBI distribution and we will pay attention to ODE documentation on JBI related topics.

  1. Go through this ODE User Guide.
  2. Try to deploy a simple BPEL process to ServiceMix.

Putting it all together

Conventions

To ensure compatibility, please follow these conventions in your service assembly. The WSDL files are provided only to ensure uniformity of names, they cannot be used to generate code for your services.

  1. The air reservation service must support this WSDL.
  2. The hotel reservation service must support this WSDL.
  3. The travel agent BPEL service must support this WSDL. The possible values of air and hotel booking status are "succeeded", "failed", and "compensated".
  4. The air and hotel services must print the messages they receive to the serviceMix console.
  5. The air and hotel services must be invoked concurrently from BPEL.

Deliverables

Submit your service assembly named as unityID-p4-sa. This assembly must contain service units named as unityID-p4-bpel-su, unityID-p4-jms-bpel-su, unityID-p4-lwair-su, and unityID-p4-lwhotel-su. Submit the project tree containing your SA and SUs with their targets built.
You also need to include a README file with team members names. This README can also contain a description of the functional sections of the program as well as any errors that have prevented you from submitting a completed project. The more detailed a description of the work you have put in (not stack traces) will increase the number of points you can be awarded.

Testing and Grading

We will test your assemblies in the following way. Note from the conventions that the travel agent, air, hotel services take a parameter to control whether or not a successful reservation is returned. This allows us to control the various failure scenarios from the client.

  1. We will invoke the travel agent process from the JMS client and inspect the response.
  2. We will check that when both air and hotel services are asked to succeed, "succeeded, succeeded" is returned and no compensations happen.
  3. We will check that when only one of air and hotel is asked to succeed, the "compensated, failed" or "failed, compensated" is returned and appropriate services are compensated.
  4. We will check that when both air and hotel are asked to fail, "failed, failed" is returned and no services are compensated.

Useful Tips / Pointers

As this is an open source project, the going may get rough. Here are a few problems we have discovered, and their solutions. If you run into a new problem, try to resolve it via the usual means (Google, forums, etc.); it is part of your learning.

  1. Avoid using "mvn jbi:Deploy". Instead copy all components from servicemix\components to servicemix\install. To cleanly rebuild and redeploy your project: (1) delete the assembly jar from servicemix\deploy, (2) delete target folder from all your SUs and SA, (3) issue "mvn install", (4) copy the newly build target\*-sa to servicemix\deploy.
  2. Not all of the tutorials will build and deploy properly! When tested in Windows most tutorials ran successfully, but the *nix tests were not as successful.
  3. The Maven command for creating template (archetype) project directories as given in the tutorials by default generates templates for 3.2.1. To check if your generated project template is correct, inspect the pom.xml file. If the property "servicemix-version" is set to "3.2.1", it is incorrect. To correct this you add an -DarchetypeVersion=3.1.2 to the command given here.
  4. If you forgot to add "-DarchetypeVersion=3.1.2" when you created any of your SUs or SA, maven would have pulled in 3.2.1 JARs from remote repositories. To remedy this, delete your local maven repository (.m2). Then, recreate your SUs and SA for 3.1.2. Now, when you issue "mvn install", maven will look for only 3.1.2 compatible JARs.
  5. The permitted set of Maven ServiceMix archetypes are listed here. Make sure you use the archetype specific to the SU you want to create and not the generic one (this ensures that all the necessary dependencies are included in the project).
  6. To interact with a service exposed via a JMS service unit, you can adapt this JMS client. To compile it, you will need to add all of ServiceMix JARs, JARs extracted from servicemix-jms-3.1.2-installer.zip in the components directory, and lingo JAR. This is the .classpath file of an eclipse project that successfully compiles the JMS client. The client currently results in a NullPointerException at the servicemix console (discussed on the message board). This is a documented sporadic behavior in 3.1.2. If you retry it a couple of more times, it will go through successfully.
  7. Avoid spending time with the tutorials that do not work or deploy properly. Instead, get a start on the actual project, and look at the tutorials only to see how they configure particular types of endpoints or how they specify their BPEL.
  8. The loan-broker-bpel example included in the distro has a very similar configuration. Try to compare your code with this example, if you run into troubles.
  9. When you create your ODE service unit (with the corresponding archetype), it generates some stuff for you in the src\main\resources directory. The auto-generated BPEL fails! Please delete the auto-generated stuff, and develop your BPEL from scracth. Again, loan-broker-bpel is a good reference to get a start.
  10. This tutorial explains how to handle faults and perform compensations in BPEL.
  11. Not all features of Ws-BPEL 2.0 are supported by ODE. See this list of supported features.
  12. Here are some of the pom files that can be used as reference.
  13. As a more concrete alternative to P4Client, there is the ESB_Client class that fills in most of the details that are omitted by P4Client. The only change you will need to make is to the namespace of the request.