Connecting A to B—XML and MQ
Anyone who's traveled overseas will appreciate the importance of finding the right adapter. Faced with two disparate (yet conceptually compatible) systems, the value of finding the right attachment to match prong type "A" into socket type "B" easily exceeds the value of the adapter itself! In software terms, there are many tools, standards and technologies designed specifically to bridge disparate systems, allowing them to work together to accomplish a common goal.
| Each of these technologies start with a client or programmer's toolkit to mold some kind of data into a standardized format. |
The key to successful middleware is its breadth of support: In order for a given tool to be effective, it must be usable on all the platforms and application environments we seek to combine. Both XML and MQSeries are of particular interest when integrating two systems because of the dramatic range of platform, operating system and development environment support they exhibit.
Each of these technologies starts with a client or programmer's toolkit designed to mold some kind of data into a standardized format. This data may be a collection of values input by a Web browser or data-entry operator, a transactional record generated by a procurement application, or perhaps a ten-thousand row data set resulting from an analytical query. Regardless of the data's origin, the fundamental desire is to allow that information to be transferred into whatever monolithic system or application component requires it for continued useful processing. By using compatible toolkits on otherwise incompatible platforms, it becomes possible to build a multitiered environment where tasks can be delegated, refined or replaced without adversely impacting the continued operation of the whole process.
For example, MQSeries might be used for coordination between two systems as part of a workflow process. Consider an existing rating/billing system where each client transaction (phone call, toll route use, pay-per-view purchase, etc.) goes through several steps before a definite price can be assigned to the transaction. Suppose the user of such a billing system wished to integrate it with a new Web-based promotions system being implemented across the company's product lines where each transaction may be subject to a discount based on prior purchases or a current sale.
Rather than coding the logic to test and handle a potential discount as part of the existing application, the developer might instead use MQSeries to send each transaction to an alternate server responsible for performing this task. Such a server might be running a Java application which uses the standard Java message queuing tools (JMS) to read each transaction, accesses the client's promotional profile from an EJB server (which is shared by many related applications), and updates the transaction record as appropriate, requeuing it for delivery back to the original application. Upon receiving the revised transactional record, the old system picks up where it left off, ultimately producing hardcopy invoices for mailing to the client.
MQSeries and XML may represent alternate or cooperative technologies. While MQSeries is primarily concerned with transport, XML is concerned strictly with data representation. MQSeries will happily deliver messages in any user-defined format. Similarly, an XML-formatted dataset may be transferred using any number of protocols, from HTTP and FTP to direct file access, even by using MQSeries itself as a transport mechanism. This kind of flexibility and interoperability is what makes these technologies so useful in building modern applications and merging the old with the new.
Mark Buchner is president of Astech Solutions (Aurora, Ontario). mbuchner@astech.com
Related Editorial:
Extending Your Client Base With XML