The State of Middleware

Java Messaging, adapters gain momentum

By SD Times News Team

January 15, 2002 —

By Andrew Binstock

Messaging middleware has undergone a stunning transformation in perception during the past five years. In the mid-1990s, middleware was still viewed very much as the province of mainframe shops that needed a plumbing layer to provide messaging between the back-room big iron and front-end applications.

This perception was furthered by the dominant role of IBM Corp.'s MQSeries middleware, which undeniably started out as a mainframe messaging layer. With the advent of Web technologies, companies discovered that the most significant impact on their enterprise infrastructure was the abrupt and radical shift to distributed architectures. The once-standard client/server model of multiple clients feeding into a business-logic server that spoke with several back-end databases was completely shattered.

In its place, a legion of dedicated, stand-alone servers took over transaction processing as a series of disjointed activities. For example, the modern enterprise with a Web presence now must support Web servers, firewalls, authentication and encryption servers, application servers, database servers and perhaps EAI servers and ERP systems. To these may well be added directory servers, WAP servers, file servers and more. The bottom line is that enterprises today are forced to deal with moving data at high speeds among a widely distributed set of servers that need to understand one another's data. Enter messaging middleware.

Suddenly, after years of rendering rock-solid service in quiet obscurity, middleware is hot and can be divided roughly into two camps: Java-based middleware and everything else.

JMS: COMING ON STRONG As of last year, the big news was the impending widespread adoption of the Java Message Service (JMS), which was expected to drive down prices as various vendors started shipping competing implementations. In addition, JMS would do away with the single biggest problem in messaging middleware: its tendency to lock customer sites into one product's API. Customers who chose one vendor's solution were locked into that product because the customers' applications all had been rewritten to use the middleware APIs. By being forced to standardize on the JMS APIs, middleware vendors would now compete purely on implementation, and dissatisfied customers could with some effort swap in a better product without having to change their codebases.

Today, it is clear that JMS delivered on these promises, as good JMS implementations can be bought at prices unimaginable just a few years ago. In fact, there are several free versions of JMS available, both commercial and open source. When you take that into account, middleware has never been less expensive.

JMS also cracked open the API issue. All middleware vendors as of late 2001 have JMS APIs associated with their products. The last major vendor to succumb was TIBCO Software Inc. (www.tibco.com), which only just released its JMS implementation. At mid-year, IBM released WebSphere 4.0, which was its first certifiably approved J2EE implementation; this version included a JMS implementation consisting of JMS wrappers around an MQSeries core. In fact, IBM is currently renaming MQSeries as WebSphere MQ.

The high hopes placed on JMS tempted numerous vendors to enter the market with stand-alone products. The two most visible vendors were Sonic Software Corp. (

), which only just released its JMS implementation. At mid-year, IBM released WebSphere 4.0, which was its first certifiably approved J2EE implementation; this version included a JMS implementation consisting of JMS wrappers around an MQSeries core. In fact, IBM is currently renaming MQSeries as WebSphere MQ.

The high hopes placed on JMS tempted numerous vendors to enter the market with stand-alone products. The two most visible vendors were Sonic Software Corp. (www.sonicsoftware.com) and Fiorano Software Inc. A year ago, these two companies battled each other relentlessly with claims of performance supremacy, allegations of benchmark dishonesty and other intriguing accusations. This hissing match died out eventually as it became clear that other vendors entering the market also had fast implementations of JMS technology.

What ultimately sobered both brawlers was the stark realization that even though JMS was in fact delivering everything it promised, the market for stand-alone JMS products simply was never going to appear.

Instead, existing middleware vendors added JMS interfaces to their products when pressured by their customers, and lowered the prices as needed to close sales. JMS became a check-list item in a series of needed features, rather than a stand-alone product.

Certainly, few IT sites tore out existing middleware to install JMS. Stand-alone JMS implementations did have one hope, however, because the middleware market continues to labor in the shadow of one very strange aspect: The biggest installed competitor to any new middleware product is what is affectionately called "home-grown" solutions.

In fact, middleware vendors informally estimate that one-third to one-half of all sites with middleware today use products that were developed in-house-generally in response to a small problem, from which it slowly permeated all applications in the company. On the surface, this factor would seem to provide JMS-specific vendors with an opportunity. But in fact, this has not been the case. Large corporations that have been replacing home-grown solutions have first turned to established large-scale messaging products. Meaning they have turned to the market leader, IBM's MQSeries, which by some estimates (such as those from Wintergreen Research Inc.) show the company with as much as 75 percent market share.

Fiorano (

) and Fiorano Software Inc. A year ago, these two companies battled each other relentlessly with claims of performance supremacy, allegations of benchmark dishonesty and other intriguing accusations. This hissing match died out eventually as it became clear that other vendors entering the market also had fast implementations of JMS technology.

What ultimately sobered both brawlers was the stark realization that even though JMS was in fact delivering everything it promised, the market for stand-alone JMS products simply was never going to appear.

Instead, existing middleware vendors added JMS interfaces to their products when pressured by their customers, and lowered the prices as needed to close sales. JMS became a check-list item in a series of needed features, rather than a stand-alone product.

Certainly, few IT sites tore out existing middleware to install JMS. Stand-alone JMS implementations did have one hope, however, because the middleware market continues to labor in the shadow of one very strange aspect: The biggest installed competitor to any new middleware product is what is affectionately called "home-grown" solutions.

In fact, middleware vendors informally estimate that one-third to one-half of all sites with middleware today use products that were developed in-house-generally in response to a small problem, from which it slowly permeated all applications in the company. On the surface, this factor would seem to provide JMS-specific vendors with an opportunity. But in fact, this has not been the case. Large corporations that have been replacing home-grown solutions have first turned to established large-scale messaging products. Meaning they have turned to the market leader, IBM's MQSeries, which by some estimates (such as those from Wintergreen Research Inc.) show the company with as much as 75 percent market share.

Fiorano (www.fiorano.com) and Sonic simply don't have the marketing oomph to either get the lead for the sale or to credibly go up against IBM when they get it. As a result, they are forced into other byways, such as special projects that require an ad hoc middleware solution. This includes the Sabre airlines reservation project, which uses Sonic's JMS and the JNET Criminal Tracking system, developed by the Pennsylvania Department of Justice, which uses Fiorano's product.

Other middleware companies such as Talarian Corp. (

) and Sonic simply don't have the marketing oomph to either get the lead for the sale or to credibly go up against IBM when they get it. As a result, they are forced into other byways, such as special projects that require an ad hoc middleware solution. This includes the Sabre airlines reservation project, which uses Sonic's JMS and the JNET Criminal Tracking system, developed by the Pennsylvania Department of Justice, which uses Fiorano's product.

Other middleware companies such as Talarian Corp. (www.talarian.com) likewise bet heavily on JMS. Talarian, which is known for very high-speed messaging used in defense and financial services markets, shipped two different JMS products built around its existing SmartSockets software. This performance emphasis, however, did not translate into significant new sales. The company is likely to return to its original middleware products and develop these, rather than continue pursuing the stand-alone JMS market.

TIBCO's JMS middleware was released only late in 2001. TIBCO got the story right. JMS was not going to make or break the company, and there was no pressure to come up with a JMS product for the sake of having one. TIBCO's then head of marketing, Fred Meyer (now chief strategy officer), articulated this view in February 2001 and stuck to it with no apparent downside.

EVERYTHING ELSE The company that loves to hate all acronyms that start with "J," Microsoft Corp., has steadily been pushing its messaging strategy. A long time ago, Microsoft's MSMQ middleware product was sold as a separate product in its BackOffice software suite. Today, its client MSMQ software ships in every version of Microsoft's Windows from Windows CE to XP. In fact, with the release of Windows XP, Microsoft unveiled MSMQ 3.0. According to the company, the new version offers two new types of messaging: one-to-many and messaging over the Internet. That these features appear only now underscores the strength and weakness of MSMQ: Its strength is it's simple and universal; its weakness is it's simple-meaning it doesn't have the feature set or the track record necessary for true enterprise-scale messaging.

Dave Wascha, Microsoft's product manager for BizTalk Server, observed that enterprises are decreasingly interested with messaging solutions that require programmer action to work.

Wascha related a story of an unnamed customer: "Their developers were delighted to hook up core applications with the new CRM package in just five weeks. Unfortunately, in many of today's enterprises, this just won't work; when you consider that same CRM system might have to hook to ERP applications, databases elsewhere in the enterprise and a variety of other kinds of software, you can't lose five weeks from top programmers with every application that needs to talk to the CRM software."

Of course, he's right. Middleware's fundamental flaw is that it does not abstract to a higher level. As Mike Foody, the founder of Actional Corp. and currently CEO of Venture Imperatives, pointed out, "It's true. Everyone would love a plug-and-play solution such as Microsoft is touting with BizTalk. The trouble is, that's a pipe dream. The work of integrating applications through messaging is difficult and cannot be raised significantly above a programming level, even with the best of wizards. Consider for example, [Amdocs Ltd.'s] Clarify's CRM product: It has three separate APIs, and still you have to work hard within these to get done what you need. There is no way to get around these problems, except at the code level."

Obviously, today's fascination with Web services has certain echoes here, but as yet, echoes only. Consistent with Foody's perspective is the fact that adapters are today's most active segment in the gamut of products termed middleware.

ADAPTERS This segment of the market deals with the software that sits between two applications and converts data from one application's format to the other. Adapters are an integral part of EAI and an increasingly central part of middleware at the messaging layer. As large software companies position themselves to be enterprise players, the quality of adapters is emerging as a key asset.

Consider, for example, that in October 2001, IBM began the acquisition of CrossWorlds Software Inc., for $129 million, in what many analysts agree was primarily a quest to gain ownership of the company's adapters. Companies like webMethods Inc. (

) likewise bet heavily on JMS. Talarian, which is known for very high-speed messaging used in defense and financial services markets, shipped two different JMS products built around its existing SmartSockets software. This performance emphasis, however, did not translate into significant new sales. The company is likely to return to its original middleware products and develop these, rather than continue pursuing the stand-alone JMS market.

TIBCO's JMS middleware was released only late in 2001. TIBCO got the story right. JMS was not going to make or break the company, and there was no pressure to come up with a JMS product for the sake of having one. TIBCO's then head of marketing, Fred Meyer (now chief strategy officer), articulated this view in February 2001 and stuck to it with no apparent downside.

EVERYTHING ELSE The company that loves to hate all acronyms that start with "J," Microsoft Corp., has steadily been pushing its messaging strategy. A long time ago, Microsoft's MSMQ middleware product was sold as a separate product in its BackOffice software suite. Today, its client MSMQ software ships in every version of Microsoft's Windows from Windows CE to XP. In fact, with the release of Windows XP, Microsoft unveiled MSMQ 3.0. According to the company, the new version offers two new types of messaging: one-to-many and messaging over the Internet. That these features appear only now underscores the strength and weakness of MSMQ: Its strength is it's simple and universal; its weakness is it's simple-meaning it doesn't have the feature set or the track record necessary for true enterprise-scale messaging.

Dave Wascha, Microsoft's product manager for BizTalk Server, observed that enterprises are decreasingly interested with messaging solutions that require programmer action to work.

Wascha related a story of an unnamed customer: "Their developers were delighted to hook up core applications with the new CRM package in just five weeks. Unfortunately, in many of today's enterprises, this just won't work; when you consider that same CRM system might have to hook to ERP applications, databases elsewhere in the enterprise and a variety of other kinds of software, you can't lose five weeks from top programmers with every application that needs to talk to the CRM software."

