Network Computingwww.networkcomputing.com

That Saturday, I stood under my car with the Honda mechanic who pointed a t the hole in the very same exhaust pipe and explained to me that they did not put in that exhaust pipe. I was dumbfounded. When I explained that the parts department had assured me that the exhaust pipe that connected directly to the muffler was a Honda part, the mechanic didn't even bat an eye.

The parts department was absolutely correct, he said. The confusion was mine, he explained, because I did not know what was obvious to anyone who knew anything about Honda exhaust systems: a Honda "muffler" is not just that long, metal, ellipto-cylindrical thing laypeople call a "muffler." It is also that curly 18-inch exhaust pipe connected to it. So when I asked the Honda parts department if part number XYZZY1117 was the exhaust pipe that connects directly into the muffler, they thought I meant the 3-foot exhaust pipe that connects directly into that curly 18-inch exhaust pipe that is an integral part of the Honda muffler. Arrrrrgh!

Toward a Middleware Framework My only consolation from this painful experience is that it has provided me with further proof that most of the problems with middleware are generic to all systems of modularized interconnecting components. Car parts a re no more standardized or interchangeable than middleware components.

Middleware is the most complex and least understood part of the client/server paradigm. An organization can standardize its desktops (on Windows95, for instance), its servers (Solaris), its databases (Oracle), and even its applications (SAP R/3), but it cannot standardize its middleware. No single product or method can enable all client/server interaction. Middleware products compete, complement and coexist in overlapping layers from the network up.

Unlike networking software, which has been consolidated and simplified roughly into the seven-layer Open Systems Interconnection (OSI) protocol stack, middleware software cannot be divided into neat little layers. Two middlewa re products may overlap in numerous layers or components, and yet each may be missing a different critical layer. For example, Common Object Request Broker Architecture (CORBA) lacks a messaging transport layer, while BEA Systems' TUXEDO lacks an object-oriented application programming interface). Worse, within a layer, two products may have widely varying features (NobleNet's RPC 3.0 can marshall complex C datatype arguments that Sun's ONC RPC cannot).

What is needed are middleware frameworks, analogous to the application development frameworks, such as Microsoft's Foundation Classes, Borland's Object Windows Library (OWL) and various computer-aided software engineering (CASE) tools that have become standard in the past few years. Such frameworks would offer the flexibility of several middleware styles, while structuring such flexibility in ways that reduce an overwhelming plethora of possibilities to a manageable army of alternatives. Although a trend toward middleware consolidation and integration is u nder way, robust, coherent, configurable, enterprise-level middleware frameworks are at least five years away.

Meanwhile, organizations must face the reality of creating their own frameworks out of a chaotic middleware product space. To create such frameworks, org anizations must do three things: develop criteria for evaluating middleware; apply those criteria to select middleware that fits the organization's client/network/server infrastructure; and configure the selected middleware to better fit the resource constraints of the infrastructure.

Carving Middleware at Its Joints Conventional taxonomies arrange middleware roughly into the following seven market-based categories: remote data access (RDA), remote procedure call (RPC), distributed object middleware (DOM), transaction-processing middleware (TPM), message-oriented middleware (MOM), publish/subscribe middleware (PSM) and World Wide Web (WWW).