PERSPECTIVES Middleware Challenges Kurt Geihs Goethe University Ahead n the first attempts to define comprehensive software platforms for dis- Facing dynamic tributed applications 25 years ago, researchers created basic middle- ware elements such as remote procedure call, file service, and directory modifications in service based on dramatic advances in hardware technology and fast distributed system networking and workstation systems. Today, the scope of middleware Iis broader, and distributed system technology occupies a prominent place in industrial and academic research and development. technology, middleware The term middleware refers to the software layer between the operating sys- developers strive to tem—including the basic communication protocols—and the distributed appli- cations that interact via the network. This software infrastructure facilitates the support applications interaction among distributed software modules. I avoid defining middleware further because its definitions share a common problem: Depending on the appli- that meet the technical cation environment, opinions differ as to which components comprise middle- ware. General middleware systems support the interaction of arbitrary challenges of ubiquitous application programs; specific functions such as remote database access, group- ware support, and workflow systems require special middleware solutions. computing. A middleware layer seeks primarily to hide the underlying networked envi- ronment’s complexity by insulating applications from explicit protocol handling, disjoint memories, data replication, network faults, and parallelism. Further, mid- dleware masks the heterogeneity of computer architectures, operating systems, programming languages, and networking technologies to facilitate application programming and management. Middleware design includes quality of service (QoS) management and information security. Different middleware systems address these issues in different ways. The “Two Decades of Middleware Develop- ment” sidebar gives an overview of middleware history. New application requirements challenge the established middleware design principles. As the first phase of middleware evolution draws to a close, we are poised to enter a major middleware design and development phase that requires new insights into distributed system technology. THE CHANGING ENVIRONMENT The communication and computing world has changed dramatically since the era in which early middleware developers worked in environments domi- nated by locally connected Unix workstations. Enterprise application integration Today, large enterprises with potentially autonomous suborganizations face a pressing requirement—integrating a multitude of applications and data sources 24 Computer 0018-9162/01/$10.00 © 2001 IEEE within an enterprise and across enterprises. Formerly The autonomy and decoupling aspects’ importance independent applications must interact to access and increases with the size of the distributed system—an share functions and data stored in heterogeneous essential issue in an open global-service market. databases. In a large bank, hundreds of application subsystems must be integrated. These applications Internet applications access data sources ranging from relational databases The Internet’s enormous success and growth have to external information providers. Further, collabo- created a distributed application environment that dif- rations with other enterprises, mergers, acquisitions, fers from typical enterprise application scenarios. and the Internet—a totally unstructured data Web-based applications must cope with a variety of source—complicate the integration task. Such an envi- performance issues. ronment’s dominating attributes—large-scale config- uration, diverse interaction models, autonomous • The number of users may fluctuate and be unpre- interacting partners, and heterogeneous data views— dictable. If users can’t get short response times, may render previously appropriate middleware prin- they tend to abort requests. ciples unsuitable. • The concept of a stateful user session is harder Consider a travel reservation system with airline, to maintain. Keeping state information at the hotel, and rental car services. With remote procedure server for user sessions and user profiles may be call middleware, a reservation request for a trip leads infeasible given the potentially large numbers of to a chain of consecutive RPCs (synchronous, tightly concurrent accesses. coupled procedure invocations), for example, client • The interacting parties belong to independent, → airline → hotel → rental car, and back to the client autonomous organizations that do not necessar- along the same sequence in reversed order. In RPC ily trust each other. Further, interaction takes middleware, invocation calls a procedure; in object- place over an insecure medium. oriented programming, invocation calls an object’s • The communication infrastructure does not pro- method or a subroutine. With message-passing mid- vide QoS guarantees. dleware, the interaction pattern is more flexible. The • Because of the inherently open environment, services notify the client directly about the reserva- exchanging information can require self-describ- tion’s progress. Generally, as the number of inde- ing data and agreement on common ontologies. pendent service providers increases, a chain of • New Web-based applications must interoperate consecutive RPCs becomes too rigid. This requires a seamlessly with existing legacy applications. loosely coupled interaction model that adequately reflects the autonomy of the involved parties and pro- For existing middleware systems, this nonexhaus- vides the necessary spatial and temporal decoupling. tive list of properties poses new demands. Developers Two Decades of Middleware Development Early examples of distributed system platforms include Athena ming language environment have received widespread attention. at MIT,1 ITC/ Andrew at CMU,2 ANSAware,3 and DACNOS at Other notable middleware products include message-based sys- IBM and the University of Karlsruhe.4 The DACNOS program- tems such as IBM’s MQS. ming model, developed in the second half of the 1980s, was built on the elegant combination of an asynchronous communication References model and a simple shared object model.4 Thereafter, the indus- 1. E. Balkovich, S. Lerman, and R. Parmelee, “Computing in Higher try consortia’s standardization activities resulted in specifications Education: The Athena Experience,” CACM, vol. 28, no. 11, for standard middleware architectures, such as DCE5 and Corba. 1985, pp. 1214-1224. The International Organization for Standardization and its related 2. J.H. Morris et al., “A Distributed Personal Computing Environ- standardization bodies provided a Reference Model for Open Dis- ment,” CACM, vol. 29, no. 3, 1986, pp. 184-201. tributed Processing that failed to make a significant impact in the 3. A. Herbert, “Key Architectural Concepts,” ANSA Project, report middleware evolution. no. AO-82-02, 1987. In today’s information technology environments, OMG Corba 4. K. Geihs and U. Hollberg, “A Retroperspective on DACNOS,” and Microsoft’s Distributed Component Object Model/ COM+6 CACM, vol. 33, no. 4, 1990, pp. 439-448. provide widely used, general-purpose middleware architectures 5. W. Rosenberry, D. Kenney, and G. Fisher, Understanding DCE, for distributed object computing. Lately, middleware approaches O’Reilly & Associates, Sebastopol, Calif., 1992. such as remote method invocation, Jini, JavaSpaces, and Enter- 6. D.S. Platt, Understanding COM+, Microsoft Press, Redmond, prise JavaBeans that depend on Java’s homogeneous program- Wash., July 1999. June 2001 25 must reevaluate architectures such as dictably. Communication bandwidth and error rates Corba and the Distributed Component change dynamically in wireless communication net- Object Model from the Internet’s perspec- works, a mobile system’s battery power decreases, tive. Internet middleware developers must portable devices can be temporarily switched off or address issues such as autonomy, decen- unreachable because of network partitions, and the tralized authority, intermittent connectiv- monetary cost of communication can vary signifi- ity, continual evolution, and scalability. cantly. Envisaging a middleware system that makes these dynamics transparent is difficult; we anticipate Quality of service that middleware must support the applications to Increasing concerns about service qual- explicitly accommodate these changes. Another QoS management aims to ity have led to several proposals that advo- mobile-computing issue, location awareness, demands control attributes such cate integrating QoS management into that mobile-computer applications know their oper- as response time, networking and distribution infrastruc- ating environment for context-dependent activities, tures. QoS management at the middleware such as giving directions or employing more or less availability, data and application levels aims to control stringent security mechanisms. accuracy, consistency, attributes such as response time, avail- and security level. ability, data accuracy, consistency, and Ubiquitous computing security level. From the Internet perspec- The ubiquitous or pervasive computing vision tive, QoS concerns seem to arise automat- assumes that future computing environments will ically when commercial applications meet comprise diverse computing devices ranging from a best-effort communication environment. When large computers to microscopic,