Network Computingwww.networkcomputing.com

Our screening of the state of middleware shows Microsoft Corp.'s Distributed Common Object Model (DCOM) and Sun Microsystem's Java may have what it takes to shine on their own. If they don't, however, ongoing consolidation among middleware vendors like BEA Systems and IBM Corp. will continue to provide a strong ensemble cast.

Middleware Casting Calls Application developers tend to view middleware as a particular point solution to an array of isolated application problems. In large part, this is because the current middleware market has been divided into roughly five categories: data access, remote procedure calls (RPCs), message-oriented middleware (MOM), distributed transac tion-processing monitors (DTP monitors) and distributed object technology (object request brokers, or ORBs). Although this taxonomy has proved tremendously useful in sorting out the ill-defined middleware market, it also has prevented middleware from evolving as a unified platform incorporating all these technologies.

Lacking an integrated middleware platform, we've assembled middleware on our networks as applications warranted. Data access, still representing 60 percent to 70 percent of the middleware market, often came first, supporting initial two-tier client/server applications. Data access middleware is commonly built using an RPC mechanism, but not necessarily the RPC mechanism that already may be included with the operating system.

Next, DTP monitors grew in popularity on networked systems as a way to enable three-tier applications, but these require networking middleware, such as RPC and messaging, to connect to the servers. Finally, as WANs and greater numbers of heterogeneous systems prolifera ted, messaging middleware became increasingly important as a vehicle to provide asynchronous, event-oriented communication.

But rarely were these middleware components tied together so an application could switch seamlessly between messaging and RPC transports, or made interoperable so one DTP monitor could be replaced with another. In most cases, the developer not only must manually integrate two completely separate middleware packages, but also must manage one middleware platform on another.

It seems odd to discuss interoperability in the context of middleware--after all, one of middleware's primary benefits always has been providing some form of transparency, whether across networks, protocols or platforms. In many cases, middleware is the interoperating technology. Yet, there is a lack of plug-and-play operation between core middleware technologies, and there are no real standards--at the protocol or API level--to prompt any industry unification. All too often, large enterprise networks contain mor e than one type (or one vendor's proprietary version) of middleware, bringing a negative impact to bear on that network's interoperability and manageability.

Just as we don't want to see cast members simply recite their lines (we want the actors to communicate and interact with one another's characters as the play goes on), we don't want to see middleware acting on its own. Take messaging as an example. Because messaging as a platform includes distributed features, such as route and queue managers, messaging vendors often tout it as a complete solution. In reality, messaging is simply an asynchronous transport that essentially forces developers to write in an event-oriented manner on the network.