Installing MQSeries Integrator version 2 is relatively simple. IBM seems to have spent considerable time making the setup painless, even for those people who are new to MQSeries and enterprise integration.
This, coupled with the feature enhancements, should make Integrator version 2 a likely upgrade choice for existing MQSeries customers. Integrator must be used with MQSeries.
Version 2’s new features include:
- Multiple message flows
- Processor nodes
- Publish and subscribe
- Extensible Markup Language support
- Graphical Control Center
- Improved performance.
The setup consists of a two-step process that requires the installation of the MQSeries Java client libraries and the creation of a user ID.
The Java client libraries are only necessary if you’re going to install the MQSeries Integrator Control Center, which provides the ability to define and manage broker domains as well as create and define messages and their message flows.
The user ID is used during the DB2 installation portion of the setup. The broker and configuration manager components use a relational database for caching and storing internal control information.
Once these two items are taken care of, the product takes about 20 minutes to install. After the installation, the setup is just as smooth. I created three DB2 databases with their respective Open Database Connectivity connections using the DB2 SmartGuide, the step-by-step, point-and-click process provided to establish the database and ODBC connections.
It’s a good idea to keep track of the user IDs, passwords, database names, and ODBC connections created throughout the process as these are needed to create the broker domains.
To establish a broker domain, you must enable the configuration manager and the broker. The configuration manager is used for establishing and maintaining the broker domain. The latter is where you define the brokers and the resources they manage, such as messages and message flows. The configuration manager is also responsible for storing and maintaining this information as well as sending updates to the brokers in its domain.
The broker is the heart of the system. It processes the messages that arrive in its queues and performs the tasks that have been defined using the control center. Each broker must have a queue manager installed on its server.
The configuration manager and broker are created using the MQSeries Integrator command assistant. This process also uses a graphical user interface to lead you through the process of creating these objects. Simple forms are presented to the user to fill in the data necessary for the process. At this point, you will need the DB2 database names created in the previous step. You will also need to provide a name for an MQSeries queue manager.
A command-line interface is available, but the command assistant GUI is easier to use.
In the first release of MQSeries Integrator, functionality relied on message descriptions and routing rules: a simple “message broker” configuration. Version 2 offers substantially more features that, in some instances, will replace the need for application programs altogether.
Message flows are at the heart of the new version of MQSeries integration processing. A message flow is comprised of processing nodes that perform actions on or use message elements for processing application tasks. Think of a processing node as an intermediate step an MQSeries message passes through on its way to its final destination. While in a processing node, the message can be transformed into another format, augmented with data, broken down into several messages, or inserted into a relational database.
A node might look up the current price for a part in a database and add that price to the original message content to be sent to a billing department for invoicing purposes.
The control center provides the ability to drag and drop message-processing nodes onto a message-flow palette for the purpose of wiring them together to produce the desired output. Several message-processing nodes are supplied with the MQSeries Integrator version 2 base product. These nodes cover most of the functions needed for complex business integration.
Each node has a set of terminals that lets users easily wire inputs and outputs together. A terminal is an action point either coming in to or going out from the processing node. These terminals have well-defined functions that allow the handling of true, false, and unknown conditions, and provide the ability to route errors and trace data to specified destinations such as an output file.
The output, or message, from one node is the input to another. It’s not much different than Cobol subroutines or C functions passing data and parameters back and forth.
Multiple message flows can be assigned to one broker, letting administrators balance workload throughout the domain and make the best possible use of their computing resources.
The publish and subscribe functionality supports static and dynamic subscriptions. A dynamic subscription lets the user subscribe to predefined types of data programmatically. Given the proper permissions, users can establish, alter, and remove their subscriptions without an administrator. For instance, an application could create a subscription to receive messages about stock price changes for a given stock symbol. This data could be used to produce a stock trend report at regular intervals.
Static subscriptions let system administrators establish these subscriptions and the destinations of the data. Dynamic subscriptions are accomplished using Pub/Sub control messages to the broker without the need for preregistration.
MQSeries Integrator version 2 also supports XML, a way of defining the layout of data using self-defined tags. An element in XML has a start tag and an end tag. XML elements can be defined in a hierarchical manner, much like a database.
Before XML, systems architects and programmers had to define the formats of the data to be sent to and from their programs and systems. Each time a message format changed, all of the programs using that format had to change also. With XML, you define the message once and users only need to access the data that interests them. If changes are made, only users interested in the new elements will need to modify their programs to access them.
XML is supported in MQSeries Integrator for input and output message types. Integrator also uses XML messages to control its internal workings. Export files that contain message descriptions, message flows, and topology layouts are exported to files using XML.
XML is often incorrectly thought of as a replacement for message queuing. XML is the content of a message, while message queuing is the ability to reliably deliver that message content to the desired destination.
One nice feature of the XML support is that message descriptions don’t need to be supplied in order to utilize or interrogate a message element. For example, let’s say we have an XML message for a new product order. It includes the customer name, sales representative, and order details. The syntax to represent that code is cumbersome.
Say we have a product ordering application and wanted to apply a 10% discount on orders that contain more than one item. In a filter or compute node, we could look at and calculate the price for all items in the order and then reference the “totalitem” element of the XML message as simply as this: if Body.Message.neworder.totals.totalitems > ‘2’.
The above example is a simple reference to an element of an XML message. However, it accurately depicts the simplicity of the syntax needed to parse and access XML elements and associated data. This same syntax would be used to access the product ID and price for each item ordered.
Enterprise integrators should find MQSeries Integrator version 2 to be a much enhanced product, and developers should realize the benefits of faster implementation, reduced infrastructure maintenance, and simplified business logic.