Product Reviews

Every company that's been around longer than a few months has probably created or purchased many different systems dedicated to specific areas of the business. For example, let's say customer files were set up years ago using off-the-shelf software. The software had hooks for customization, and some features were added. Over the years the customer list has grown very large, and the company has become dependent on this system. You know the word: legacy.

Of course, the developers who did the customization are long gone.

At some time between then and now new features were needed by the marketing department. The development staff was afraid to make changes in the poorly documented code and, besides, the marketing department's needs had little to do with the accounting department's use of their system. So armed with a C compiler, they added an entirely new system that provided the features they required. But it also ended up duplicating some of the features and data of the existing system because it needed that information and couldn't easily extract it.

Now we can add a new term to our vocabulary: stovepipe processes. Each system treats the customer independently, so it's difficult to obtain a complete view of the company's relationships with any given customer. Now, in the age of e-commerce, the company has decided that customers need to see their complete profiles online and you, the Java systems architect and developer, have the task of creating the Web application that will do this. Now it's your problem.

The issue resolves to this: "How do we obtain a single view of the customer across all these systems?"

Architecture for the Solution
The problem can be solved by building an architecture around MQSeries and MQSeries Integrator (MQSI). MQSeries, IBM's messaging and queuing middleware, provides connectivity across multiple systems, allowing different applications on different platforms to communicate with each other in a straightforward and reliable manner. MQSI allows you to isolate client applications that request data from the complexities of where and how legacy applications handle the data.

This architecture allows you to format client requests as required and then route them to the appropriate systems according to a central rules database. At the same time, this architecture is flexible and can be easily extended as new systems or business requirements are introduced.

Strategy
Figure 1 shows the design of our proposed solution. We'll adopt the following strategy:

1. Enable the back-end applications with MQ.
2. Develop MQSI message formats and flows that route and translate data between the legacy data formats and XML - our format of choice for the new Web application.
3. Deploy the servlet and JSP that will handle client requests on the WebSphere Application Server, Advanced Edition.
4. Develop the business logic and front end with VisualAge for Java and WebSphere Studio. This allows us to take advantage of their tight integration with the application server.

For the purposes of this article we'll assume that both back-end systems have already been MQ-enabled by their respective departments. Because the older system could stand only limited modification, a wrapper script was written to capture the binary output stream and place it on a queue. This binary record format can be described using the C language type definition shown in Listing 1.

For the newer legacy system, the group maintaining it managed to modify the code to translate its data structure into XML before placing it on the queue. Listing 2 shows an example record from this application. We'll configure a new message format in MQSI, define the message flows to accept the dual inputs, and merge them into a single output XML stream (see Listing 3).

VisualAge for Java contains connector technology for accessing MQSeries queues. It also provides XML parsers, which we'll need when we add our new business logic. Since we plan to deploy to WebSphere Application Server, our job will be made easier by the WebSphere Test Environment and live debugging engine that are in VisualAge for Java.

Once we've created the MQSeries access code and business logic in VisualAge for Java, we can take the Java code into WebSphere Studio and generate the servlet, HTML, and JSP files necessary to our Web application. We'll also use WebSphere Studio to deploy the application onto our WebSphere test server.

This column recently discussed using VisualAge for Java and WebSphere Studio in conjunction with WebSphere Application Server to create, test, and deploy end-to-end Web application solutions (JDJ, Vol. 5, issues 9 and 10). Therefore, we won't focus on that aspect of our project. Instead, in Part 2 of this article we'll look at MQSeries Integrator and some of the steps for creating data translations and message flows. But we'll be able to give you only a taste of the facilities provided by MQSI. For a complete discussion of end-to-end solutions, we urge you to examine the following resources.

Resources
If you'd like to explore the entire end-to-end setup of an MQSeries/MQSI environment for the development and testing of legacy integration applications consult the following sources:

1. IBM's Patterns for e-business Web site. The Patterns for e-business Development Kit available here is a self-configuring, end-to-end skeleton Web application. The PDK is a best practice implementation of the User-to-Business pattern: www.ibm.com/software/developer/web/patterns/.
2. Van de Putte, G., Brett, C., Sehorne, P., and Stubblebine, S. (2000). Business Integration Solutions with MQSeries Integrator. IBM Redbook: ibm.com/redbooks.
3. Sadtler, C., Ahmed, S., Fleifel, G., Jeynes, M., and Young, Y. (2000). User-to-Business Patterns Using WebSphere Advanced and MQSI. IBM Redbook: ibm.com/redbooks.