sign in sign up
<<
Home , Middleware

PERSPECTIVES

Middleware Challenges

Kurt Geihs Goethe University Ahead

n the first attempts to define comprehensive 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 isI 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 access, group- ware support, and workflow systems require special middleware solutions. . 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 . 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. . 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 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, invisible processing clients must pay for a service, they are certainly con- units contained in objects we use in activities of daily cerned about QoS, and they will expect to pay less for life.6 We may, for example, wear “personal area net- lower quality. works” powered through motion energy. These com- For Corba middleware, the Object Management puting devices will communicate with one another Group recently proposed new messaging extensions over a wireless network. Mobility and dynamic recon- that support QoS guarantees such as message deliv- figuration will be inherent features in this environ- ery and error handling. Research projects have pro- ment. Devices will automatically detect other devices, duced specific Corba-based platforms for handling forming ad hoc agglomerations spontaneously. The individual QoS categories such as real time1 or repli- middleware must withstand these dynamic challenges. cation and fault tolerance.2 Others have addressed Addressing and naming the multitude of computing generic frameworks for generating and operating cus- devices cannot be done with current technology. Even tomized systems for various QoS categories.3,4 Al- if we assume that the new IPv6 provides a sufficiently though integrating QoS management into middleware large IP address space, we must question whether every architectures is essential, a procedure for doing so has supermarket product’s smart label, for example, should yet to be agreed upon. obtain its own IP address because losing such an address with the product’s sale would be wasteful. Nomadic mobility Although a low-end computing device possesses Nomadic users in a highly mobile society enthusi- limited resources, it has stringent security require- astically take their “computing environment” every- ments. Imagine remotely monitoring and controlling where—for business or private use.5 New wireless a heart monitor. Interrupted communication and secu- communication technologies provide connectivity for rity context changes at runtime make the security laptop computers and personal digital assistants, problem a critical issue. phone organizers offer the processing power, and application-level protocols such as the wireless appli- PROGRAMMING MODELS cation protocol—a tiny first step—allow convenient Since the dawn of the computer age, computer sci- applications to run on these devices. Undoubtedly, entists have sought to determine the appropriate pro- these developments point toward the widely expressed gramming abstractions, particularly for distributed goal of accessing and processing information almost processing and middleware. “anywhere and any time.” Independent of our cur- rent location, we can already use voice communica- Client-server tion via mobile phones almost anywhere, and we have The client-server model has been the predominant worldwide access to personal e-mail, bank accounts, abstraction for building distributed software systems. and home-country news over the Web. The client, which binds to a server, initiates the inter- Mobility introduces a key technical challenge action, sends a request, and awaits the answer. In prin- because the available resources vary widely and unpre- ciple, this is a sequential pull model with a single

