There are articles on IBM developerWorks that show you how to use IBM WebSphere Process Server to address a number of different technical and business scenarios. Similarly, there are also articles that describe how to apply the IBM WebSphere Enterprise Service Bus (ESB) product to a number of ESB-related scenarios. A developer might tend to focus on using one of these products more than the other, largely based on their own background and skill level. Of course, the end product benefits most when the technology used is in fact the best match for the overall solution. To this end, this discussion looks at a business problem, then examines the differences between what we call business logic and connectivity logic, and finally shows how to implement the logic in both products. A concrete example that you can download and experiment with in your own environment is also included.
The business problem
Here is the scenario: Fictional company Global Airlines recently formed an alliance with two other airlines, Atlantic Airlines and Pacific Airlines. As part of this arrangement, passengers who have accumulated miles on one airline can use them to book a flight on one of the others. Hence, Global Airlines wants to create a new solution that enables passengers to book a miles award trip. If a passenger has a miles account on one of the other airlines, Global Airlines' solution will automatically retrieve the passenger's status from the other airlines.
The Global Airlines architecture team decides to build this new solution based on the principles of Service Oriented Architecture (SOA), leverage the IBM SOA Foundation as the underlying architectural model, and, subsequently, use its products for the run time environment.
Starting with the architecture
Companies aspiring to build solutions based on SOA typically establish an architectural reference model for their enterprise. Such a model enables them to explicitly depict certain functional areas and show how they are related to each other. Any new solution is built with this reference model in mind, and different aspects of this solution can use different products and technologies.
IBM has defined and published the SOA Foundation Reference Architecture, which can act as the starting point for any company's reference architecture based on SOA. Figure 1 shows the logical model view of this architecture.
Figure 1. IBM SOA Foundation Reference Architecture logical model
This figure introduces different types of services that interact with each other via the Enterprise Service Bus. The task that the Global Airlines team is now facing is to properly structure the new reservation solution. The team has identified that some of the required logic deals with implementing the actual reservation business process, and other logic handles interacting with and connecting to services provided by another airline.
Business logic versus connectivity logic
The two different types of logic needed for the new reservation solution can be mapped into a reference architecture similar to the one shown in Figure 1. The process-relevant parts of the solution are handled within the "process services," and the ESB will handle the connectivity with the other airlines' services, including any data transformation that might be needed.
This separation of concerns enables developers with two different skill sets to work on the solution in parallel:
- The business logic is developed by someone who is familiar with reservations and the steps necessary to successfully book a flight.
- The connectivity logic is created by someone who knows the protocols and data formats supported by the other airlines within the alliance.
What makes it possible for the two pieces of logic to communicate is a virtual service interface. We call this interface virtual because there is no "real" service provider for it. The interface is offered by the ESB, which then routes and manipulates request and response messages appropriately. Once this virtual service interface is known, both pieces of logic can be developed and maintained independently. This will be more apparent later in this article. (For the purpose of this example, assume that the service interfaces for each airline to return a frequent flyer's miles already exist and are well known.) Figure 2 shows a graphical representation of the solution.
Figure 2. The Award Flight Reservation solution
This figure shows how the business process and the mediation flow are loosely coupled, with the only dependency they have on each other being the virtual service interface mentioned above. New airlines joining the alliance can easily be added to the solution without requiring any changes to the business process.
Building the solution
For the remainder of this article, assume that the Global Airlines team developing the new reservation system chose WebSphere Process Server (hereafter referred to as Process Server) to host the business process, and WebSphere ESB for the mediation flow. The tool used for both run time environments is WebSphere Integration Developer (hereafter referred to as Integration Developer). While this choice might otherwise deserve a more detailed discussion, suffice it to say here that Process Server is IBM's prime solution for developing and executing business processes, and that WebSphere ESB supports the requirements given by our simplified example. Moreover, WebSphere Process Server includes the WebSphere ESB runtime, and both share the same Integration Developer tool.
Step-by-step instructions are not used here to illustrate how to build the solution. Instead, the major and most interesting parts of the solution will be described, with an explanation of why it was built that way. An Integration Developer project interchange file with the complete example is included with this article. You can download this file and import it into your own workspace. This sample project is for illustration purposes only; several elements that would be necessary for actual use have been omitted for simplicity.
This article assumes a basic understanding of WebSphere Integration Developer. You will find pointers to additional material on the basics of creating solutions with Integration Developer in the Resources section.
To define resources to be used in both business logic and connectivity logic, a library module named GlobalAirlinesLibrary is available in the sample. In this library module, the following resources are defined:
- Reservation business object: Includes all information about the reservation of a flight.
- PassengerDetails business object: Includes passenger details of the reservation.
- FrequentFlyerInfo business object: Includes frequent flyer information of the passenger.
- RetrieveMilesStatus interface: Interface to retrieve mileage from the appropriate airline; a request is called with the passenger's detail information, and his/her mileage is returned in integer format (Figure 3).
Figure 3. The RetrieveMilesStatus interface
All of the resources defined in this library share the same namespace. The same is true for the artifacts described below; each module uses its own namespace for its contained resources. This reflects that they belong to different parts of the overall system, and also avoids any clashes in the underlying generated code by ensuring each module ends up in differently named Java™ packages, to name one example.
The interface and related business objects described above represent the only connection point between the business process and the mediation. Thus, it needs to be defined first.
Business logic (WebSphere Process Server)
The business logic for the Airline Award Reservation solution is defined in the GlobalAirlinesBP module. In this case, you create the process component first and identify all external dependencies this component will have. Those dependencies are represented as partner links, which you will later resolve as part of creating the Service Component Architecture (SCA) assembly.
ReservationProcess business process component
This is the main component in the GlobalAirlinesBP module. In this business process, the reservation operation process is defined and it has an interface named ReserveAwardFlight. The process is built in BPEL using the process editor in the Integration Developer tool, as shown in Figure 4.
Figure 4. The business process
When a reservation is requested, a new process instance is generated and input reservation data is received in the Receive activity. In the SetPassengerDetails activity, data is copied from the incoming request message to a set of local variables for later use in the process. The RetrieveMiles activity is used to obtain the number of miles the passenger has available for use in this reservation. Then, another activity is invoked, this time to complete and confirm the reservation. Finally, the confirmation is returned to the caller of the process in the Reply activity.
The two external activities that are called from within the process (RetrieveMiles and ReserveWithMiles) are represented by partner links, which you can see in the Reference Partners section in Figure 4.
This brings us to one of the main points of this article. We assume that there are multiple service endpoints for the members of the airline alliance (two will be defined later), and the appropriate one must be selected to retrieve mileage for the passenger making the reservation. Also, each airline's service endpoint might have its own interface (remember the assumption that those existed before this solution was designed). If the business process included the logic to select the correct service endpoint and transform to the proper data or interface, we would mix business and connectivity logic, making it difficult to develop and maintain the logic over time.
Instead, following the good practice of separating concerns, the selection and transformation logic are delegated to the ESB, and the business process just calls a virtual service interface on the ESB, where the connectivity logic is executed.
The GlobalAirlinesBP SCA assembly
The external dependencies of the ReservationProcess process component can be resolved by wiring its references to other components. The process defined above has two such references, thus two additional components are created in the assembly:
RetrieveMilesImport is an SCA import that is used to connect to the external connectivity logic to retrieve the passenger's mileage from the appropriate airline. It supports the RetrieveMilesStatus interface. An SCA binding is used in this sample to bind the business process and the connectivity logic. This binding was chosen because both modules will be deployed into the same server instance, and this binding is the most efficient for that case.
ReserveWithMiles is a Java component that receives the reservation information and retrieved mileage, and returns its confirmation with true or false. In a real environment, this would be another external component. However, in this sample, an internal Java component is used for simplicity.
The components and their relations are shown in Figure 5.
Figure 5. The GlobalAirlinesBP assembly
Notice that we did not add an export component to this wiring, because we will test the component later using the BPC Explorer, which requires no export.
Connectivity logic (WebSphere ESB)
As already mentioned earlier, the connectivity logic is responsible for content-based service endpoint selection, and for data or interface mapping to call the selected endpoint. This logic will be created in the GlobalAirlinesESB module. Unlike the GlobalAirlinesBP module, you start out here by completing the assembly diagram first, because all of the external dependencies are already known at this time. The actual connectivity logic, contained in a mediation flow component, is created later.
The GlobalAirlinesESB assembly
The GlobalAirlinesESB module consists of a mediation component, its export, and two imports. These components and their relations are shown in Figure 6.
Figure 6. The GlobalAirlinesESB assembly
RetrieveMilesMediation is a mediation component to select an appropriate service endpoint and map to the selected endpoint's interface to call it. The component contains the RetrieveMilesStatus interface defined above. Details about the component are described in the next section.
RetrieveMilesExport is an SCA export that is used to make the RetrieveMilesMediation component accessible for the business process created above. The mediation component is called from the business process through this export. Hence, the binding type used in the business process module's import must match the mediation module's export. SCA bindings were chosen here for both to enable the two modules to communicate efficiently (among other things, SCA bindings do not require a network hop in cases where both modules run in the same process).
Both AtlanticAirline and PacificAirline are SCA imports that are used to connect to external Web services provided by the airlines. Each service has a method to retrieve a passenger's mileage, but the interfaces are slightly different from each other. While the GetMilesFromAtlanticAirline interface takes a complete PassengerDetails business object as its input parameter and returns the miles as an integer value, the GetMilesFromPacificAirline interface requires the passenger name as a string and returns the miles as a string, too. They also use different names for their operations.
Each service uses a Web service binding with SOAP/HTTP as the transport protocol. (If you test the downloadable sample in your environment, you might have to modify the host name and port number in the endpoint URL for both imports to fit to your environment.)
The RetrieveMilesMediation mediation flow component
This is the main component in the GlobalAirlinesESB module. In this mediation, the appropriate airline service is selected based on the passenger's frequent flyer information. Also, data mapping is executed to transform the request and response parameters to match the interface of the selected airline service. Figure 7 shows the request part of the RetrieveMilesStatus interface.
Figure 7. The RetrieveMilesMediation mediation flow component
In the MessageFilter1 primitive, the airline's code, which is stored in the passenger's frequent flyer information, is checked to select a suitable airline service for the request. If "AA" is specified for the airline code, AtlanticAirline is selected and the request message is forwarded to XSLTransformation1. For all other airline codes, PacificAirline is selected and the message goes to XSLTransformation2. Figure 8 shows the properties for the MessageFilter1 primitive.
Figure 8. MessageFilter1 primitive properties
In each XSLTransformation, parameters are transformed so that they match the target service interface. In Figure 9, the transformation for the request message to the AtlanticAirline service is shown.
Figure 9. The transformation for the AtlanticAirline service endpoint
Notice that not only the request messages, but also the response messages have to be transformed into the right format. The other transformations used in our example are quite similar to the one shown above and are therefore omitted. (Refer to the download sample imported into your own environment to explore all the transformations.)
Test the solution: Reserving your first flight
It is now time to test the Airline Award Reservation solution. After starting your test server (WebSphere Process Server V6.0), deploy the following projects included in the sample to that server:
(In an actual processing environment, the process logic (GlobalAirlineBPApp), ESB logic (GlobalAirlineESBApp), and each service project would most likely be running on separate servers.)
Once the test server has started, start the Business Process Choreographer Explorer (BPC Explorer) utility, using the Launch menu of the test server's context menu. In the BPC Explorer, check ReservationProcess in the My Process Templates panel, and click the Start Instance button to start the business process. Figure 10 shows how you would then input information for the award reservation.
Figure 10. BPC Explorer
After you enter the information for the reservation, click Submit. The business process instance is executed, the mediation flow is invoked, and the appropriate airline service is called to retrieve the passenger's mileage. If the reservation is confirmed, a value of "true" is returned to the BPC Explorer as shown in Figure 11.
Figure 11. BPC Explorer shows the result of the process invocation
Now check the Console View in your tool. Depending on the data you entered in the input panel, something like the following messages should display:
[9/23/07 17:34:00:094 CDT] 00000083 SystemOut O [AtlanticAirlineService] retrieveMiles() [9/23/07 17:34:00:328 CDT] 00000084 SystemOut O [ReserveWithMilesImpl] reserveWithMiles()
If the reservation is called with the airline code "AA," the AtlanticAirline service is selected and called in the connectivity logic, and the message:
is logged in the view. If it is called with any other airline code, the PacificAirline service is selected and the message:
This article explained how to leverage a reference architecture that can lead to good separation of concerns when building service oriented solutions. The example of an award flight reservation solution was split into business logic (developed and deployed in WebSphere Process Server) and connectivity logic (developed and deployed in WebSphere ESB). Both parts of the solution can be developed independently of each other, and changes to one do not need to impact the other. The skills required to develop these different parts are also different, one focusing on business aspects and one focusing on connectivity aspects.
|Sample code||globalairlinesPI_new_09182007.zip||104 KB|
- Exploring the Enterprise Service Bus
- IBM SOA Foundation whitepaper
- WebSphere Process Server product information
- WebSphere ESB product information
- Service Component Architecture
- Technical Overview of WebSphere Process Server and WebSphere Integration Developer
- Patterns: Building Serial and Parallel Processes for IBM WebSphere Process Server V6
- Getting Started with WebSphere Enterprise Service Bus V6