The inter-application messaging market, dominated for several years now by IBM's MQ Series, is being shaken up by the larger IT upheavals of e-business integration, along with the associated emergence of XML and Java based approaches. When the dust has settled, it is likely that these different strands will be united within a unified product set available from single suppliers. Such products will also bring together the currently disparate worlds of batch and real time messaging within a single management umbrella.
The most coherent subdivision of the whole integration field is into three layers. Messaging comes in the middle, providing the means of transporting messages between processes, points, or applications. We are talking here of high level messages that convey instructions for some form of execution, and may or may not require a response, rather than low level data transmission, which is the function of the bottom integration layer. This lower layer, sometimes called the connectivity layer, defines how applications that may reside on different applications exchange information at the level of data fields or documents above the basic physical plumbing, and ensures that necessary format translation takes place. XML comes in this layer, and so requires extension to provide full application level messaging - more of this later.
Then the topmost of our three layers, sometimes referred to as the integration broker, manages the overall integration between multiple processes, providing the map of relationships between the relevant applications and systems. This could be within an e-commerce application to manage the integration between Web servers and back end systems, or an even more complex B2B environment.
This top layer is particularly important in the context of messaging evolution, because many of the suppliers are subsuming it into their messaging products. Indeed, IBM has done this to some extent with MQ Series Integrator. 'This is a classical message broker, providing routing and data transformation,' said IBM's worldwide technical strategist for MQ Series Peter Niblett.
However, MQ Series Integrator does not provide all the management services needed to keep track of message flows in complex networks with many interfaces. This has led many smaller businesses in particular to spurn MQ Series in favour of some of the new wave message related products. For example, the e-business integration company eCredible recently ditched MQ Series and replaced it with software from Web Methods. 'It was easier to install, and certainly for the kind of clients we deal with, flexibility and ease of configuration is a factor,' said eCredible's director of sales and business development Robert Wilson.
Only viable choice
Gartner's senior analyst for middleware Deborah Hess suggested that MQ Series is now the only viable choice for large enterprises wanting to integrate Web servers with legacy back end systems. Yet the most excitement, said Hess, was being generated by the two other main courses of messaging, XML, and Java. XML alone is merely a data description protocol, and to give it messaging capabilities, the Soap (Simple Object Access Protocol) has been developed. 'With Soap, you have simplicity and don't need to put a lot of work in up front, but there is a lack of security, and no follow up or guaranteed delivery as you get with MQ Series,' said Hess. The great attraction of Soap though, is that being based on XML, it is the first open supplier-independent messaging platform. Such at least is the theory. The reality is a little different in that XML is becoming suspiciously like Unix, in having multiple versions and therefore creating new supplier dependencies. Still, if Soap can bridge between the versions, it may achieve its goal. Certainly Microsoft is betting on it, preferring for commercial and religious reasons not to back the Java or MQ Series alternatives too strongly. At present Microsoft has its Message Queue (MSMQ) technology, which is nothing to do with Soap. But as Hess noted, MSMQ will have to be rewritten to conform withMicrosoft's.net strategy, whenever that condenses from the vapour, and then Soap will figure prominently.
The third messaging dimension comes with Java, with JMS (Java Messaging Service). The attraction here is Java's pervasiveness for Web applications and its ability to run on almost any platform. JMS itself is just an interface specification providing a framework for different Java based messaging applications. MQ Series by contrast is a complete product supporting message delivery and transformation out of the box. In addition, MQ Series is always asynchronous in that the message is delivered without waiting for a result to be returned, although there may be an acknowledgement. Java based messaging systems on the other hand may be synchronous, supporting tightly coupled processes whereby a request is sent, say from a client PC to a Web server, and after execution of the process a reply is returned to the client.
Hess suggests that future messaging systems will combine the security, robustness and support for all conceivable legacy interfaces of MQ Series, the simplicity of Soap/XML, and the multi-platform and tight coupling of Java systems. In fact, IBM itself seems to be heading this way, having introduced XML support within MQ Series in 1999 to provide a migration towards XML, and having been involved intimately in the definition of JMS. So although JMS is radically different in form from MQ Series, it inherits some of its well-proven robustness.
The most significant Java related messaging development has just occurred with the release of version 2.0 of EJB (Enterprise Java Beans). 'This allows you to write a bean that is triggered by a message,' said Niblett. This makes it easier to develop server code that orchestrates all the processes that need to be performed upon the receipt of a message.
There is still work to be done in the top management layer of integration, or integration broker, that we defined earlier, as products like MQ Series Integrator only do part of the job. There are third products that go further, an example being MQ Accelerator from ETI. 'This tackles the fundamental problem many enterprises have encountered as they consolidate their systems, in amassing complex multiple interfaces between sources and targets, needing substantial hand coding around MQ Series. So now they have to maintain a whole bunch of interfaces,' said ETI's cto and vp of development David Marshall.
Market shares and leading products
According to Gartner, MQ Series has 70 per cent of the overall messaging market. Number two is Tibco, which has grown rapidly in the market for high speed transactions in the financial arena and other industry sectors such as telecoms that need support for reliable real time processes. But the field has been distorted by the emergence of other branches of middleware with messaging components. Indeed, Tibco is really in the market for high-level integration brokers fitting into the top layer of integration defined in the feature. In this top layer where messaging is often a bundled component, there is no single dominant player according to Gartner, but among the leaders are IBM, Tibco, Web Methods, CrossWorlds Software, and in Europe, Software AG. These companies all need to be considered in the context of messaging, which is no longer a stand-alone option but is part of the overall integration picture.
The other contenders include Microsoft's Message Queue (MSMQ), JMS (Java Message Service), and Soap (Simple Object Access Protocol). Soap is for the future, while MSMQ will soon be history if .net ever gets off the ground. JMS is already gaining ground, having largely taken over from Corba (Common Object Request Broker Architecture), whose functions it largely subsumes.