26 Computer logical control thread. The server stores long-term bility, and decoupling in large-enterprise state information related to particular client-server and Internet applications caused a strong associations. The term client-server is generally syn- general trend toward asynchronous, mes- onymous with distributed processing. However, sage-based communication in middleware increasingly important new application scenarios fit systems. poorly with the client-server interaction model, denot- Corba’s latest release offers more asyn- ing the end of this model’s dominance. chronous invocation mechanisms than Information dissemination uses a push model in previously available.8 In addition to the which the information source sends information to a existing deferred invocation and one-way Large-scale, widely group of receivers who have registered their interest in operations, Corba messaging defines an distributed systems a particular subject. Such publish/subscribe systems inherently asynchronous interaction style require decoupled, do not request information explicitly. Most workflow and includes selectable QoS guarantees systems are not strictly client-server—rather, a task such as message priorities, request time asynchronous moves from station to station, and each station per- limits, and queuing strategies. Further, two interaction. forms activities on a joint task. By receiving and programming models—polling and call- forwarding tasks, each station participates simulta- back—ensure that the client program can neously as client and server. The Web provides another deal appropriately with asynchronous re- example of storing long-term state information in the sponses. client’s file system—in this case as cookies. Scalability For Internet applications, the simple object access problems prohibit keeping the state entirely at the protocol defines a mechanism for transporting invo- server. Dealing with state in this way requires a par- cations between peers using HTTP or other protocols ticular programming style, which is different from and XML as the interface description and encoding conventional client-server programming. language. SOAP does not prescribe any particular pro- Lately, peer-to-peer interaction models in the gramming model. SOAP implements patterns such as Internet have attracted a lot of attention. Their server- request-response pairs as one-way transmissions from less file sharing effectively makes every computer client a sender to a receiver. Developers designed SOAP to and server at the same time. correspond with the Internet’s need for a lightweight, Thus, using the client-server model is not only inap- open, and flexible mechanism for linking arbitrary propriate in many interaction scenarios, it also can be applications and services. misleading to software developers and management. Event-based middleware architectures address the New application scenarios require another model and requirement for decoupled, asynchronous interaction more adequate terminology. in large-scale, widely distributed systems. Using events as the primary means of interaction allows asynchro- Asynchronous interaction nous, peer-to-peer notifications between objects and Independent from any particular communication provides flexible pattern-based event filtering and for- style, distributed programming models such as RPC warding options.9 and the later remote object invocation (ROI) are nat- accommodates peer-to-peer inter- ural companions for client-server applications. These action because it has weaker coupling and better scal- programming models introduce a synchronous, block- ability. However, in terms of programming ab- ing interaction style in which a server object remains stractions, this low-level paradigm makes program- passive until it receives a request, and the system ming potentially more error-prone and more difficult blocks the client’s execution until the server response to test and debug for elaborate communication pat- arrives. Distributed programming models hide distri- terns. Thus, we can view message passing as a back- bution because the transaction looks like a local pro- ward step in middleware evolution that illustrates the cedure call, and they elegantly handle the implicit design trade-off between degree of abstraction and synchronization. RPC and ROI remain middleware’s practical requirements. most popular communication models. Obvious drawbacks occur if the client uses the net- Shared memory work environment’s inherent parallelism, for exam- A continuous and lively debate focuses on invoca- ple, to send a search request in parallel to several tion-oriented versus shared-memory cooperation directory services. RPC-style communications offer models for distributed processing. The interaction two choices: Either use multithreading and spawn a among the distributed shared-memory model’s re- separate thread per request or use a modified non- mote processes occurs primarily by accessing shared blocking RPC facility. The RPC system’s inherently information items such as shared objects or shared in- sequential interaction style has received some criti- formation spaces. The middleware provides the illu- cism.7 Only lately has the need for scalability, flexi- sion of a shared memory.

June 2001 27 For example, developers have widely neous network environment. This trade-off between cited the Linda tuple space approach10 as generality in the programming model and homo- an elegant, flexible base for distributed geneity in the requires further applications. Although not widely used exploration. commercially, Linda offers an option when The inherent diversity of interaction styles in large- distribution is an issue. Recently, JavaSpaces scale heterogeneous systems with many autonomous revived the Linda idea. A JavaSpace is a entities and parallel activities requires new program- shared space containing Java objects that ming models. Whether we will live with a multitude supports an associative, Linda-style object of different models or develop a unified middleware matching. programming model that supports decoupled, flexi- Other projects like PerDiS11 have shown ble, and scalable interaction remains to be seen. that the shared-memory paradigm can be attractive for data-intensive cooperative ARCHITECTURE Large-scale applications. However, in its pure form, it In light of new technological advances, established heterogeneous systems lacks responsiveness. Because objects are middleware architecture elements merit reconsideration. with many autonomous passive, asynchronous events require addi- tional event-notification mechanisms. Distribution transparency entities and parallel The distributed shared-memory para- Creating transparency to hide the complexity and activities require new digm raises interesting middleware re- isolate applications from the underlying hardware and programming models. search questions in mobile-computing software details forms a cornerstone of all system soft- environments in which temporary discon- ware, especially for middleware systems. Conse- nections occur. For example, to control quently, the definition and discussion of distribution access to replicate shared data, conven- transparencies played a major role in the International tional pessimistic locking and concurrency control Organization for Standardization’s Reference Model mechanisms restrict mobile systems too tightly. for Open Distributed Processing. Distribution trans- Depending on the application scenario, data usage parency is beneficial and necessary for programming pattern, and networking situation, the middleware distributed applications. However, distribution trans- should adopt optimistic concurrency control schemes parency cannot be the foremost goal in nomadic com- to provide higher-degree data availability and appli- puting and context-aware applications.16 For ex- cation flexibility. An optimistic approach accepts ample, mobile users want to know about the security updates on replicated shared objects provisionally and guarantees their current environment provides. stores them in an update log. When the disconnected Context-aware applications need selective trans- system reconnects, reconciliation takes place based on parency features. The open research questions involve the update logs.12 how to expose network imperfections at the right level of granularity and abstraction and how applications Mobile code and mobile agents on top of the middleware deal with a selectable degree Mobile code and mobile agents enhance the flexi- of transparency. bility and adaptability of distributed applications at Increasing awareness of QoS requires making cer- runtime. They also provide performance advantages tain effects of distribution explicit. For example, cus- in situations in which shipping small amounts of code tomers who are charged for a certain level of to the nodes where the data originates is advisable communication service want to know about band- instead of wasting transmission bandwidth for trans- width variations or bad transmission quality because ferring large data quantities with low information con- they expect to pay less for lower quality. Complete tent. Sending code rather than an invocation introduces distribution transparency is inappropriate when com- a novel that is more general puting applications must adapt to fluctuations in than the conventional request-response or distributed resource supply such as variations in communication shared-memory models. The interaction of auton- bandwidth and fading battery power. However, we do omous agents cannot be classified generally as client- not currently have middleware facilities to control the server or publish/subscribe. Agents are peer entities degree of transparency. that interact at their own will. Mobile agents not only need a new programming model but also require new Layering typing concepts13,14 and security provisions.15 Since the implementation of the Open Systems Inter- Mobile agent-based middleware suffers from the connection ISO 7498 standard, layering has served as obvious shortcoming of requiring a homogeneous pro- the structuring principle for communication proto- gramming language environment, which creates a cols. OSI’s seven-layered architecture supports sepa- rather strong assumption in an inherently heteroge- ration of concerns, modularity, extensibility, flexibility,

28 Computer and so forth. Although later proposals did not always examples of how QoS frameworks can agree with some OSI layers—the need for a separate help build customized platforms using session layer is not obvious in Internet applications, enhanced interface specifications and addi- for example—new application requirements make it tional QoS management services. Al- necessary to renounce the strict layering principle in though developers recognize that frame- middleware systems and support a direct interaction works are the main architectural technique between nonadjacent layers. This development corre- for supporting flexibility and reusability, sponds with the need for selective distribution trans- few in the middleware arena use them. parencies. Several issues are of concern: Moreover, frameworks typically exploit patterns. We need more • Context-aware applications may need the IP research to find the specific patterns that address or the geographical location to make middleware frameworks require and to location-dependent decisions. explore the adaptability and flexibility lim- • The application may need authentication - its of reflexive middleware architectures.18 Future computing mation, such as an encryption key, in the secure Finally, we must understand how to environments will require sockets layer protocol’s transport layer for access- introduce composability and customiza- control decisions, whereas the middleware itself tion into middleware systems in response software systems that is not interested in this information. to QoS and ubiquitous computing de- support customization • An application may require a customized trans- mands. Rather than relinquish our estab- and adaptation. port protocol to perform a transfer lished architectural design principles, we that directly influences a nonadjacent layer’s con- must accept the challenge of amplifying figuration. these principles to accommodate new re- quirements. Middleware could offer appropriate programming interface elements to the applications and pass infor- DYNAMIC CONFIGURATION mation to and from the lower layers. Why should the Dynamic changes in system configuration and oper- middleware bother with handling information of no ating context at runtime will be inherent characteris- concern to itself just because of the layering princi- tics of future computing environments. Middleware ple? The conventional layering principle can also be design and development must readily meet these chal- violated in the other direction, bottom-up: The mid- lenges. dleware may need runtime information via a call back to the applications to request handling deci- Disconnected operation sions that relate, for example, to the caller’s security Mobile computing invalidates some implicit credentials. assumptions in current middleware platforms. For example, the Corba interoperability protocol assumes Monolithic architectures a permanent transport connection between the client To date, middleware products have been monolithic and the object implementation. In contrast, PDAs software systems that do not support customization automatically switch themselves off to save battery and adaptation. Such products cannot satisfy the power. This requires buffering replies to client requests needs of future computing environments. Mobile on the server side if the client is unreachable. How ubiquitous computing devices have few resources long should the server wait and keep the interaction’s compared with their stationary counterparts. Thus, state? Can we view these situations as faults and han- current middleware platforms such as Corba or dle them by applying conventional fault-tolerance COM+ are too bloated to be loaded into a resource- mechanisms? Reconnection also poses a severe secu- scarce mobile device. A Corba platform must be rity problem, requiring mutual reauthentication stripped down to fit its basic client functionality into within a client-server association’s lifetime. a PalmPilot PDA with 2-MByte memory. Developers On the client side, receiving and reacting correctly have criticized the inefficiency of existing object mid- to incoming replies requires facilities that uniquely dleware in application scenarios involving conven- identify and restore the state of earlier server associ- tional desktop computers. Occasionally, customized, ations. Web applications encode such state informa- low-overhead-interaction support mechanisms have tion in the URL or store it in cookies at the client’s replaced this middleware.17 end, but Corba middleware, for example, currently Likewise, QoS management demands customizable cannot handle this operation in a systematic, archi- middleware architectures. Diverse application require- tected way. Traditionally, we assumed that applica- ments make it impossible to construct a ready-made tion entities would be permanently available during platform for all QoS needs. MAQS3 and QuO4 are some application association. In modern networking

