University of California, Irvine, 92697
This invited editorial appeared in the Parallel and Distributed Computing
Practices journal, edited by Maria Cobb and
Kevine Shaw, Vol. 3, No. 1, March 2000.
Limitations with Current Practice
During the past decade advances in VLSI technology and fiber-optics
have increased computer processing power by 3-4 orders of magnitude
and network link speeds by 6-7 orders of magnitude. Assuming that
these trends continue, by the end of this decade there will be
billions of interactive and embedded computing and communication
devices throughout the world running at clock speeds approaching ~100
Gigahertz, LAN link speeds running at ~100 Gigabits/second, and
wireless link speeds running at ~100 Megabits/second. These powerful
computers and networks will be available largely at commodity prices,
built mostly with robust commercial off-the-shelf (COTS) components,
and will inter-operate over an increasingly convergent and pervasive
To maximize the benefit from these advances in hardware technology,
the quality and productivity of technologies for developing
distributed middleware and application software must also increase.
Historically, hardware has tended to become smaller, faster, and more
reliable. It has also become cheaper and more predictable to develop
and innovate, as evidenced by Moore's Law. In contrast, however,
distributed software has often grown larger, slower, and more
error-prone. It has also become very expensive and time-consuming to
develop, validate, maintain, and enhance.
Although hardware improvements have alleviated the need for some
low-level software optimizations, the lifecycle cost [Boehm:88] and
effort required to develop software--particularly mission-critical
distributed and embedded real-time applications--continues to rise.
The disparity between the rapid rate of hardware advances versus the
slower software progress stems from a number of factors, including:
- Inherent and accidental complexities. There are vexing
problems with distributed software that result from inherent and
accidental complexities. Inherent complexities arise from fundamental
domain challenges such as detecting and recovering from partial
failures and distributed deadlocks, minimizing the impact of
communication latency, determining an optimal partitioning of service
components and workload onto computers throughout a network, and
guaranteeing end-to-end quality of service (QoS) requirements. As
networked systems have grown in scale and functionality they must now
cope with a much broader and harder set of these complexities.
Accidental complexities arise from limitations with software tools and
development techniques, such as non-portable programming APIs, poor
distributed debuggers, and the widespread use of algorithmic--rather
than object--oriented design, which results in non-extensible and
non-reusable systems. Ironically, many accidental complexities stem
from deliberate choices made by developers who favor low-level
languages and tools that scale up poorly when applied to complex
- Continuous re-invention and re-discovery of core concepts and
techniques. The software industry has a long history of recreating
incompatible solutions to problems that are already solved. For
example, there are dozens of non-standard general-purpose and
real-time operating systems that manage the same hardware resources.
Likewise, there are dozens of message-oriented and method-oriented
middleware frameworks that provide slightly different APIs that
implement essentially the same features and services. If effort had
instead been focused on enhancing and optimizing a small number of
solutions, developers of distributed software would be reaping the
benefits available to hardware developers, who innovate rapidly by
reusing and applying common CAD tools and standard instruction sets,
buses and network protocols.
Solution Approach: Distributed Object Computing
Obviously, no single silver bullet [Brooks:87] can slay all the demons
plaguing distributed software. Over the past decade, however, it has
become clear that distributed object computing (DOC) can help
to alleviate many inherent and accidental software complexities. DOC
represents the confluence of two major areas of software
- Distributed computing systems. Techniques for developing
distributed systems focus on integrating multiple computers to act as
a scalable computational resource.
- Object-oriented (OO) design and programming. Techniques
for developing OO systems focus on reducing complexity by creating
reusable frameworks and components that reify successful design
patterns and software architectures.
Thus, DOC is the discipline that uses OO techniques to distribute
reusable services and applications efficiently, flexibly, and robustly
over multiple, often heterogeneous, computing and networking
At the heart of contemporary distributed object computing is DOC
middleware. DOC middleware is object-oriented software that
resides between applications and the underlying operating systems,
protocol stacks, and hardware to enable or simplify how these
components are connected and interoperate, as shown in
the following figure:
In general, DOC middleware can be decomposed into the following
In general, these layers of DOC middleware provide the following
benefits: (1) they shield software developers from low-level, tedious,
and error-prone details, such as socket-level programming
[Schmidt:94k], (2) they provides a consistent set of higher-level
abstractions [QuO:97] for developing distributed systems, (3) they
amortize software lifecycle costs by leveraging previous development
expertise and capturing implementations of key patterns [Vlissides:94]
in reusable frameworks, rather than building them entirely from
scratch for each use-case.
- Infrastructure middleware, which encapsulates and
enhances native OS communication and concurrency mechanisms to create
object-oriented (OO) network programming components, such as reactors,
acceptor-connectors, monitor objects, active objects, and component
configurators. These components help eliminate many tedious,
error-prone, and non-portable aspects of developing and maintaining
networked applications via low-level OS programming API, such as
Sockets or POSIX pthreads. Widely-used examples of infrastructure
middleware include Java virtual machines (JVMs) [Lindholm:97] and the
ADAPTIVE Communication Environment (ACE) [Schmidt:94k].
- Distribution middleware, which use and extend the
infrastructure middleware to define a higher-level distributed
programming model. This programming model defines reusable APIs and
components that automate common end-system network programming tasks,
such as connection management, (de)marshaling, demultiplexing,
end-point and request demultiplexing, and multi-threading.
Distribution middleware enables distributed applications to be
programmed using techniques familiar to developers of stand-alone
applications, i.e., by having clients invoke operations on
target objects without concern for their location, programming
language, OS platform, communication protocols and interconnects, and
hardware. At the heart of distribution middleware are Object Request
Brokers (ORBs), such as Microsoft's Component Object Model (COM)+
[Box:97], Sun's Java Remote Method Invocation (RMI) [Waldo:96], and
the OMG's Common Object Request Broker Architecture (CORBA)
- Common middleware services, which augment distribution
middleware by defining higher-level domain-independent services, such
as event notifications, logging, multimedia streaming, persistence,
security, global time, real-time scheduling and end-to-end quality of
service (QoS), fault tolerance, concurrency control, and transactions
[CorbaComponents:99f]. Whereas distribution middleware focuses
largely on managing end-system resources in support of an OO
distributed programming model, common middleware services focus on
managing resources throughout a distributed system. Developers can
reuse these services to allocate, schedule, and coordinate global
resources and perform common distribution tasks that would otherwise
be implemented in an ad hoc manner within each
- Domain-specific services, which are tailored to the
requirements of particular domains, such as telecommunications,
e-commerce, health care, process automation, or aerospace. Unlike the
other three OO middleware layers--which provide broadly reusable
``horizontal'' mechanisms and services--domain-specific services are
targeted at vertical markets. Domain-specific services are the least
mature of the middleware layers today, due partly to the historical
lack of distribution middleware and common middleware service
standards, which provide a stable base upon which to create
domain-specific services. Since these services embody knowledge of
application domains, however, they can significantly increase system
quality and decrease the cycle-time and effort required to develop
particular types of distributed applications.
Emerging Trends in Distributed Object Computing R&D
The following trends are shaping the evolution of software development
techniques for applications and middleware based on distributed object
- Applying patterns to capture the ``best practices'' of
distributed object computing. Many patterns associated with
middleware and applications for concurrent [Lea:99] and networked
objects [Schmidt:00a] have been documented during the past decade. A
key next step is to document the patterns for designing [Vlissides:94]
and optimizing [Schmidt:99h] distributed objects, extending earlier
work to focus on topics such as remote service location and
partitioning, naming and directory services, load balancing,
dependability and security. An increasing number of distributed
object computing systems, for example, must provide high levels of
dependability to client programs and end-users. With the adoption of
the CORBA Fault Tolerance specification and ORBs that implement this
specification, developers will have more opportunities to capture
their experience in the form of patterns for fault-tolerant
distributed object computing.
- Real-time and embedded systems. An increasing number of
computing systems are embedded, including automotive control systems
and car-based applications, control software for factory automation
equipment, avionics mission computing and hand-held computing
devices. Many of these systems are subject to stringent computing
resource limitations, particularly memory footprint and
time-constraints. Developing high-quality real-time and embedded
systems is hard and remains somewhat of a ``black art.'' As the
efficiency, scalability, and predictability of DOC middleware
continues to improve, and is increasingly capable of being subsetted
to reduce footprint, it will be applied extensively in these
- Mobile systems. Wireless networks are becoming pervasive
and embedded computing devices are become smaller, lighter and more
capable. Thus, mobile systems will soon support many consumer
communication and computing needs. Application areas for mobile
systems include ubiquitous computing, mobile agents, personal
assistants, position-dependent information provision, remote medical
diagnostics and teleradiology and home and office automation. In
addition, Internet services, ranging from Web browsing to on-line
banking, will be accessed from mobile systems. Mobile systems present
many challenges, such as managing low and variable bandwidth and
power, adapting to frequent disruptions in connectivity and service
quality, diverging protocols and maintaining cache consistency across
disconnected network nodes. DOC middleware is essential to provide a
flexible and adaptive framework for developing and deploying mobile
- Quality of service for common-off-the-shelf (COTS)-based
distributed systems. Distributed systems, such as streaming video,
Internet telephony and large-scale interactive simulation systems,
have increasingly stringent quality of service (QoS) requirements. Key
QoS requirements include network bandwidth and latency, CPU speed,
memory access time and power levels. To reduce development cycle-time
and cost, such distributed systems are increasingly being developed
using multiple layers of COTS hardware, operating systems and
middleware components. Historically, however, it has been hard to
configure COTS-based systems that can simultaneously satisfy multiple
QoS properties, such as security, timeliness and fault tolerance. As
developers and integrators continue to master the complexities of
providing end-to-end QoS guarantees, it is essential that successful
patterns and techniques be reified in DOC middleware to help others
configure, monitor and control COTS-based distributed systems that
possess a range of interdependent QoS properties [QuO:97].
- Reflective middleware. This term describes a collection of
technologies designed to manage and control system resources in
autonomous distributed application and systems. Reflective middleware
techniques enable dynamic changes in application behavior by adapting
core software and hardware protocols, policies and mechanisms with or
without the knowledge of applications or end-users [Kon:00]. As with
distributed system QoS, DOC middleware will play a key role in
supporting the effective application of reflective middleware-based
Advances in distributed object computing (DOC) technology have
occurred at a time when deregulation and global competition are
motivating an increase in software productivity and quality.
Distributed computing is perceived as a way to meet QoS requirements
for dependability and scalability, and to control costs via open
systems. Likewise, OO design and programming are widely touted as a
means to reduce software cost and improving software quality through
reuse, extensibility, and modularity. As a result, there has been a
surge of interest in DOC technology in the trade press and in many
Unfortunately, the level of high quality R&D focus concerning DOC
technologies has not kept pace with the level of interest. Since DOC
is a combination of two fields, academic journals and conferences
concerned with either field have only recently embraced the merger,
which has yielded relatively few forums for technical discussion of
the combined disciples. Consequently, DOC technology has been
``sold'' far more than it has been studied systematically. This
special issue Parallel and Distributed Computing Practices is
intended to rectify this imbalance by examining the technical benefits
and the challenges provided by DOC technology.
B. W. Boehm, ``A Spiral Model of Software Development and
Enhancement,'' IEEE Computer, vol. 21, pp. 61--72, May 1988.
F. P. Brooks, ``No Silver Bullet: Essence and Accidents of Software
Engineering,'' IEEE Computer, vol. 20, pp. 10--19, Apr. 1987.
T. Lindholm and F. Yellin, The Java Virtual Machine Specification.
D. C. Schmidt and T. Suda, ``An Object-Oriented Framework for Dynamically
Configuring Extensible Distributed Communication Systems,'' IEE/BCS
Distributed Systems Engineering Journal (Special Issue on Configurable
Distributed Systems), vol. 2, pp. 280--293, December 1994.
Object Management Group, The Common Object Request Broker: Architecture
and Specification, 2.3 ed., June 1999.
D. Box, Essential COM.
Addison-Wesley, Reading, MA, 1997.
A. Wollrath, R. Riggs, and J. Waldo, ``A Distributed Object Model for the Java
System,'' USENIX Computing Systems, vol. 9, November/December 1996.
BEA Systems, et al., CORBA Component Model Joint Revised
Object Management Group, OMG Document orbos/99-07-01 ed., July
J. A. Zinky, D. E. Bakken, and R. Schantz, ``Architectural Support for Quality
of Service for CORBA Objects,'' Theory and Practice of Object Systems,
vol. 3, no. 1, 1997.
E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software.
Reading, MA: Addison-Wesley, 1995.
D. C. Schmidt, M. Stal, H. Rohnert, and F. Buschmann, Pattern-Oriented
Software Architecture: Patterns for Concurrency and Distributed Objects,
New York, NY: Wiley & Sons, 2000.
D. Lea, Concurrent Java: Design Principles and Patterns, Second
Reading, MA: Addison-Wesley, 1999.
I. Pyarali, C. O'Ryan, D. C. Schmidt, N. Wang, V. Kachroo, and A. Gokhale,
``Using Principle Patterns to Optimize Real-time ORBs,'' Concurrency
Magazine, vol. 8, no. 1, 2000.
F. Kon, M. Roman, P. Liu, J. Mao, T. Yamane, L. Magalhaes, and R. Campbell,
``Monitoring, Security, and Dynamic Configuration with the dynamicTAO
Reflective ORB,'' in Proceedings of the Middleware 2000 Conference,
ACM/IFIP, Apr. 2000.