Toward Integration Where is Middleware? Steve Vinoski • IONA Technologies • [email protected] his column is all about middleware, and eventually need to integrate two or more systems ultimately, middleware is all about integra- that use different middleware. T tion. Middleware has existed in various forms for many years in systems such as the IBM Middleware Classification Customer Information Control System (CICS), We commonly classify (and debate) middleware numerous message queuing systems such as IBM’s systems along several dimensions. The following MQ Series, the Common Object Request Broker list is not exhaustive, but it still shows that many Architecture (Corba), Microsoft’s Component Object different types of middleware are possible and nec- Model (COM), Java 2 Enterprise Edition (J2EE), and essary to solve all the integration problems we face. the latest rage, Web services. Virtually every form of application, programming language, operating RPC vs. Asynchronous Messaging system, and hardware has been a target of an inte- At an abstract level, remote procedure calls enable gration effort involving these middleware systems programmers to invoke (possibly remote) services or their cousins. Middleware is everywhere. as if they were intra-application procedure calls. The many reasons we need middleware all boil Much like function or procedure calls in traditional down to one: As technology continues to evolve programming languages, RPCs block the caller’s at an accelerating rate, nontrivial computing sys- execution while the invoked service carries out the tems will remain diverse and heterogeneous.1 caller’s request. In other words, while the called ser- Computing systems grow over time, which means vice is busy handling the caller’s request, the call- hardware and applications purchased years ago ing thread stops executing and waits until the must work together with those purchased just yes- request either returns normally or encounters an terday. Add factors such as mergers, reorganiza- error such as a timeout condition. Messaging sys- tions, leadership changes, and e-business into the tems, on the other hand, are based on a queuing picture, and the heterogeneity in the overall sys- abstraction in which producers post data to queues tem rises sharply. As much as we might wish oth- for consumers to retrieve and act upon. Messaging erwise, the complexity caused by this diversity will systems are typically data- or document-oriented, not disappear anytime soon, if ever. while RPC systems are procedure- or object- We’re surrounded by examples of successfully oriented. Middleware applications based on mes- deployed middleware in cost-effective and effi- saging typically have key abstractions and design cient production computing systems. Neverthe- centers that revolve around information, whereas less, it’s interesting to note that while middle- applications based on RPC center around the objects ware eases the diversity and heterogeneity and functions that provide system services. problem, it does not completely solve it. It’s iron- ic that all forms of middleware attempt to reduce Language-Specific vs. Language-Independent complexity by introducing artificial homogene- Many middleware systems support the integration ity into the system, which only delays the of applications written in different programming inevitable collision between heterogeneous sys- languages. Corba is probably the best example tems. The very ab-stractions and simplifications because it explicitly supports several language that allow middleware to address integration mappings for its Interface Definition Language issues can also cause problems between middle- (IDL), which is used for defining contracts for Corba ware systems. After all, middleware systems dif- objects. The argument for such middleware is that fer from each other, and system administrators complex computing systems — perhaps involving IEEE INTERNET COMPUTING 1089-7801/02/$17.00 ©2002 IEEE http://computer.org/internet/ MARCH • APRIL 2002 83 Toward Integration everything from handheld devices to Embedded vs. Enterprise sive, achieving acceptable levels of Windows laptops to Unix servers and Middleware has historically targeted both can be tricky. Power users want mainframes — are rarely written in a enterprise systems, which typically in- hooks into all parts of the middleware single language. Nevertheless, many volve many disparate computing sys- so they can take control wherever they systems, such as J2EE, are based on the tems, usually including one or more deem necessary, but they also want simplifying assumption that one pro- mainframes, across multiple company their applications’ performance levels gramming language is in use. Other divisions. Such systems normally seek to be the same as if they were running single-language distributed systems to improve business process automa- directly on the operating system. Too have also been developed using C++, tion. Embedded systems, with their spe- many configuration “knobs,” on the Modula-3, and Smalltalk. cial hardware environments and typi- other hand, often frighten new users; cally stringent software requirements, they want to simply install the mid- Proprietary vs. Standards-Based were mostly off limits for middleware dleware and have it work. Finding a The argument for middleware stan- until recently. Advances in hardware suitable balance between these ex- dards is that by enabling interoper- and software have made embedded tremes is what keeps middleware ability and portability between prod- middleware viable, however, now that architects and designers up at night. ucts, they prevent “customer lock-in” developers can create embedded sys- As hardware performance has and allow users to select middleware tems using commercial off-the-shelf increased, so has the capacity to tune based on quality. In the real world, (COTS) components.2 Still, embedded middleware through configuration, however, this black-and-white stan- middleware faces real-time deadline rather than through programming. By dards ideal deteriorates into various and predictability constraints that often separating development from deploy- shades of gray as some vendors pay lip limit its size and available features. ment issues, this approach lowers main- tenance costs for middleware applica- tions. Our goal is to be able to affect the The most significant challenge...is facilitating application’s behavior without going Internet-scale application-to-application integration. back to modify, recompile, retest, and finally redeploy its source code. The deployment descriptor design of Enter- service to standards while still hook- Like its embedded counterpart, enter- prise Java Beans (EJB) is a prime exam- ing customers into lock-in. prise middleware also tends to address ple of this approach. An unfortunate On the other hand, even those mid- runtime overhead, but it can typically side effect of increasing the configura- dleware vendors that stay true to stan- ignore issues such as memory footprint. bility of applications, however, is that dards are typically forced to introduce Enterprise middleware also tends to be configuration has become nearly as proprietary features to cover areas the highly dynamically configurable, and it complicated as programming. standards do not address. No standard requires runtime management capabil- Reducing system complexity is in- can address all possible problems — ities that allow system operators to deed a significant challenge for middle- not even long-lived standards such as monitor for proper operation. Because ware suppliers. However, contemporary Corba or the collection created under it needs to integrate a wider array of middleware systems address such a wide the Java Community Process (www. disparate systems, users often judge variety of problems that they themselves jcp.org). Furthermore, standardization enterprise middleware mostly by how have become complicated, in some efforts can be lengthy, bureaucratic, easily it allows them to integrate new cases overly so. Clearly, middleware expensive, and political. Proprietary systems. On the other hand, users typi- designers need to make sure that their development efforts typically seek to cally judge real-time and embedded systems are flexible, but they need to avoid these negative aspects while middleware on memory footprint, per- establish reasonable default settings that protecting potentially lucrative secrets formance, and predictability. make reconfiguration unnecessary for from competitors. Very large compa- the most common cases. nies (such as Microsoft) or very small Middleware Challenges Perhaps the most significant chal- vendors are normally the ones that Despite the differences among com- lenge facing middleware today is facil- pursue proprietary efforts. The very peting systems, all middleware shares itating Internet-scale application-to- large believe their proprietary efforts some characteristics that make it chal- application integration. The World will eventually become actual or de lenging to build and deploy. Foremost Wide Web has shown us how the facto standards due to sheer volume, among these is that everyone wants Internet can be used to support suc- and the very small often believe their middleware to be as flexible as possi- cessful consumer-to-business interac- systems will be novel enough to dis- ble — and to provide high levels of tions. However, its browser-Web site rupt the market and force others to performance. Given that flexibility and architecture