Two fundamental trends influence the way we conceive
and construct new computing and information systems. The first is that information
technology of all forms is becoming highly commoditized i.e., hardware and software artifacts are getting faster, cheaper,
and better at a relatively predictable rate.
The second is the growing acceptance of a network-centric paradigm,
where distributed applications with a range of quality of service (QoS) needs
are constructed by integrating separate components connected by various forms
of communication services. The nature
of this interconnection can range from
1. The very small and tightly coupled, such as avionics
mission computing systems to
2. The very large and loosely coupled, such as global
telecommunications systems.
The interplay of these two trends has yielded new
architectural concepts and services embodying layers of middleware. These layers are interposed between applications and
commonly available hardware and software infrastructure to make it feasible,
easier, and more cost effective to develop and evolve systems using reusable
software. Middleware stems from recognizing the need for more advanced and
capable support–beyond simple connectivity–to construct effective distributed
systems. A significant portion of
middleware-oriented R&D activities over the past decade have focused on
1. The identification, evolution, and expansion of our understanding
of current middleware services in providing this style of development and
2. The need for defining additional middleware layers and
capabilities to meet the challenges associated with constructing future
network-centric systems.
These
activities are expected to continue forward well into this decade to address
the needs of next-generation distributed applications.
During
the past decade we've also benefited from the commoditization of hardware (such
as CPUs and storage devices) and networking elements (such as IP routers). More
recently, the maturation of programming languages (such as Java and C++),
operating environments (such as POSIX and Java Virtual Machines), and enabling
fundamental middleware based on previous middleware R&D (such as CORBA,
Enterprise Java Beans, and .NET) are helping to commoditize many software
components and architectural layers.
The quality of commodity software has generally lagged behind hardware,
and more facets of middleware are being conceived as the complexity of
application requirements increases, which has yielded variations in maturity
and capability across the layers needed to build working systems. Nonetheless, recent improvements in
frameworks [John97], patterns [Gam95, Bus96, Sch00b], and development processes
[Beck00, RUP99] have encapsulated the knowledge that enables common
off-the-shelf (COTS) software to be developed, combined, and used in an
increasing number of real-world applications, such as e-commerce web sites,
consumer electronics, avionics mission computing, hot rolling mills, command
and control planning systems, backbone routers, and high-speed network
switches.
The
trends outlined above are now yielding additional middleware challenges and
opportunities for organizations and developers, both in deploying current
middleware-based solutions and in inventing and shaping new ones. To complete our overview, we summarize key
challenges and emerging opportunities for moving forward, and outline the role
that middleware plays in meeting these challenges.
·
Growing focus on integration rather than on
programming – There is an
ongoing trend away from programming applications from scratch to integrating
them by configuring and customizing reusable components and frameworks
[John97]. While it is possible in theory to program applications from scratch,
economic and organizational constraints–as well as increasingly complex
requirements and competitive pressures–are making it infeasible to do so in
practice. Many applications in the future will therefore be configured by
integrating reusable commodity hardware and software components that are
implemented by different suppliers together with the common middleware
substrate needed to make it all work harmoniously.
·
Demand for
end-to-end QoS support, not just component QoS – The need for autonomous and time-critical behavior
in next-generation applications necessitates more flexible system
infrastructure components that can adapt robustly to dynamic end-to-end changes
in application requirements and environmental conditions. For example,
next-generation applications will require the simultaneous satisfaction of
multiple QoS properties, such as predictable latency/jitter/throughput,
scalability, dependability, and security. Applications will also need different
levels of QoS under different configurations, environmental conditions, and
costs, and multiple QoS properties must be coordinated with and/or traded off
against each other to achieve the intended application results. Improvements in current middleware QoS and
better control over underlying hardware and software components–as well as
additional middleware services to coordinate these–will all be needed.
· The
increased viability of open systems
– Shrinking profit margins and increasing shareholder pressure to cut costs are
making it harder for companies to invest in long-term research that does not
yield short-term pay offs. As a result, many companies can no longer afford the
luxury of internal organizations that produce completely custom hardware and
software components with proprietary QoS support. To fill this void, therefore,
standards-based hardware and software researched and developed by third
parties–and glued together by common middleware–is becoming increasingly
strategic to many industries. This trend also requires companies to transition
away from proprietary architectures to more open systems in order to reap the
benefits of externally developed components, while still maintaining an ability
to compete with domain-specific solutions that can be differentiated and
customized. The refactoring of much domain-independent middleware into
open-source releases based on open standards is spurring the adoption of common
software substrates in many industries.
It is also emphasizing the role of domain knowledge in selecting,
organizing, and optimizing appropriate middleware components for requirements
in particular application domains.
·
Increased leverage for disruptive technologies leading
to increased global competition
– One consequence of the commoditization of larger bundled solutions based
around middleware-integrated components is that industries long protected by
high barriers to entry, such as telecom and aerospace, are more vulnerable to
disruptive technologies [Chris98] and global competition, which drive prices to
marginal cost. For example, advances in high-performance COTS hardware are
being combined with real-time and fault tolerant middleware services to
simplify the development of predictable and dependable network elements.
Systems incorporating these network elements, ranging from PBXs to high-speed
backbone routers–and ultimately carrier class switches and services built
around these components–can now use standard hardware and software components
that are less expensive than legacy proprietary systems, yet which are becoming
nearly as dependable.
·
Potential complexity cap for next-generation systems – Although current middleware solves a number of
basic problems with distribution and heterogeneity, many challenging research
problems remain. In particular,
problems of scale, diversity of operating environments, and required level of
trust in the sustained and correctly functioning operation of next-generation
systems have the potential to outstrip what can be built. Without significantly improved capabilities
in a number of areas, we may reach a point where the limits of our starting
points put a ceiling on the size and levels of complexity for future
systems. Without an investment in
fundamental R&D to invent, develop,
and popularize the new
middleware capabilities needed to realistically and cost-effectively
construct next-generation network-centric applications, the anticipated move
towards large-scale distributed “systems of systems” in many domains may not
materialize. Even if it does, it may do
so with intolerably high risk because of inadequate COTS middleware support for
proven, repeatable, and reliable solutions.
The additional complexity forced into the realm of application
development will only exacerbate the already high rate of project failures
exhibited in complex distributed system domains.
The preceding discussion outlines the fundamental
drivers that led to the emergence of middleware architectures and components in
the previous decade, and will of necessity lead to more advanced middleware
capabilities in this decade. We spend the rest of this paper exploring these
topics in more depth, with detailed evaluations of where we are, and where we
need to go, with respect to middleware.
2 How Middleware Addresses Distributed Application Challenges
Requirements
for faster development cycles, decreased effort, and greater software reuse
motivate the creation and use of middleware
and middleware-based architectures. Middleware is systems software that resides
between the applications and the underlying operating systems, network protocol
stacks, and hardware. Its primary role
is to
1.
Functionally bridge the gap between application programs and the
lower-level hardware and software infrastructure in order to coordinate how parts of applications
are connected and how they interoperate
and
2.
Enable and
simplify the integration of components developed by multiple technology
suppliers.
When implemented properly, middleware can help to:
· Shield software developers from low-level, tedious, and error-prone platform details, such as socket-level network programming.
· Amortize software lifecycle costs by leveraging previous development expertise and capturing implementations of key patterns in reusable frameworks, rather than rebuilding them manually for each use.
· Provide a consistent set of higher-level network-oriented abstractions that are much closer to application requirements in order to simplify the development of distributed and embedded systems.
· Provide a wide array of developer-oriented services, such as logging and security that have proven necessary to operate effectively in a networked environment.
2.1
Structure
and Functionality of DOC Middleware
Just as networking protocol stacks can be
decomposed into multiple layers, such as the physical, data-link, network,
transport, session, presentation, and application layers, so too can DOC
middleware be decomposed into multiple layers, such as those shown in Figure 1.
Figure
11.
Layers of DOC Middleware and Surrounding Context
Below, we describe each of
these middleware layers and outline some of the COTS technologies in each layer
that have matured and found widespread use in recent years.
Host
infrastructure middleware encapsulates and enhances native OS communication and
concurrency mechanisms to create reusable network programming components, such
as reactors, acceptor-connectors, monitor objects, active objects, and
component configurators [Sch00b, Sch01]. These components abstract away the
peculiarities of individual operating systems, and help eliminate many tedious,
error-prone, and non-portable aspects of developing and maintaining networked
applications via low-level OS programming APIs, such as Sockets or POSIX
pthreads. Widely used examples of host infrastructure middleware include:
·
The
Sun Java Virtual Machine (JVM) [JVM97], which provides a platform-independent way of executing code by
abstracting the differences between operating systems and CPU architectures.
A JVM is responsible for interpreting Java
bytecode, and for translating the bytecode into an action or operating system
call. It is the JVM’s responsibility to encapsulate platform details within the
portable bytecode interface, so that applications are shielded from disparate
operating systems and CPU architectures on which Java software runs.
·
.NET
[NET01] is Microsoft's platform for
XML Web services, which are designed to connect information, devices, and
people in a common, yet customizable way.
The common language runtime (CLR) is the host infrastructure middleware
foundation upon which Microsoft’s .NET services are built. The Microsoft CLR is
similar to Sun’s JVM, i.e., it
provides an execution environment that manages running code and simplifies
software development via automatic memory management mechanisms, cross-language
integration, interoperability with existing code and systems, simplified
deployment, and a security system.
· The ADAPTIVE Communication Environment (ACE) [Sch01]
is a highly portable toolkit written in C++ that encapsulates native operating
system (OS) network programming capabilities, such as connection establishment,
event demultiplexing, interprocess communication, (de)marshaling, static and
dynamic configuration of application components, concurrency, and
synchronization. The primary difference between ACE, JVMs, and the .NET CLR is
that ACE is always a compiled interface, rather than an interpreted bytecode
interface, which removes another level of indirection and helps to optimize
runtime performance.
Distribution
middleware defines higher-level
distributed programming models whose reusable APIs and components automate and
extend the native OS network programming capabilities encapsulated by host
infrastructure middleware. Distribution middleware enables clients to program
distributed applications much like stand-alone applications, i.e., by
invoking operations on target objects without hard-coding dependencies on their
location, programming language, OS platform, communication protocols and
interconnects, and hardware. At the heart of distribution middleware are
request brokers, such as:
· The OMG's Common Object Request Broker Architecture
(CORBA) [Omg00], which is an open standard for distribution middleware that allows objects to
interoperate across networks regardless of the language in which they were
written or the platform on which they are deployed. In 1998 the OMG adopted the
Real-time CORBA (RT-CORBA) specification [Sch00a], which extends CORBA with
features that allow real-time applications to reserve and manage CPU, memory,
and networking resources.
· Sun's Java Remote Method Invocation (RMI) [Wol96],
which is distribution middleware that enables developers to create distributed
Java-to-Java applications, in which the methods of remote Java objects can be
invoked from other JVMs, possibly on different hosts. RMI supports more
sophisticated object interactions by using object serialization to marshal and
unmarshal parameters, as well as whole objects. This flexibility is made possible by Java’s virtual machine
architecture and is greatly simplified by using a single language..
· Microsoft's Distributed Component Object Model (DCOM)
[Box97], which is distribution middleware that enables software components to communicate
over a network via remote component instantiation and method invocations. Unlike CORBA
and Java RMI, which run on many operating systems, DCOM is implemented
primarily on Windows platforms.
· SOAP [SOAP01] is an emerging distribution middleware
technology based on a lightweight and simple XML-based protocol that allows
applications to exchange structured and typed information on the Web. SOAP is
designed to enable automated Web services based on a shared and open Web
infrastructure. SOAP applications can be written in a wide range of programming
languages, used in combination with a variety of Internet protocols and formats
(such as HTTP, SMTP, and MIME), and can support a wide range of applications
from messaging systems to RPC.
Common
middleware services augment
distribution middleware by defining higher-level domain-independent services
that allow application developers to concentrate on programming business logic,
without the need to write the “plumbing” code required to develop distributed
applications by using lower-level middleware directly. For example, application
developers no longer need to write code that handles transactional behavior,
security, database connection pooling or threading, because common middleware
service providers bundle these tasks into reusable components. Whereas distribution middleware focuses largely on managing end-system
resources in support of an object-oriented distributed programming model,
common middleware services focus on allocating, scheduling, and coordinating
various resources throughout a distributed system using a component programming
and scripting model. Developers can reuse these component services to manage
global resources and perform common distribution tasks that would otherwise be
implemented in an ad hoc manner within each application. The form and
content of these services will continue to evolve as the requirements on the
applications being constructed expand.
Examples of common middleware services include:
· The OMG’s CORBA Common Object Services (CORBAservices)
[Omg98b], which provide domain-independent interfaces and capabilities that can
be used by many DOC applications. The
OMG CORBAservices specifications define a wide variety of these services,
including event notification, logging, multimedia streaming, persistence,
security, global time, real-time scheduling, fault tolerance, concurrency
control, and transactions.
· Sun’s Enterprise Java Beans (EJB) technology [Tho98],
which allows developers to create n-tier distributed systems by linking a
number of pre-built software services—called “beans”—without having to write
much code from scratch. Since EJB is
built on top of Java technology, EJB service components can only be implemented
using the Java language. The CORBA
Component Model (CCM) [Omg99] defines a superset of EJB capabilities that can
be implemented using all the programming languages supported by CORBA.
· Microsoft’s .NET Web services [NET01], which complements the lower-level middleware .NET capabilities, allows developers to package application logic into components that are accessed using standard higher-level Internet protocols above the transport layer, such as HTTP. The .NET Web services combine aspects of component-based development and Web technologies. Like components, .NET Web services provide black-box functionality that can be described and reused without concern for how a service is implemented. Unlike traditional component technologies, however, .NET Web services are not accessed using the object model–specific protocols defined by DCOM, Java RMI, or CORBA. Instead, XML Web services are accessed using Web protocols and data formats, such as the Hypertext Transfer Protocol (HTTP) and eXtensible Markup Language (XML), respectively.
Domain-specific
middleware services are tailored
to the requirements of particular domains, such as telecom, e-commerce, health
care, process automation, or aerospace. Unlike the other three DOC middleware
layers, which provide broadly reusable “horizontal” mechanisms and services,
domain-specific middleware services are targeted at vertical markets. From a
COTS perspective, domain-specific services are the least mature of the
middleware layers today. This immaturity is due partly to the historical lack
of distribution middleware and common middleware service standards,
which are needed to provide a stable base upon which to create domain-specific
services. Since they embody knowledge of a domain, however, domain-specific
middleware services have the most potential to increase system quality and
decrease the cycle-time and effort required to develop particular types of
networked applications. Examples of domain-specific middleware services include
the following:
· The OMG has convened a
number of Domain Task Forces that concentrate on standardizing domain-specific
middleware services. These task forces vary from the Electronic Commerce Domain Task Force, whose charter is to define
and promote the specification of OMG distributed object technologies for the
development and use of Electronic Commerce and Electronic Market systems, to
the Life Science Research Domain Task
Force, who do similar work in the area of Life Science, maturing the OMG
specifications to improve the quality and utility of software and information
systems used in Life Sciences Research. There are also OMG Domain Task Forces
for the healthcare, telecom, command and control, and process automation
domains.
· The Siemens Medical Engineering
Group has developed Syngo(R), which is both an integrated
collection of domain-specific middleware services, as well as an open and
dynamically extensible application server platform for medical imaging tasks
and applications, including ultrasound, mammography, radiography, flouroscopy,
angiography, computer tomography, magnetic resonance, nuclear medicine, therapy
systems, cardiac systems, patient monitoring systems, life support systems, and
imaging- and diagnostic-workstations. The Syngo(R) middleware services allow healthcare facilities to integrate
diagnostic imaging and other radiological, cardiological and hospital services
via a blackbox application template framework based on advanced patterns for
communication, concurrency, and configuration for both business logic and
presentation logic supporting a common look and feel throughout the medical
domain.
· The Boeing Bold Stroke [Sha98, Doe99] architecture
uses COTS hardware and middleware to produce a non-proprietary, standards-based
component architecture for military avionics mission computing capabilities,
such as navigation, display management, sensor management and situational
awareness, data link management, and weapons control. A driving objective of
Bold Stroke was to support reusable product line applications, leading to a
highly configurable application component model and supporting middleware
services. Associated products ranging from single processor systems with O(105)
lines of source code to multi-processor systems with O(106) lines of
code have shown dramatic affordability and schedule improvements and have been
flight tested successfully. The domain-specific middleware services in Bold
Stroke are layered upon common middleware services (the CORBA Event Service),
distribution middleware (Real-time CORBA), and host infrastructure middleware
(ACE), and have been demonstrated to be highly portable for different COTS
operating systems (e.g. VxWorks), interconnects (e.g. VME), and processors
(e.g. PowerPC).