PERSPECTIVES

Middleware
Challenges
Kurt Geihs
Goethe University
Ahead
I
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
networking and workstation systems. Today, the scope of middleware
distributed system is 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-
networking and distribution infrastruc- ating environment for context-dependent activities,
as response time, 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, 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- Message passing 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 programming language 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 programming paradigm 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
software design 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 infor- its of reflexive middleware architectures.18 Future computing
mation, such as an encryption key, in the secure Finally, we must understand how to
sockets layer protocol’s transport layer for access- introduce composability and customiza-
environments will require
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 multimedia 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-
not completely mask these fluctuations. A ple, to protect a corporate network with a firewall—
supply and demand,
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
tions must adapt to the prevailing operat- various intermediary functions, but comprehensive
require adaptation. 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
model that captures the essence of these decisions
and allows comparison of different strategy per-
formances.
M iddleware research and development has
reached the end of its first major phase, and
new requirements are arising that are so fun-
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 computer science 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.
11. P. Ferreira et al., “PerDiS: Design, Implementation, and
REACH
HIGHER
Use of a Persistent Distributed Store,” Recent Advances
in Distributed Systems, Springer-Verlag, New York,
2000, pp. 427-452.
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.
585-590.
GIVE YOUR CAREER A BOOST
15. M. Zapf, H. Müller, and K. Geihs, “Security Require-
ments for Mobile Agents in Electronic Markets,” Proc.
UPGRADE YOUR MEMBERSHIP
computer.org/join/grades.htm