June 2001 29 environments, this assumption is no longer Intermediaries valid, although message-based, store-and- The diversity and heterogeneity of distributed sys- forward communication mechanisms offer tems increase the need for intermediaries. For example, one solution. The upcoming minimum a low-end device may be incapable of hosting the com- Corba specification, part of Corba 3.0, will plete middleware software in a ubiquitous computing include enhanced messaging facilities, environment. Therefore, a low-end device requires sup- although whether this provides a viable port from an intermediary on a more powerful com- practical solution remains to be seen. puter. Then the intermediary translates and forwards external communication requests to the low-end device Adaptive applications and manages agglomerations of low-end devices. Mobile-computing applications must Connecting heterogeneous middleware domains—for The middleware must cope with a dynamically varying resource example, bridging COM+ to a message-queuing sys- monitor the resource supply. The underlying middleware can- tem—or separating authoritative domains—for exam- supply and demand, not completely mask these fluctuations. A ple, to protect a corporate network with a firewall— similar situation arises for QoS-aware also requires an intermediary. Developers also use inter- compute adaptation applications in a best-effort networking mediaries to transform ordinary information streams decisions, and notify environment such as the Internet. In the to enhance the information’s quality.19 applications if they absence of resource guarantees, applica- Developers have provided pragmatic solutions for require adaptation. tions must adapt to the prevailing operat- various intermediary functions, but comprehensive ing conditions. For example, if communi- general principles are missing. We must address not cation bandwidth becomes scarce, a tourist only intermediaries’ functionality, but also the inte- information application on a mobile com- gration of issues like security, transactions, conversion puter with a wireless connection can dis- overhead, and reliability. For example, using an inter- play text and low-resolution pictures instead of video mediary to act as a representative for other devices clips. Thus, the middleware must monitor the resource requires sound security concepts for delegating supply and demand, compute adaptation decisions, authority. Although a few individual solutions are and notify applications if they require adaptation. available such as the largely unexplored Corba secu- Although researchers have studied the viability rity specification for delegation, how mature these of application adaptation in mobile systems, strate- concepts are remains unclear. gies for making adaptation decisions also require exploration. Currently, work is under way on a iddleware research and development has model that captures the essence of these decisions reached the end of its first major phase, and and allows comparison of different strategy per- M new requirements are arising that are so fun- formances. damentally different that they will lead to new-gen- eration middleware systems. This transition poses a Ad hoc organization number of questions: Ubiquitous computing requires enormously diverse computing devices, many of which are mobile and use • What is the most appropriate programming wireless communications. Based on lower-layer dis- model for the diverse application scenarios? covery protocols, these devices automatically detect • Does a single distributed programming model fit others and spontaneously form ad hoc agglomera- all applications? tions. Existing middleware platforms do not scale to • Can we build customizable, configurable, and the device diversity, population size, and runtime flexible middleware frameworks for inherently dynamics that ubiquitous computing requires. Static heterogeneous environments? configuration assumptions about what infrastructure • What middleware features and infrastructure ser- services are accessible in a computing environment are vices will the dynamics and ad hoc nature of no longer sufficient. Self-organization, extensive infor- mobile-ubiquitous computing require? mation caching, and delegation of activities are impor- tant requirements. These issues are the top challenges for future mid- The Java-based Jini system appears to anticipate dleware research, generating open research problems these requirements. Jini defines a middleware infra- that require building applications atop new middle- structure for spontaneous networking in which Java ware prototypes. Therefore, we have no reason to objects can discover, join, and interact with commu- resign ourselves to believing Pike’s provocative state- nities of objects. Whether the Jini approach will scale ment that “systems software research is irrelevant.”20 to the requirements of ubiquitous computing, how- Many exciting and challenging questions await reso- ever, remains unclear. lution. ✸

30 Computer Acknowledgments Int’l Working Conf. Trends in Distributed Systems for I thank Anne-Marie Kermarrec, Ant Rowstron, and Electronic Commerce (TrEC 98), Lecture Notes in Com- Marc Shapiro for their technical contributions and puter Science, Springer-Verlag, New York, 1998, pp. constructive comments. 205-214. 16. P.J. Brown, J.D. Bovey, and X. Chen, “Context-Aware References Applications: From the Laboratory to the Marketplace,” 1. D.C. Schmidt, D.L. Levine, and S. Mungee, “The Design IEEE Personal Comm., vol. 4, no. 5, 1997, pp. 58-64. of the TAO Real-Time Object Request Broker,” Com- 17. T. Weis and K. Geihs, “Components on the Desktop,” puter Comm. J., vol. 21, no. 4, 1998, pp. 294-324. Proc. Technology of Object-Oriented Languages and 2. S. Maffeis, “The Object Group Design Pattern,” Proc. Systems (TOOLS Europe 2000), IEEE CS Press, Los Conf. Object-Oriented Technologies and Systems Alamitos, Calif., 2000, pp. 250-261. (COOTS 96), Usenix, Berkeley, Calif., 1996, pp. 294-303. 18. F. Costa, G. Blair, and G. Coulson, “Experiments with 3. C. Becker and K. Geihs, “Generic QoS Support for Reflective Middleware,” Proc. ECOOP 98 Workshop Corba,” Proc. Int’l Symp. Computers and Communi- Reflective Object-Oriented Programming and Systems, cation (ISCC 2000), IEEE CS Press, Los Alamitos, Calif., Springer-Verlag, New York, 1998, pp. 390-393. 2000, pp. 60-65. 19. R. Barrett and P. Maglio, “Intermediaries: An Approach 4. R. Vanegas et al., “QuO’s Runtime Support for Quality to Manipulating Information Streams,” IBM Systems of Service in Distributed Objects,” Proc. IFIP Int’l Conf. J., vol. 38, no. 4, 1999, pp. 629-641. Distributed System Platforms and Open Distributed Pro- 20. R. Pike, “Systems Software Research Is Irrelevant,” cessing, Springer-Verlag, New York, 1998, pp. 207-223. http://cm.bell-labs.com/who/rob/utah2000.ps. 5. L. Kleinrock, “Nomadic Computing,” Proc. IFIP/ICCC Int’l Conf. Information Network and Data Communi- Kurt Geihs is a professor of at cation, Chapman & Hall, London, 1996, pp. 223-233. Goethe University, Frankfurt, Germany. His research 6. M. Weiser, “Some Computer Science Issues in Ubiqui- interests include distributed systems, operating sys- tous Computing,” CACM, July 1993, pp. 75-84. tems, networks, and software technology. Current 7. A.S. Tanenbaum and R. Van Renesse, “A Critique of the projects focus on quality-of-service management in Remote Procedure Call Paradigm,” Proc. European Corba, component-based software, and mobile Teleinformatics Conf. (EUTECO 88), North-Holland, agents. Geihs received a PhD in computer science Amsterdam, 1988, pp. 775-783. from the Technical University in Aachen, Germany. 8. J. Siegel, “An Overview of Corba 3,” Proc. 2nd IFIP Contact him at [email protected]. Int’l Working Conf. Distributed Applications and Inter- operable Systems (DAIS 99), Kluwer, Boston, 1999, pp. 119-132. 9. J. Bacon et al., “Generic Support for Distributed Appli- cations,” Computer, Mar. 2000, pp. 68-76. 10. N. Carriero and D. Gelernter, “Linda in Context,” CACM, Apr. 1989, pp. 444-458. REACH 11. P. Ferreira et al., “PerDiS: Design, Implementation, and Use of a Persistent Distributed Store,” Recent Advances in Distributed Systems, Springer-Verlag, New York, 2000, pp. 427-452. HIGHER 12. M. Shapiro, A. Rowstron, and A-M. Kermarrec, “Appli- cation-Independent Reconciliation for Nomadic Appli- cations,” Proc. 9th ACM SIGOPS European Workshop, Advancing in the IEEE Computer Society ACM Press, New York, 2000, pp. 1-6. can elevate your standing in the profession. 13. N. Minar et al., “Hive: Distributed Agents for Net- Application to Senior-grade membership recognizes working Things,” Proc. 1st Int’l Symp. Agent Systems ✔ and Applications and 3rd Int’l Symp. Mobile Agents, ten years or more of professional expertise IEEE CS Press, Los Alamitos, Calif., 1999, pp. 118-129. Nomination to Fellow-grade membership recognizes 14. M. Zapf and K. Geihs, “What Type Is It? A Type Sys- ✔ exemplary accomplishments in tem for Mobile Agents,” Proc. 15th European Meeting computer engineering on Cybernetics and Systems Research (EMCSR 2000), Austrian Soc. for Cybernetic Studies, Vienna, 2000, pp. GIVE YOUR CAREER A BOOST 585-590. 15. M. Zapf, H. Müller, and K. Geihs, “Security Require- UPGRADE YOUR MEMBERSHIP ments for Mobile Agents in Electronic Markets,” Proc. computer.org/join/grades.htm