WebSphere Message Broker scenario

WebSphere Message Broker manages the flow of information in your business, applying business rules to route, store, retrieve, and transform the information as required by the different systems in your business and the systems of your customers, suppliers, partners, and service providers.

The following scenario outlines an example of how WebSphere Message Broker can be used to solve IT infrastructure problems in a business.

Mergers and acquisitions scenario

This scenario describes how WebSphere Message Broker is used by a fictitious insurance company to manage two disparate IT infrastructures after a small, Internet-based insurance company is acquired by a large, more traditional insurance company. The description focuses on what happens when a potential customer requests a motor insurance quotation using the merged company's Web site. This scenario is based on a larger, more complex scenario that was published on developerWorks. To read the full scenario see the links at the end of the scenario description.

Background

Company A is a motor and general insurance company that has been in business for about 50 years and currently has about 5 million policyholders. The company uses agents and a call center to communicate with customers. The company has a large legacy IT infrastructure, which includes CICS Transaction Server on z/OS and IBM DB2 Universal Database on z/OS.

Company B is small Internet-based motor insurance company, which currently has less than one million policyholders but is expanding. The company's IT infrastructure includes WebSphere Application Server on Windows 2000, and Oracle Enterprise and IBM DB2 Universal Database on Windows 2000.

Problems

Company A acquired Company B to gain access to the Internet-based insurance market and to use Company B's Internet-based skills and IT infrastructure. The two companies have customer and policy data of different formats but, for legal reasons, the data from the separate companies cannot be merged. However, the administration costs of managing the separate IT infrastructures are high. Also, customers, agents, and call center staff need to be have a single administration process to interact with the company's data.

Solution

Now that the two companies have merged, users can request an insurance quotation by giving some basic personal information in a form on the new company's Web site. WebSphere Application Server, on which the Web site runs, forwards the request in XML format to WebSphere Message Broker using the request queue in a WebSphere MQ cluster. WebSphere Message Broker transforms the XML request to the legacy COMMAREA format that is used by Company A's systems, then routes the request to Company A's systems. WebSphere Message Broker also routes the request, in XML format, to Company B's systems. Both systems return a quotation to WebSphere Message Broker.

Logic within WebSphere Message Broker also requests a risk assessment from the internal underwriter and applies the returned risk to the quotations from Company A's and Company B's systems. The broker detects that, in this instance, the best or lowest quotation for the customer has been generated by Company A's systems. So the broker transforms Company A's quotation from COMMAREA to XML and routes the quotation back to WebSphere Application Server using a reply queue in the WebSphere MQ cluster where the quotation is stored for up to 14 days. WebSphere Application Server returns the quotation to the customer.

The following diagram illustrates the flow of information in this scenario.

A diagram to show the flow of data when a customer requests a quotation from the merged company's Web site.