Let's take each of these components in turn:

• MQSeries Message-Oriented-Middleware
  With over 50% market share, and the widest product platform coverage, MQSeries is the de facto standard for message oriented middleware. MQSeries has achieved popularity with customers because it enables you to develop applications that deal with messages and queues through a common API and it frees you from needing to worry about the underlying operating system or network.
  
  MQSeries is ideally suited to high value message handling and high volume applications because it guarantees once only message delivery and it supports transactional messaging. This means that messages are grouped into ‘units of work’; either all of the messages in a unit of work are processed, or none of them. MQSeries can also coordinate message work with other transactional work, like database updates, so that data integrity is always maintained.
  
  Usually, when two applications exchange messages, they are the only ones that know about the format of the data in the message. For instance, a message exchanged between two applications may contain a name followed by an address field, separated by a special character, like a ‘#’. A third application may be interested in the name and address information, but expects its data to arrive in a message with two fields - a name field that’s one hundred characters long (padded with spaces if the name is less than one hundred characters) and an address field that’s five hundred characters long (again padded with spaces to the maximum length).
  
  Normally the message exchanged by the first two applications wouldn’t make any sense to the third application, unless some extra code was written to transform the message into the expected format. In this case it would be fairly simple, but real life is seldom so easy!
  

  The problem gets worse as you try to connect more and more applications: Because you build point-to-point links between pairs of applications and each end of a link needs to know about the other’s message formats, a change to one application is likely to impact many others. This type of solution has built-in inflexibility and a high cost of maintenance and we characterise it as “inter-application spaghetti”. Obviously not a desirable situation!

  

  This is where the Formatter* for MQSeries Integrator offers a leap ahead.

• Formatter* for MQSeries Integrator
  Formatter* for MQSeries Integrator - Formatter for short - is capable of understanding the formats of all messages being passed between applications. Even better, it’s able to convert between formats: Data from one message can be restructured into a new message, so it will make sense to another application. You can think of the Formatter as a universal dictionary, that understands how each application ‘talks’ and knows which pieces of information are useful to each application.
  

  Formatter is able to understand message formats because it has a set of powerful parsing and pattern matching methods that can be combined to describe the structure of virtually any message format. Message formats are built up from component pieces that identify each field within the message. Once a message has been described in terms of its components, the fields can be recombined to create new messages.
  
  Formatter can handle virtually any message format, including fixed format (e.g. COBOL records), delimited format (e.g. C null delimited strings), variable formats and tagged, delimited, repetitive and recursive formats (e.g. S.W.I.F.T. type messages).
  
  The Formatter can be invoked through a simple Application Programming Interface (API), that allows you to parse a message and retrieve individual fields by name, or by ‘walking’ along the message, looking at each field in sequence. Once a message has been parsed, it can be transformed into a new output format by calling another Formatter API function.
  
  Defining the message formats in the Formatter’s database is easy because MQSeries Integrator provides a Graphical User Interface (GUI) that leads you through the definitions of format components, like tags, delimiters and patterns, to the building of complete message definitions.
  
  Formatter stores the message format information in a relational database so it can leverage the power of the database engine to make storage and retrieval of the data fast and reliable. Using standard database technology, the message format information can be distributed around the enterprise thereby making its management more centralised.
  
  Rules* for MQSeries Integrator. The last section described how Formatter gives you the ability to translate between the different message formats used by your applications. Rules* for MQSeries Integrator (or just Rules) builds on the power of translation by allowing you to implement intelligent message routing and transformation.
  
  In the simplest case, a certain message may be required by only one receiving application. A more complex case is where the message is required by two, or more, receiving applications. To cover any scenario you need be able to route a message to any number of receiving applications. Remember too, that each receiving application will expect its message in a different format. To implement a truly flexible solution, you need the capability to make these formatting and routing decisions dynamically, based on the actual data in each message. MQSeriesIntegrator Rules, combined with Formatter, makes this possible.
  
  Rules allows you to define transformation and routing decisions based on the format and content of a message. Like the Formatter definitions, Rules definitions are stored in a relational database for high performance access and easy administration. Defining rules is simple because MQSeries Integrator provides a GUI front-end that leads you through their definition. (We’ll use a convention in this document that refers to the MQSeries Integrator component as ‘Rules’ - with a capital ‘R’, and the definitions that determine message routing and formatting decisions as ‘rules’ - with a lowercase ‘r’).
  
  A rule is associated with an input message format and consists of tests defined in terms of message fields and values. Fields can be evaluated for presence, equal, not equal, greater than, less than, greater than or equal, less than or equal. Tests are combined with ANDs and ORs to create rules. Associated with each rule are a number of actions, which are to be performed if the rule evaluates to true. There is no architectural limit to the number of tests that can be combined in a rule or the number of rules that can be defined.
  
  An example of a rule might implement logic to say:

  If this message is a payment, and the currency is US dollars and the amount is greater then $100,000, or the currency is Canadian dollars and the amount is greater than $140,000, then inform the domestic audit department of the customer name, account number, currency and value.

  With Rules’ intelligent routing and transformation of data, you can implement message flows between applications that match the data flows required by your business processes. MQSeries Integrator can keep up with the pace of change in your business requirements because the configuration is centralised, and when changes are necessary they affect MQSeries Integrator and not the applications.
  
  MQSeries Integrator also means that you can integrate legacy applications with new package applications because the applications don’t need to be modified to update the messages they send and receive - all of that information is defined within MQSeries Integrator. Adding a new application, and routing the data it requires is easy, because it only means an update to the rules for the relevant input messages and the definition of the output message formats expected by the new application. All the other applications are completely unchanged, so code disruption is eliminated and testing is minimised.

