Part 1 of this series covered the architecture of the On Demand Operating Environment. Part 2 demonstrates the best practices, patterns, and products that you can use to build an on demand solution. The series uses a fictitious financial company, odFinance, to facilitate the discussion. To download the code used in this article, click on the Code icon at the top or bottom of this page.
Through IBM® WebSphere® Portal, new customers can enroll online, and existing customers can be authenticated. Customers can invoke different services such as personal loan, online trade, and portfolio management. This article focuses on how odFinance uses an Enterprise Service Bus (ESB) pattern to facilitate mediated interactions between the customer requests and the back-end services.
odFinance customers use the customer enrollment application when they want to open a new bank account. Customers log into the portal and fill out a form with their profile information. Later they receive a new account id through e-mail.
Behind the scenes, odFinance needs to integrate a number of disparate applications. Customer profile information is stored in a legacy Enterprise Information System (EIS), and customer relationship information is stored in a purchased CRM application.
The IBM Patterns for e-business (see Resources) enables architects to implement solutions through the reuse of assets from successful proven experiences. It identifies four business patterns: Self-Service, Information Aggregation, Collaboration, and Extended Enterprises. The Self-Service pattern captures the direct interaction between users and core business systems and applies perfectly to the customer enrollment scenario. Within the Self-Service pattern, seven application patterns are defined, ranging from the simple stand-alone Single Channel application pattern to the most complex Agent application pattern. One of the seven patterns is the Decomposition application pattern. As Figure 1 shows, the Decomposition application pattern provides the ability to take a user request and decompose it into multiple requests to be routed to multiple back-end applications. This article illustrates how you can implement the Decomposition pattern using the ESB to provide connectivity between services, and how the ESB mediates service requests and responses.
Figure 1. The Decomposition application pattern
Realizing the ESB pattern in today’s products
The ESB provides the connectivity infrastructure for Service-Oriented Architecture (SOA). The ESB enables the use of multiple protocols (for example, synchronous and asynchronous) and performs transformation and routing of service requests. The ESB enables services to interact with each other based on the quality of service requirements of the individual transactions. It also supports different standards such as SOAP, XML, WSDL, JMS, J2EE, JAX-RPC, and so on.
To implement the customer enrollment application using the ESB pattern, you can use a number of products that are available today, such as the WebSphere Business Integration Message Broker (WBI Message Broker -- see Resources) and the Web Services Gateway (see Resources). The Web Services Gateway provides a common access point so that the Portal can send in requests using SOAP/HTTP. It provides transport protocol conversion, for example, converting the request into a SOAP/JMS message for invoking the enterprise services.
You can use the WBI Message Broker to transform an input message into separate messages that can be routed to different back-end applications. The applications retrieve messages from the queues asynchronously and process them. The WBI Message Broker also acts as a mediator and performs some audit logging. The data it logs can be used for correlation later. For example, it can validate that all the applications are updated correctly and trigger an autonomic recovery action if something goes wrong.
Figure 2 shows the overall customer enrollment application. This architecture effectively takes multiple, diverse back-end applications and unifies them into one interface for the customer.
Figure 2. Customer enrollment application architecture
The WBI Message Broker Toolkit (see Resources) provides an integrated environment for developing, testing, and deploying your message flow. Before you begin, you must configure the broker domain that is used for administering components and resources needed to run the brokers. Use the Getting Started Wizard Figure 3 shows to set up the broker domain and the database that will store the broker configuration information.
Figure 3. Getting Started Wizard
The Broker Application Development perspective is where you create your message flow. A message flow is created by wiring together a number of nodes. WBI Message Broker ships a large number of message nodes, including nodes to handle input and output messages, nodes to manipulate, transform, and map messages, nodes to interact with databases, as well as nodes to handle errors and reporting. Each node may have input and output terminals. The connections between nodes can be made using drag and drop in the Message Flow Editor.
The customer enrollment message flow is responsible for routing the input message the portal application creates to the CRM application and the customer profile application. The CRM application is a purchased application that the sales department uses to develop marketing and relationship-building programs with the customers. The customer profile application creates a new customer profile and stores it in a legacy system. Figure 4 shows this message flow.
Figure 4. Customer enrollment message flow
The EnrollmentIn node is an MQInput node responsible for reading the message that initiates the message flow. The CRMIn and LegacyIn are MQOutput nodes -- they represent the input queue to the CRM application and the customer profile application, respectively.
In addition to routing the input message to the back-end applications, the customer enrollment message flow must also transform the input message to the appropriate message format that is suitable for the back-end applications. The CRMAdjustment and LegacyAdjustment are Compute nodes that manipulate the message content and transform them using the ESQL scripting language. For example, the LegacyAdjustment node needs to add some header information to the message so that the business objects that are developed using the WBI Adapter Framework can consume it (see Resources).
Finally, the message flow also mediates requests and responses between the end points. This is handled by the Trace nodes that generate trace entries to record what is happening so that it can be used for auditing purposes.
Once you complete the development of the message flow, you have to create a package of deployable resources by creating a broker archive file. The broker archive file has a .bar extension and contains message flows and message sets. To deploy the Enrollment.bar file, use the Broker Administration Perspective as Figure 5 shows and select the broker to deploy to.
Figure 5. Broker Administration Perspective
Connecting to legacy system using WBI adapters
WebSphere Business Integration Adapters helps you connect to different legacy applications, technologies, and mainframe systems using one consistent approach. WBI adapters allow heterogeneous business applications to exchange data over an integration broker such as WBI Message Broker or WBI Server Foundation (see Resources). Data is transferred between the adapter and the integration broker by sending XML messages over JMS. The structure of each message, which describes a business object, is defined in XML schema.
A business object consists of attributes describing the data and a verb describing the action. The most common verbs associated with a business object are Create, Update, Retrieve, and Delete. The WBI Adapter Development Kit includes a Business Object Designer that you can use to define business objects. A business object definition can also be automatically generated from existing database schemas.
A WBI adapter supports four interaction patterns: Adapter initiated one-way, Adapter initiated request-response, Integration broker initiated one-way, and Integration broker initiated request-response. The customer enrollment application uses the Integration broker initiated one-way interaction pattern. This pattern is one of the most popular usage scenarios. The WBI Message Broker requests the WBI adapter to create a customer profile, but it will not wait for the completion of the action. This scenario can be broken down into five basic steps, as Figure 6 shows:
- The LegacyIn message node sends a message to the designated WebSphere-MQ queue.
- The Adapter Framework picks up the incoming message.
- The Adapter Framework maps the message to a business object.
- The Adapter Framework calls the Adapter passing in the business object.
- The business object is used to create the data in the legacy EIS.
Figure 6. WBI Message Broker initiated, one-way interaction
WBI Adapter Development Kit also provides a Visual Test Connector (VTC) that you can use to unit test your adapter configuration and your business objects. You can create business objects inside the VTC and send them to the integration broker. You can also inspect a business object received from the integration broker. Figure 7 shows the VTC.
Figure 7. Unit testing the business objects using the Visual Test Connector
This article examined a number of ESB patterns that you see in today's products. Using a customer enrollment business scenario, it illustrated how a portal application, a CRM application, and a legacy application can use a message-driven architecture to generate and consume messages independently of one another. The ESB provides connectivity and the transformation and routing of messages, as well as enables the use of multiple protocols. To meet the requirements of the on demand world, IBM continues evolving the messaging products and the ESB programming model, which future articles will discuss.
| Name | Size | Download method |
|---|---|---|
| i-odoebp2.zip | HTTP |
Information about download methods
- Read Part 1 of this series, "Best practices for using the thirteen capabilities of the IBM On Demand Operating Environment" (developerWorks, September 2004).
- Read the book "Patterns for e-business" by Adams, Koushik, Vasudeva, and Galambos (IBM Press, 2003).
- Find out more about IBM Patterns for e-business.
- Get a product overview of WebSphere Business Integration Message Broker V5.0, formerly WebSphere MQ Integrator Broker.
- Read the developerWorks article, "Integrate Web Services Gateway with WebSphere Studio Application," to learn how to shorten the development cycle for Web services (developerWorks, January 2004).
- Check out the WebSphere Business Integration Message Broker Toolkit for information and downloads.
- Explore the WebSphere Business Integration Adapters page, and learn how to quickly and easily create integrated processes that exchange information.
- Check out the WebSphere Business Integration Server Foundation V5.1.
- Read the Redbook "Patterns: Implementing an SOA using an Enterprise Service Bus" for more information on the capabilities of the ESB (IBM, July 2004).
Christina Lau is a Senior Technical Staff Member at IBM. Christina is an architect on the On Demand Development team focusing on the next generation technologies for the On Demand Operating Environment. You can reach Christina at clau@ca.ibm.com.
Hendra Suwanda is currently working in On Demand Development and Incubation at the IBM Toronto Laboratory. He previously worked for WebSphere Commerce as an architect. He can be reached at suwanda@ca.ibm.com.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags