Columns

Messaging Moves Into the Mainstream

• By Michael W. Bucken
• August 21, 2000

By the end of the 1990s, corporate IT organizations were spending huge sums to buy tools that would integrate various applications and extend older but still mission-critical apps. The key technology in the effort: middleware. The ’90s also saw “middleware” become a catch-all phrase for a variety of technologies — such as messaging middleware, remote procedure call (RPC)-based offerings, Component Object Model (COM)-based software, Enterprise JavaBeans (EJBs) and publish-and-subscribe technologies — whose capabilities can be as different as night and day, but which all have some ability to link dissimilar systems. Picking the right technology for the job has become tremendously complicated for even the brightest development manager. And it doesn’t help that some suppliers push middleware technologies to solve problems their technology cannot fix.

The messaging middleware market has been dominated by IBM’s MQSeries and, to a lesser extent, by offerings from Talarian, BEA Systems, Level 8, Microsoft, Tibco and some others. Hurwitz Group Analyst Tyler McDaniel cites the relatively new SonicMQ system from Progress Software as a strong competitor due to its support of the Java Messaging Service (JMS) specification that some see as the first step in a messaging standards process. Though not as widely celebrated as its RPC cousins, and suffering somewhat due to a historical lack of standards, messaging middleware has found a home in a variety of niche environments that need its strong communications facilities. Now observers say messaging is set to become the key technology foundation for distributed e-business systems.

In this issue of Application Development Trends, a trio of experts, Max Grasso, Ed Lyons and Jonathan Venezian, all from consulting firm NetNumina Solutions Inc., Boston, offer a definition of messaging middleware and, as a bonus, define some of the key capabilities of RPC-based systems (see “Getting the message,” p. 21). The authors maintain that messaging middleware together with some RPC-based technologies can be the optimum platform for building distributed systems. Development managers are warned to avoid being swayed by technical religion, and to use the best technology for the project.

This issue also includes some tips for selecting the right testing technologies for complex distributed development projects, another difficult task (see “Testing 1, 2, 17,” p. 47). Freelance writer Johanna Ambrosio notes that the dearth of testing tools for distributed development is changing quickly with the unveiling of several new systems said to be designed for projects such as these. There is some help on the way, she says, though good modeling and design are still the keys to building good software.

Best Regards