• MQSeries Integrator Daemon
  MQSeries and MQSeries Integrator Rules and Formatter are powerful tools in their own right. To allow organisations to put MQSeries Integrator to use immediately, without having to write any code, MQSeries Integrator includes a daemon, which combines these three components in a generic server process.
  
  The MQSeries Integrator daemon processes messages from an MQSeries input queue, uses Formatter to parse the messages and Rules to decide what transformations to perform and where to route the messages, then puts the output messages on MQSeries queues for delivery to applications.
  

Implementation Considerations

• Pervasiveness
  As we mentioned in the introduction, MQSeries has the widest product platform coverage of any message-oriented-middleware in the market. MQSeries Integrator is available on five operating systems with four different databases (see the Appendix) and because MQSeries Integrator uses MQSeries messaging, applications that need to make use of MQSeries Integrator’s intelligent routing and transformation capabilities can run on any one of over twenty five operating systems, including Java.

• Scaleability
  The implementation of an intelligent routing architecture with MQSeries Integrator is very flexible: You may decide to run one system as a dedicated hub with an MQSeries queue manager and a daemon processes to handles all message routing and transformation. Each application sends its messages to the daemon’s input queue and the daemon, using Rules and Formatter, routes messages on to the appropriate receiving applications.

  In a larger implementation, or a more complex architecture, you may decide to run a large server system as the intelligent routing hub, with several daemon processes to handle the message throughput. As message volumes increase, the routing workload can be shared across several systems, each with a queue manager and one or more daemon processes.

• Manageability
  MQSeries has an associated mature market in systems management products, which allow an entire MQSeries network of queue managers to be administered and monitored centrally. MQSeries Integrator fits into the MQSeries management model because the daemon process can be started by standard MQSeries triggering facilities, and executes as a long-running application process until the queue manager shuts down.

• Security One of the most important aspects for any distributed architecture is security. This becomes especially relevant when the architecture spans not only a single organisations but multiple organisations, as is the case with value chain integration.
  
  Because there are so many varying requirements for security - whether it be access control, data authentication or encryption, or non-repudiation - MQSeries provides a flexible framework, into which you can link security facilities to meet your specific requirements. MQSeries provides exit points, where the appropriate security modules can be invoked. For example, when two queue managers initiate communications, each queue manager can verify the identity of the other, and during message transmission, the entire network data, including protocol information, can be encrypted to prevent unauthorised browsing or insertion of data. MQSeries also provides a security manager (or uses the standard security manager facilities on MVS) to control application access to queue managers and queues.

Where to Find More Information

IBM United Kingdom Ltd.
Hursley Park
Winchester
Hampshire SO21 2JN

http://www.ibm.com/software/ts/mqseries

Appendix: MQSeries Integrator Environments

MQSeries Integrator will be available on the following platforms and databases:

Notes:

1. An ODBC server must be present on MVS
2. A Win NT machine must be available with the appropriate database client for the Rules and Formatter GUIs.

* The Rules and Formatter are developed for IBM by NEON (New Era Of Networks)