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 not only resembles the standardize on their terms. performance are often mutually exclu- classic two-tier application model, it

84 MARCH • APRIL 2002 http://computer.org/internet/ IEEE INTERNET COMPUTING Where is Middleware? also shares some of the same limita- and they can create and manipulate solve real-world problems. After all, tions. While traditional “back office” it with domain-independent tools. there is no one-size-fits-all solution to integration projects, such as encapsu- This means that Web services do the problems middleware addresses. lating databases behind application not require specialized IDLs or spe- servers, are never simple nor easy, con- cialized compilers or code genera- Only the Beginning temporary middleware has made them tors for such languages. This alone This column is about middleware and relatively straightforward. The next is an enormous leap forward. how it enables integration. This being goal is to build on that success and Business standards. To facilitate my inaugural column in IEEE Internet extend application integration from integration between trading partners, Computing, I’ve supplied only a brief the intranet to the Internet. all cooperating parties must fully high-level overview of the issues and understand Web services semantics. challenges we face as middleware con- Web Services Electronic Data Interchange, the e- tinues to mature and evolve. I find the Web services currently present the most business standard that’s been sup- configurability of modern middleware promising way to facilitate application- porting automated interactions interesting, and I intend to explore it to-application integration on the Inter- between trading partners for about further in future columns. I also dug into net.3 Unfortunately, the tremendous 20 years, includes standardized busi- Web services a bit because I believe they amount of hype surrounding Web ser- ness processes and documents. EDI hold promise as the next generation of vices makes it difficult to keep their is the forerunner of today’s XML- successful middleware, and I’ll cover fundamental aspects clear. Part of the based e-business standards such as them in greater depth as well. If you appeal is that there is nothing really ebXML (www.ebxml.org), RosettaNet have issues you’d like me to address in new about Web services; they simply (www.rosettanet.org), and UCCNet future columns, or comments you’d like use the ubiquitous Internet infrastruc- (www.uccnet.org). If Web services to share with me on anything I’ve writ- ture to apply proven approaches from are to succeed on an Internet scale, ten here, please e-mail me. mature middleware. Web services are they must incorporate standard busi- based on the convergence of four tech- ness documents and processes to References nology streams.4 To use them well, we enable correct interactions. 1. S. Vinoski, “Corba: Integrating Diverse Applications Within Distributed Heteroge- need not relearn what we’ve already neous Environments,” IEEE Comm., vol. 35, figured out the hard way. An important strength of Web services no. 2, pp. 46-55. is that they intentionally accommo- 2. R.E. Schantz and D.C. Schmidt, “Middleware Ubiquitous infrastructure. Web ser- date diversity and heterogeneity, not for Distributed Systems: Evolving the vices operate over the ubiquitous only in applications, operating sys- Common Structure for Network-centric Applications,” Encyclopedia of Software infrastructure of the Web, or more tems, and hardware platforms, but Eng., Wiley & Sons, New York, 2001; also accurately, the Internet. They nor- also in other middleware systems. One available at http://www.cs.wustl.edu/ mally communicate with other way to think of Web services is as ~schmidt/PDF/middleware-chapter.pdf. applications via Internet protocols “middleware for middleware.” Given 3. F. Curbera et. al., “Unraveling the Web Ser- such as HTTP or SMTP. that mature systems have been hurt by vices Web: An Introduction to SOAP, WSDL, and UDDI,” IEEE Internet Computing, vol. 6, Proven approaches. Web services their inability to incorporate useful no. 2, March/April 2002, pp. 86-93. incorporate fundamental aspects of features and approaches from each 4. S. Vinoski, “The Chief Architect’s View: Web proven middleware. They encour- other, it is tremendously powerful that services,” IONAsphere, IONA Technologies, age the creation of service-orient- Web services are “middleware agnos- May 2001; available at http://www.iona. ed architectures, as systems such as tic.” That means rather than replacing com/devcenter/articles/stevev/0501sv.htm. Corba have done for the past de- existing middleware solutions, you cade. Unlike most middleware, can just integrate and expand their Steve Vinoski is vice president of platform tech- though, they support both RPC-ori- capabilities via Web services. nologies and chief architect for IONA Tech- ented and message-oriented sys- Those with a flair for the dramatic nologies. Vinoski helped develop several tems equally well, which makes like to create artificial technology wars, aspects of the OMG Corba standard, including them extremely flexible. such as “COM vs. Corba” or “RPC vs. its C++ Language Mapping and Portable XML. Web services contracts are messaging.” They also like to make cer- Object Adapter. He is coauthor of Advanced defined in XML and communica- emonious declarations like “application CORBA Programming with C++ (Addison Wes- tions occur via XML-based mes- servers are dead,” but such actions serve ley Longman, 1999) and has written the sages. XML’s flexibility and ubiqui- only to hurt vendors and users alike. In “Object Interconnections” column for the C++ ty help set Web services apart from real life, successful technologies never Report and the C/C++ Users Journal with Dou- previous middleware technologies. die; technologies that some view as glas C. Schmidt since 1995. Vinoski currently Developers can use XML to repre- competitive, such as RPC and messag- serves as IONA’s representative to the W3C’s sent any structured information, ing, often must be applied together to Web Services Architecture working group.

IEEE INTERNET COMPUTING http://computer.org/internet/ MARCH • APRIL 2002 85