Enterprise applications Toolkit

All aboard! The enterprise service bus pulls in

David Berlind ZDNet.com

Published: 29 Jul 2004 11:45 BST

For those ready to embrace the idea, another issue remains. Just because you can get discreet software components and systems talking directly to each other doesn't mean you should. For transactional systems engaging in millions of transactions a day -- transactions of different types and priorities that need to integrate with different systems -- it's not as simple as just spitting those transactions out onto a TCP/IP network as fast as you can and crossing your fingers. Nor is it as simple as just turning the receiving system's ear to the network and hanging an "Open for XML requests" sign on the window. You can do both, but, depending on your situation, it could be an invitation to mayhem. Imagine thousands of unruly people storming the turnstiles at a soccer match. The aftermath isn't pretty. TCP/IP as a network simply doesn't have enough built-in facilities for managing the integrity of business-critical transactions that need to take place according to priority in a reliable, secure, and often a choreographed fashion.

As it turns out, taming such mayhem has nothing to do with XML or Web services. To the extent that people have been integrating systems for over a decade, usually via proprietary methods, it's been an issue that integrators have been dealing with, regardless of the data or networking protocols. To bring order to chaos, the answer has invariably been the insertion of message queues as a layer of abstraction between integrated systems.

Although the metaphor is a bit of an oversimplification, message queues such as IBM's WebSphereMQ do for integration what orderly queues do for getting spectators safely in and out of a soccer match, worrying about issues such as guaranteed delivery that protocols such as TCP and UDP can't map to the transactions that are taking place at a fairly high layer in the protocol stack.

In the spirit of cost reduction, message queues also have another benefit. In typical intermediary fashion, message queues allow the host systems (to which the queues are adjacent) to focus on spitting out transactions while the queue is the proxy that worries about the business logic of what to do with them, such as prioritisation and routing. From an ongoing maintenance point of view, such separation of duties reduces the complexity of having the transaction logic intermingled with business logic. The generally accepted rule of TCO is "less complexity, less cost".