Recent interest in Web services has refocused IT’s attention on EAI (enterprise application integration) middleware. In integration projects, no software component is more important than messaging. Every new project poses challenging architectural questions – such as the use of XML and the selection of programming languages – but all successful integration work hinges on a robust and flexible messaging infrastructure.
Within the EAI context, messaging refers to software that packages application data, shoots it across the network, then deciphers it on the other side. For messaging to be of any use in an enterprise setting, it must be able to guarantee that 100 percent of the messages received will be delivered to their destinations. It is that guarantee that makes message-oriented middleware worth the high price typically charged for it.
There are plenty of ways to attack enterprise messaging. Traditionally, you would choose your overall integration platform and accept the messaging layer that came with it. For example, when Windows is the chosen platform, MSMQ (Microsoft Message Queuing) will most likely link applications. The .Net framework gives programmers a new set of APIs for messaging, but the server messaging software stays the same.
IBM Corp. has created what is probably the most popular messaging middleware, MQSeries. Unlike the Windows-only MSMQ, MQSeries runs on everything from desktops to mainframes. MQSeries’ reach is evidenced by the tendency of competing messaging vendors to offer MQSeries connectors. Such connectors either create a bridge between messaging servers or allow developers to use a non-MQSeries API to communicate with an MQSeries server.
Sun Microsystems Inc., a relative newcomer to the messaging space, set a new standard with its JMS (Java Message Service) specification. Using JMS, developers can create message-oriented software without concerning themselves with the vagaries of a specific messaging platform. JMS specifies only the API. JMS-compatible providers supply the actual messaging services, a field that includes IBM, BEA Systems Inc., Progress Software Corp., JBoss, and several other commercial and open source players.
The JMS specification grants developers and IT managers an uncommon degree of flexibility. The developer needs to learn only one API, even if he or she is coding for an environment that employs multiple overlapping messaging systems (which is common). Even a midproject or post-deployment switch, either of which would be unthinkable without JMS, creates little disruption.
JMS is not without its faults. The underlying messaging platform is only transparent until something goes wrong. Debugging serious problems requires a deep understanding of the specific JMS provider. And the use of multiple interconnected providers can make troubleshooting especially difficult because each provider has a unique set of administrative tools. Still, Sun’s approach of separating the API from the messaging layer has changed the EAI landscape for the better.
Tom Yager (tom_yager@infoworld.com) is the technical director of the InfoWorld Test Center.