In Part I of this article (JDJ, Vol.6, issue I) we discussed solving legacy data integration problems with VisualAge for Java and WebSphere Studio. In Part 2 we'll discuss using the MQSeries Integrator and some of the steps for creating data translations and data flows.

MQSeries Integrator extends MQSeries by adding message brokering that's driven by business rules. MQSI lets us add the intelligence to route and transform messages or filter messages (content-based or topic-based). It also lets us perform direct database access so we can augment or warehouse messages. We'll look primarily at routing and transforming as we build our solution.

The MQSI Control Center lies at the heart of MQSI's user interface. We'll use this tool to create message types and message flows. Figure 1 shows an example message flow, one that would be applicable to our problem. Notice the similarity between this screen and the VisualAge for Java Visual Composition Editor. Components are dropped on the canvas and wired together in much the same manner as Java objects are in VisualAge.

The Message Flow
In our sample message flow we left out any error or exception handling so we could highlight the core tasks. As you can see from Figure 1, the message flow describes our stated problem: it takes two disparate inputs and merges them into a single XML output stream. Both the C-formatted data and the XML data from our legacy applications arrive on message queues - the MQInput nodes. The C input is routed through a processor, or "compute node," that will translate the data into XML. Both streams are then sent off to an XML processor compute node, where they're merged and placed on an output queue.

Notice that we haven't defined how the data gets onto the input queues in the first place. In the complete solution, we'll define another message flow that sends request messages to both legacy applications with the appropriate search criteria for locating a customer. The input messages for the "Combiner" flow represent the replies from such a query. Different queries could be posed - a search by name or postal code, for example. The message flow defined here could be used to process the results of any such query.

Before we get too deeply into the message flow, we need to use the MQSI Control Center's Message Repository Manager to define the message that will encapsulate the C-formatted data. There are three steps needed to create a Message Repository Manager (MRM) message from a C structure:

1. Create the message set.
2. Import a C structure to create a new message type within the message set.
3. Create a message of that new message type.

The creation of the message set only involves choosing a menu option on the Message Sets pane and giving the new message set a name. MQSI can read a C header file or a COBOL copybook, parse the contents, and generate a message type based on the structures or COMMAREAs defined in the file. We've used the C header file from Listing 1 (reproduced from Part 1 of this article) to create a completed message type with a minimal amount of typing and clicking on our part.

Now we can return to our message flow. Each of the input nodes has properties in which we can enter the queue name that will be used and the message format that will be presented. For the CInput node, the message domain will be MRM and the format will be our generated type, C_CUSTOMER_TYPE. For the XMLInput node, the domain is XML.

Notice how we've structured the flow so the C structure is translated to XML before further processing. Figure 2 shows the completed property sheet for the CtoXML Compute node. We added our MRM message type C_CUSTOMER_TYPE and wrote the ESQL for the translation. To convert the C structure to XML, we included the line:

We then used OutputRoot.XML in the lines that follow to set the field values in the output XML. Notice that we changed the field names between input and output and that we didn't include the fields that aren't required by our Web application.

Because we chose to perform this translation before sending both streams to a common processor, the XMLProcessor can concern itself with the job of merging two XML streams without knowing that one or more of its inputs started life in some other format. Again, here's a good opportunity to create a reusable component. Finally, we can use the MQSI Control Center to deploy our message flow to the running broker. We can do this from the Assignments page. Figure 3 shows a completed deployment.

Java Access to MQSeries
We have several ways to access MQSeries from the code we'll develop in VisualAge for Java. MQSeries has featured a robust Java API for several years. The original MQSeries Java API predates the Java Message Service (JMS) API but since the introduction of JMS, IBM also provides a JMS implementation for MQSeries so that developers can write portable code to access MQSeries. Finally, the IBM Common Connector Framework (CCF) features an MQ connector. CCF is quite powerful and flexible, and it provides the basis for the upcoming Java Connector API in J2EE.

We took a middle-of-the-road ap- proach here and created a wrapper class called MQAccess that we'll use for our queue access. Right now this class is implemented using the MQSeries "original flavor" API, but we could change the implementation at any time without affecting our business logic. This class is shown in Listing 2. It uses the IBM XML4J Parser for part of its data handling, so that feature must be added to your VisualAge for Java workspace. We've provided a main() method to illustrate how the methods in the class should be called. To run this class, however, there are other steps that still need to be taken, not the least of which is to set up MQSeries, create something to mimic the legacy systems during testing, and start the MQSI Broker. This all falls outside the scope of this article but you can get a complete solution from the "Patterns for e-business" kit that's available from IBM.

Finishing Off
Once the rest of the infrastructure is set up and our MQAccess class is tested in the VisualAge for Java environment, the next step is to move the class into WebSphere Studio so we can create the wrapper servlet, HTML, and JSP for the Web application. From this point we can deploy to test and production servers or to the VisualAge for Java WebSphere Test Environment; move Java code back and forth between Studio and VisualAge for editing, testing, and debugging; and further enhance the HTML and JSP files. For a discussion on how to do all these things, see JDJ (Vol. 5, issues 9, 10).

Summary
Hopefully, in this brief discussion of MQSeries Integrator we've been able to show how valuable a message broker and translation/routing engine based on business rules can be when you need to solve a problem that involves the integration of legacy data, regardless of the format and the location of the data or legacy systems. Once we created our message flows, we created a flexible set of tools - reusable components we can build upon as we need to access back-end systems in new ways. The MQAccess class we created could serve as the basis for a set of EJB components. It could service stateless session beans for generic MQSeries access or even be the engine for BMP entity beans.