Of course, he's right. Middleware's fundamental flaw is that it does not abstract to a higher level. As Mike Foody, the founder of Actional Corp. and currently CEO of Venture Imperatives, pointed out, "It's true. Everyone would love a plug-and-play solution such as Microsoft is touting with BizTalk. The trouble is, that's a pipe dream. The work of integrating applications through messaging is difficult and cannot be raised significantly above a programming level, even with the best of wizards. Consider for example, [Amdocs Ltd.'s] Clarify's CRM product: It has three separate APIs, and still you have to work hard within these to get done what you need. There is no way to get around these problems, except at the code level."

Obviously, today's fascination with Web services has certain echoes here, but as yet, echoes only. Consistent with Foody's perspective is the fact that adapters are today's most active segment in the gamut of products termed middleware.

ADAPTERS This segment of the market deals with the software that sits between two applications and converts data from one application's format to the other. Adapters are an integral part of EAI and an increasingly central part of middleware at the messaging layer. As large software companies position themselves to be enterprise players, the quality of adapters is emerging as a key asset.

Consider, for example, that in October 2001, IBM began the acquisition of CrossWorlds Software Inc., for $129 million, in what many analysts agree was primarily a quest to gain ownership of the company's adapters. Companies like webMethods Inc. (www.webmethods.com) and other B-to-B vendors that have written their own adapters are facing terrific competition on the basis of performance and scalability, and the heart of their problem is the adapter's performance-which is why good adapters are in such demand: They can make or break a product.

One company that has specialized in adapter performance is Actional (

) and other B-to-B vendors that have written their own adapters are facing terrific competition on the basis of performance and scalability, and the heart of their problem is the adapter's performance-which is why good adapters are in such demand: They can make or break a product.

One company that has specialized in adapter performance is Actional (www.actional.com). The company markets adapters that run as native modules on each of the two applications they're linking. As a result, they can do more than the usual transaction and data conversion; they can represent each application to the other as a native module on the network and talk the native language.

This is in clear contrast to typical solutions in this space that use an EAI model, whereby a central server has spokes that connect to every application. The server has an adapter convert the incoming data into a metaformat, then an outgoing adapter converts it into the format of the target system. This means that a data item making a round trip from server A to B is subject to four conversions. Do that on every database transaction and performance will acquire an entirely abstract meaning.

The adapter market is on the verge of moving to a standard API in much the same way JMS unified the messaging market. Sun and the Java Community Process released the Java Connector Architecture in mid-2001 as part of J2EE v. 1.3. (Note: The Java Connector Architecture is not the same as JCA, which is the official acronym for the Java Cryptography Architecture.)

Many analysts believe the Java Connector Architecture will become a universal interface for access not only like JMS, but more in the mold of ODBC and its universal database interface. And like ODBC, it will rarely represent the fastest form of access. Right now, the specification lacks key features such as asynchronous operation, but a 2.0 version of the draft is actively under way.

In the area of adapters, Microsoft's BizTalk Server 2000, one of the early cornerstones of the company's XML initiative, uses a variety of technologies to push data through its large array of connectors and adapters. It uses XML schemas and runs them over HTTP, which allows them to be used in tightly coupled and loosely coupled contexts. Use of HTTP gives the product a ubiquitous transport layer for sites that don't run BizTalk's native messaging layer, MSMQ.

Quite separately, BizTalk supports EDI, which remains one of the few application-specific messaging protocols in widespread use. As usual, last year's predictions that XML would rid the world of EDI were way too aggressive. Infrastructure technologies turn over very slowly. Which is why after all these years, in the world of messaging, MQSeries is still the boss.

Share this link: http://www.sdtimes.com/link/26271

Growth seen in application middleware The world market for middleware grew by 13% last year, according to Gartner. Demand for service-oriented architecture and advances in middleware technology are seen as the two biggest contributors to the growth.

Fuse ESB 4.0 is first open-source product since Iona purchase Progress considers the Fuse ESB to be a "battle-hardened" version of Apache ServiceMix. The company is building up a development community around Fuse and is including a set of graphical icons to aid programmers in coming up with integration solutions.

Still no release date set for Oracle Fusion Applications With Oracle OpenWorld going on, the company declined to state when it expects its middleware product to become available. Analysts have ideas as to why the delays persist and how its development affects the company.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST