Can message brokers deliver? - architecture for designing more efficient middleware - includes related glossary, data warehousing article - Technology Information

Software Magazine,  June, 1996  by Julie Bort

• E-mail
• Print
• Link

This middleware design claims to streamline distributed computing by eliminating point-to-point application interfaces

Somewhere between the time the mainframe dominated computing circles and client/server was embraced, IT shops got saddled with a big problem. As networks became distributed, business data ended up in numerous information systems. The problem? These applications couldn't talk to one another.

Rather than ditching mission-critical legacy applications, programmers have relied on middleware, or inter-application interfaces, to connect disparate back ends. However, this middleware, while preserving the investment in legacy systems, has created a crisis of its own.

Most middleware solutions to date have meant someone has to write an interface between every disparate application. The upshot: These point-to-point links have created an IS management mess, dubbed "spaghetti" code because a schematic of the architecture resembles a plate of pasta. Spaghetti code isn't just ugly on paper -- it's a laborious way to build an IT infrastructure.

Typically, links between application systems are individually conceived, and therefore deployed incrementally, according to Roy Schulte, vice president, system software architecture, Gartner Group, Stamford, Conn. This approach results in a complex web of offline and online connections, which are extremely difficult for IS to manage and maintain.

Schulte and other analysts have been pushing what they consider a better way to build middleware -- a planned architecture called a message broker.

A message broker architecture, says Schulte, can make middleware easier to create, manage and scale, while giving applications a level of automation previously unseen. Better yet, the architecture can be implemented while maintaining much of the investment in installed mid- dleware technologies.

"Message brokering is a design approach, rather than a single middleware technology. It might use RPCs, MOMs or TP monitors, but it would use them in a different way than they are traditionally used today," says Schulte, referring to competing messaging technologies.

This approach aims to improve the efficiency of the message delivery system, rather than changing the treatment of the message. Others agree that message brokering may be the answer to efficient, distributed networks.

"This [concept] is very strategic in moving client/server into a truly distributed paradigm. We are encouraging our clients to plan for an 'information-mover infrastructure,'" says Bob Spalding, senior research analyst for the Meta Group, San Francisco. "This offers the ability to provide true application transparency. The historic orientation of middleware is where the rub is. It is synchronous and very, very data-centric."

A message broker, on the other hand, is asynchronous and delivery-centric. This makes it much more user friendly, say early adopters.

"Not only is middleware working, but many people are using it and may not even know it," says message broker user Pierre Pureur, first vice president and technology manager for the Republic National Bank in New York City. "Does it make my life more complicated? Absolutely not. What makes life more complicated is that people refuse to set up an architecture."

Pureur knows first-hand how troublesome the lack of a middleware architecture can be. A few years ago Republic took a look at its middleware strategy and discovered it didn't have one.

"We used to glue systems in all directions. At one point we realized that we had about 70 to 80 systems, which isn't a lot for a $44 billion company. But we had 300 logical processes between them. We knew that if we were to move to client/server on top of that, [the situation] would be made worse," says Pureur.

Pureur has in place a sophisticated message broker that relies on a variety of middleware products, including DECmessageQ from Digital Equipment Corp.

While the term "message broker" smacks of "object request broker," objects are not required. In fact, the underlying technology is more often a message queue, though a message broker can be constructed to deliver realtime messages.

What differentiates a message broker from other types of middleware is its asynchronous nature, allowing one-to-many, many-to-one and many-to-many messaging. Say for example, a customer name and address database has been designated as a meaningful source of information. Each time a name is changed in this database, it could simultaneously send a message to all other databases in the enterprise using this information. Further, all databases may be required to send their designated information to this database.

Many message queuing products can be used in a message broker architecture, but only some offer an innate asynchronous core. One such product is The Information Bus (TIB) from Tibco Inc., Palo Alto, Calif. TIB uses a "publish and subscribe" method that allows any node to both send and receive messages based on content.

Getting a bare-bones message broker architecture up and running is eased by using an asynchronous third-party product, and the result provides great benefit, says TIB user Steve Belmont, manager of strategic programs at Motorola, Tempe, Ariz.