Patterns, Frameworks, and Middleware:

Their Synergistic Relationships

Douglas C. Schmidt Frank Buschmann

[email protected] [email protected]
Electrical Engineering & Computer Science Corporate Research
Vanderbilt University Siemens, AG
Nashville Tennessee, USA Munich, Germany

Abstract time and within budget remains hard. Some problems stem
from the growing demands placed on software, such as re-
The knowledge required to develop complex software has his- quirements to provide predictable, reliable, scalable, and se-
torically existed in programming folklore, the heads of experi- cure quality of service (QoS) simultaneously. Other problems
enced developers, or buried deep in the code. These locations stem from the propensity to rediscover and reinvent core soft-
are not ideal since the effort required to capture and evolve ware artifacts, such as programming languages, operating sys-
this knowledge is expensive, time-consuming, and error-prone. tems, networking protocols, and software component libraries.
Many popular software modeling methods and tools address Moreover, the heterogeneity of hardware architectures, diver-
certain aspects of these problems by documenting how a sys- sity of operating system (OS) and network platforms, and stiff
tem is designed. However, they only support limited portions global competition makes it increasingly infeasible to build
of software development and do not articulate why a system high-quality software from scratch.
is designed in a particular way, which complicates subsequent
software reuse and evolution. In today’s time-to-market-driven environments, building
Patterns, frameworks, and middleware are increasingly quality software in cost-effective manner requires the system-
popular techniques for addressing key aspects of the chal- atic reuse of successful software models, designs, and imple-
lenges outlined above. Patterns codify reusable design ex- mentations that have already been developed and tested. Un-
pertise that provides time-proven solutions to commonly oc- like opportunistic reuse (in which developers simply cut and
curring software problems that arise in particular contexts paste code from existing programs to create new ones), sys-
and domains. Frameworks provide both a reusable product- tematic reuse is an intentional and concerted effort to create
line architecture [1] – guided by patterns – for a family of and apply multiuse software artifacts throughout an organi-
related applications and an integrated set of collaborating zation. In a well-honed systematic reuse process, each new
components that implement concrete realizations of the ar- project leverages time-proven designs and implementations,
chitecture. Middleware is reusable software that leverages mostly just adding new code that is specific to a particular ap-
patterns and frameworks to bridge the gap between the func- plication, and only refactoring existing software architectures
tional requirements of applications and the underlying oper- and designs when they become inadequate to cover the evolv-
ating systems, network protocol stacks, and databases. This ing business cases and variability in the supported domains.
paper presents an overview of patterns, frameworks, and mid- Systematic reuse is essential to increase software productiv-
dleware, describes how these technologies complement each ity and quality by breaking the costly cycle of rediscover-
other to enhance reuse and productivity, and then illustrates ing, reinventing, and revalidating common software artifacts.
how they have been applied successfully in practice to improve Throughout the rest of the paper when we use the term “reuse”
the reusability and quality of complex software systems. we therefore always mean “systematic reuse.”
The skills required to develop, deploy, and support reusable
software have traditionally been a “black art” practiced only
1 Introduction by expert developers and architects. Moreover, these techni-
cal impediments to reuse are often exacerbated by a myriad of
Emerging trends and challenges. Despite significant ad-
nontechnical impediments, such as organizational, economic,
vances in computers, networks, programming languages, and
administrative, political, sociological, and psychological fac-
software methodologies, developing quality applications on
tors. It’s therefore not surprising that significant levels of soft-
 This work was supported in part by DARPA, NSF, and Siemens. ware reuse have been slow to materialize in many projects and
organizations. and patterns support the development of product-line archi-
tectures for specific application domains, such as warehouse
Solution approach ! Middleware, framework, and pat- management or hot rolling mill process automation [14], that
terns. Middleware [2] is software that can significantly in- apply particular types of middleware. A contribution of this
crease reuse by providing readily usable, standard solutions paper is to illustrate by examples how these three technologies
to common programming tasks, such as persistent storage, relate and complement each other.
(de)marshaling, message buffering and queueing, request de- Paper organization. The remainder of this paper is orga-
multiplexing, and concurrency control. Developers who use nized as follows: Section 2 presents an taxonomy of the layers
middleware can therefore focus primarily on application- of middleware; Sections 3 and 4 describe the key properties
oriented topics, such as business logic, rather than wrestling of frameworks and patterns, respectively; Section 5 then illus-
with tedious and error-prone details associated with program- trates the synergies between all three technologies via a case
ming infrastructure software using lower-level OS APIs and study of how frameworks and patterns have been applied in
mechanisms. practice to develop middleware for distributed real-time and
Over the past decade a number of middleware standards embedded systems; Section 6 summarizes promising areas of
have emerged and matured. Some of these standards, such as future R&D; and Section 7 presents concluding remarks.
the Common Object Request Broker Architecture (CORBA),
are open systems sanctioned by international organizations,
such as the Object Management Group (OMG). Other middle- 2 An Overview of Middleware
ware standards, such as Java virtual machines, Jave 2 Enter-
prise Edition (J2EE), and .NET, have emerged from industry Some of the most successful techniques and tools devised to
consortia and market leaders. enhance the reuse of software center on middleware that helps
Crucial to the success of standard middleware are the pat- manage the complexity and heterogeneity of distributed appli-
terns [3, 4, 5] and frameworks [6, 7] that reify the knowledge cations. This distributed computing middleware (henceforth
of how to develop and apply the middleware and applications referred to simply as middleware) provides reusable software
that run atop it. Patterns support the reuse of design expertise that functionally bridges the gap between (1) end-to-end ap-
by articulating the static and dynamic aspects of successful plication functional requirements and (2) the lower-level op-
solutions to problems that arise when building software in a erating systems, networking protocol stacks, databases, and
particular context. Frameworks are concrete realizations of hardware devices. Middleware provides reusable capabilities
groups of patterns that enable reuse of code by (1) captur- whose qualities are critical to help simplify and coordinate
ing the common abstractions of an application domain – both how application software is connected and how it interoper-
their structure and mechanisms – while (2) yielding control of ates.
application-specific structure and behavior to application de- Just as networking protocol stacks can be decomposed into
velopers. multiple layers, such as the physical, data-link, network, trans-
During the past decade a number of influential R&D ef- port, session, presentation, and application layers, so to can
forts [4, 8, 5, 9, 10, 11, 12, 13] have focused on documenting middleware be decomposed into the multiple layers [2] shown
patterns and developing frameworks that enable the effective in Figure 1 and described in the remainder of this section.
development and reuse of middleware. As a result, middle- Host infrastructure middleware encapsulates and enhances
ware is now commonly developed using frameworks based on native OS mechanisms to create reusable event demultiplex-
strategized composition and optimization patterns. These pat- ing, interprocess communication, concurrency, and synchro-
terns and frameworks guide the integration and configuration nization objects, such as reactors; acceptors, connectors, and
of middleware that can meet the functional and QoS require- service handlers; monitor objects; active objects; and service
ments of particular application domains more effectively than configurators [9, 10]. By encapsulating the peculiarities of
can realistically be developed manually from scratch in time- particular operating systems, these reusable objects help elim-
to-market driven environments. inate many tedious, error-prone, and non-portable aspects of
The relationship between middleware, frameworks, and pat- developing and maintaining application software via low-level
terns is highly synergistic. For example, patterns help guide OS programming APIs, such as Sockets or POSIX pthreads.
framework design and use, thereby reducing software devel- Common host infrastructure middleware includes the Sun
opment effort and training costs. In turn, frameworks can be Java Virtual Machine (JVM) and Microsoft’s Common Lan-
used to develop middleware for product-line architectures [1], guage Runtime (CLR), which provide platform-independent
whose interfaces then provide application software with a sim- ways of executing code by abstracting the differences be-
pler facade to access the powerful (and complex) internal com- tween operating systems and CPU architectures. The ADAP-
ponent structure of the frameworks. Likewise, frameworks TIVE Communication Environment (ACE) [9, 10] is portable
 middleware service providers bundle transactional behavior,
APPLICATIONS
security, and database connection pooling and threading into
reusable components, so that application developers no longer
DOMAIN-SPECIFIC HUD AVIONICS need to write code that handles these tasks.
MIDDLEWARE WTS REPLICATION
SERVICES Nav SERVICE Whereas distribution middleware focuses largely on manag-
ing end-system resources in support of an object-oriented dis-
COMMON Cons
EVENT Cons tributed programming model, common middleware services
MIDDLEWARE CHANNEL
SERVICES Cons focus on allocating, scheduling, and coordinating various re-
sources throughout a distributed system using a component
DISTRIBUTION programming and scripting model. Developers can reuse these
MIDDLEWARE component services to manage global resources and perform
common distribution tasks that would otherwise be imple-
HOST
INFRASTRUCTURE mented in an ad hoc manner within each application. The form
MIDDLEWARE and content of these services will continue to evolve as the re-
quirements on the applications being constructed expand.
OPERATING Examples of common middleware services include the
SYSTEMS
OMG’s CORBA Common Object Services, such as event no-
HARDWARE tification, logging, multimedia streaming, persistence, secu-
DEVICES rity, global time, real-time scheduling, fault tolerance, con-
currency control, and transactions. Likewise, Sun’s Enterprise
Figure 1: Middleware Layers in Context
Java Beans (EJB) technology and Microsoft’s .NET allows de-
velopers to create n-tier distributed systems by linking a num-
C++ host infrastructure middleware that encapsulates na- ber of pre-built software service components without having
tive operating system capabilities, such as connection estab- to write much code manually.
lishment, event demultiplexing, interprocess communication, Domain-specific middleware services are tailored to the
(de)marshaling, dynamic configuration of application compo- requirements of particular domains, such as telecom, e-
nents, concurrency, and synchronization. commerce, health care, process automation, or aerospace. Un-
like the other three middleware layers discussed above that
Distribution middleware defines higher-level distributed pro-
provide broadly reusable “horizontal” mechanisms and ser-
gramming models whose reusable APIs and objects automate
vices, domain-specific middleware services are targeted at
and extend the native OS mechanisms encapsulated by host
“vertical” markets and product-line architectures. Since they
infrastructure middleware. Distribution middleware enables
embody knowledge of a domain, moreover, reusable domain-
clients to program applications by invoking operations on tar-
specific middleware services have the most potential to in-
get objects without hard-coding dependencies on their loca-
crease the quality and decrease the cycle-time and effort re-
tion, programming language, OS platform, communication
quired to develop particular types of application software.
protocols and interconnects, and hardware.
An example of domain-specific middleware services in-
At the heart of distribution middleware are request bro- cludes the Siemens Medical Solutions Group has developed
kers, such as The OMG’s Common Object Request Broker syngo (www.syngo.com), which is a product-line archi-
Architecture (CORBA) and Sun’s Java Remote Method Invo- tecture that is both an integrated collection of domain-specific
cation (RMI). The request brokers allow objects to interoper- middleware services, as well as an open and dynamically ex-
ate across networks regardless of the platform on which they tensible application server platform for medical imaging tasks
are deployed. SOAP is an emerging distribution middleware and applications, including ultrasound, mammography, an-
technology based on an XML-based protocol that allows ap- giography, computer tomography, magnetic resonance, and
plications to exchange structured and typed information on the nuclear medicine. The Boeing Bold Stroke [15, 16] product-
Web using various Internet protocols, such as HTTP, SMTP, line architecture is another example of domain-specific mid-
and MIME. dleware. Bold Stroke uses COTS hardware and middleware
Common middleware services augment distribution middle- to produce a non-proprietary, standards-based component ar-
ware by defining higher-level domain-independent reusable chitecture for military avionics mission computing capabili-
services that allow application developers to concentrate on ties, such as navigation, display management, sensor manage-
programming business logic, without the need to write the ment and situational awareness, data link management, and
“plumbing” code required to develop distributed applications weapons control.
via lower-level middleware directly. For example, common As the products associated with the reusable middleware
layers summarized above have matured and become perva- EVENT
NETWORKING
sive throughout the industry, the total amount of software that LOOP

application developers must write has shrunk substantially. CALLBACKS

However, reduction in application developer effort also im- GUI

APPLICATION- DOMAIN-SPECIFIC
plies more work for middleware developers since they be- CALL
SPECIFIC BACKS FRAMEWORK
come responsible for an increasing number of software lay- EVENT
FUNCTIONALITY CAPABILITIES
ers. While some believe that the techniques used to de- LOOP
velop reusable middleware are simply implementation details, CALLBACKS
in practice these choices have a significant impact on other EVENT
key middleware qualities, such as its affordability, extensibil- DATABASE LOOP

ity, flexibility, portability, predictability, efficiency, reliability,

scalability, and trustworthiness.
Figure 2: Relationships Between Framework Components
As a result, middleware developers must themselves apply
more powerful reuse technologies to simplify the evolution of
their software layers. Not surprisingly, frameworks and pat- help them to achieve these qualities.1
terns are increasingly applied to improve the reusability and  A framework exhibits “inversion of control” at run
quality of both middleware and application software. The re- time via callbacks to component hook methods af-
mainder of this paper presents overviews of frameworks and ter the occurrence of an event, such as a mouse click
patterns and then shows how these technologies can be com- or data arriving on a network connection. When an
bined with middleware to enhance software reuse. It is impor- event occurs, the framework calls back to a virtual hook
tant to note, however, that the reuse potential of frameworks method in a pre-registered component, which then per-
and patterns is not limited to middleware! forms application-defined processing in response to the
event. The virtual hook methods in the components de-
couple the application software from the reusable frame-
3 Overview of Frameworks work software, which makes it easier to extend and cus-
tomize the applications as long as the interaction proto-
As outlined in the previous section, in today’s competitive, cols and QoS properties are not violated.
fast-paced computing industry, successful middleware and ap-  A framework provides an integrated set of domain-
plication software must possess (1) affordability, to ensure specific structures and functionality. Reuse of software
that the total ownership costs of software acquisition and evo- depends largely on how well frameworks model the com-
lution are not prohibitively high, (2) extensibility, to support monalities and variabilities [19] in application domains,
successions of quick updates and additions to address new re- such as business data processing, telecom call process-
quirements and take advantage of emerging markets, (3) flex- ing, graphical user interfaces, or real-time middleware.
ibility, to support a growing range of multimedia data types, By leveraging the domain knowledge and prior efforts
traffic flows, and end-to-end QoS requirements, (4) portabil- of experienced developers, frameworks embody common
ity, to reduce the effort required to support applications on solutions to recurring application requirements and soft-
heterogeneous OS platforms and compilers, (5) predictability ware design challenges that need not be recreated and
and efficiency, to provide low latency to delay-sensitive real- revalidated for each new application.
time applications, high performance to bandwidth-intensive  A framework is a “semi-complete” application that
applications, and usability over low-bandwidth networks, such programmers can customize to form complete applica-
as wireless links, (6) reliability, to ensure that applications are tions by extending reusable components in the frame-
robust and tolerant of faults, (7) scalability, to enable applica- work. In particular, frameworks help abstract the canoni-
tions to handle large numbers of clients simultaneously, and cal control flow of applications in a domain into product-
(8) trustworthiness, to ensure integrity, confidentiality, and line architectures and families of related components. At
availability in distributed systems. runtime, these components can collaborate to integrate
When software is developed monolithically, i.e., as tightly customizable application-independent reusable code with
coupled clumps of functionality that are not organized mod- customized application-defined code.
ularly or hierarchically, it is hard to achieve these qualities.
Frameworks [6, 7] have emerged as a powerful technology for Since frameworks exhibit inversion of control, they can sim-
developing and reusing middleware and application software 1 While there are subtle technical distinctions between frameworks and
that possess the qualities listed above. Figure 2 illustrates the components [18, 10], we subsume components into the discussion of frame-
three characteristics of frameworks [17] described below that works below.
plify application design because the framework—rather than not documented, they will be lost over time and thus can-
the application—runs the event loop to detect events, demul- not be used to guide subsequent software evolution.
tiplex events to event handlers, and dispatch hook methods  Without guidance from earlier work, software developers
on the handlers that process the events. Since frameworks must engineering complex systems from the ground up,
reify the key roles and relationships of components in appli- rather than by reusing proven solutions.
cation domains, the amount of reusable code increases and the Over the past decade, experienced software developers and
amount of code rewritten for each application decreases dra- architects have helped to address these problems by creating
matically. Since a framework is a semi-complete application, a body of literature that documents the following types of
it enables larger-scale reuse of software than can be achieved reusable knowledge:
by reusing individual components or stand-alone functions.
 Design patterns [3], which provide a scheme for refining
Developers in certain domains have applied frameworks
the elements of a software system and the relationships
successfully for several decades. Early frameworks, such as
between them, and describe a common structure of com-
MacApp, X-windows, and Interviews, originated in the do-
municating elements that solves a general design problem
main of graphical user interfaces (GUIs). Java Swing and
within a particular context.
Microsoft Foundation Classes (MFC) are contemporary GUI
frameworks that are widely used to create graphical applica-
 Architectural patterns [4], which express the funda-
tions on PC platforms. The broad adoption of reusable GUI mental, overall structural organization of software sys-
tems and provide a set of predefined subsystems, specify
frameworks has yielded many productivity and quality bene-
their responsibilities, and include guidelines for organiz-
fits for business and desktop applications.
ing the relationships between them.
Building upon their success in the GUI domain, frameworks
 Pattern languages [21], which weave together a web of
are now being applied to many new and more complex do-
related patterns to define a vocabulary for talking about
mains [6, 7, 20]. For example, ACE and TAO described in
software development problems and provide a process for
Section 5.1 are frameworks for host infrastructure and dis-
the orderly resolution of these problems.
tribution middleware, JBoss and BEA’s WebLogic Server are
component frameworks for application servers, and many re- Patterns help enhance reuse by capturing and reusing the
cent R&D efforts, such as the Open Grid Service Infrastructure static and dynamic structure and collaboration of key par-
(OGSI), focus on frameworks for web services. There are also ticipants in software designs. They are particularly useful
frameworks for specific application domains, such as SAP, and for documenting recurring micro-architectures, which are ab-
application frameworks for medical imaging systems, such stractions of software components that experienced developers
as the Syngo platform. These frameworks are increasingly apply to resolve common design and implementation prob-
aligning with the layers of middleware standards and domain- lems. By studying and applying patterns and pattern lan-
specific product-line architectures discussed in Section 2. guages, developers can often escape traps and pitfalls that have
been avoided traditionally only via long and costly apprentice-
ships [22]. Patterns also raise the level of discourse in project
4 Overview of Patterns design and programming activities, which helps improve team
productivity and software quality.
Developers of middleware and application software must ad- Figure 3 illustrates the relationships amongst a pattern lan-
dress many challenges related to complex design and program- guage [5] that addresses service access and configuration,
ming topics, such as persistence, data organization, connection event handling, interprocess communication, concurrency, and
management, service initialization, distribution, concurrency synchronization dimensions in various networked applica-
control, flow control, error handling, event loop integration, tion domains, such as online financial services, remote pro-
and dependability. Many of these challenges occur repeatedly cess control, avionics mission computing, and telecommuni-
in many applications and domains. Until the mid-1990’s, the cations.2 The relationships in this diagram reveal the follow-
knowledge needed to resolve these challenges existed largely ing ways in which the patterns complement and complete each
in programming folklore, the heads of expert researchers and other in multiple ways to form a pattern language:
developers, or buried deep in complex source code. These lo-  Although each pattern is useful in isolation, the pattern
cations are not ideal because language is even more powerful, because it integrates so-
 Discovering patterns from source code is expensive and lutions to particular problems in important technical ar-
time-consuming since it is hard to separate the essence of eas, such as event handling, connection management and
a design from its implementation details. 2 Since it is beyond the scope of this paper to describe each pattern in detail,

 If the insights and rationale of experienced designers are please see the references [5] for comprehensive coverage of these patterns.
 Thread-per Active resolving a given problem, how are mutual dependencies be-
Acceptor
Request Object tween the problems handled, and how is each individual prob-
lem resolved effectively in the presence of its associated prob-
Thread-per
Session Connector lems.
Half-Sync/ Many pattern languages exist today. Some support the cre-
Thread Half-Async Component ation of a specific types of software, such as the pattern lan-
Pool Configurator guages for networked and concurrent computing [5] and enter-
prise application architectures [13]. Others pattern languages
Thread Leader/ Object help to realize a certain part, subsystem, or large component
Specific Followers Lifetime of a software system. For instance, there is a pattern language
Storage Manager for server components [12] that describes how to build well-
structured server-side components. Yet other languages focus
Asynchronous Reactor
Completion Double Thread- on a particular problem area of relevance in software, such as
Token Checked Safe handling erroneous user input [24] and designing user-friendly
Proactor Locking Interface interfaces to computer and information systems [25]. There
are also pattern languages for good programming style and
External Wrapper Scoped Strategized practice, such as Smalltalk best practice patterns [26], C++
Polymorphism Facade Locking Locking reference accounting [27], and Java exception handling [28].
Section 6 describes other key areas where we expect future
pattern languages will be published.
Concurrency Event Initialization Synchronization
Patterns Patterns Patterns Patterns
5 Illustrating the Synergies of Middle-
Figure 3: A Pattern Language for Network Programming
ware, Frameworks, and Patterns
service access, concurrency models, and synchronization Sections 2–4 present overviews of middleware, frameworks,
strategies. Each problem in these areas must be resolved and patterns, emphasizing their particular contributions to
coherently and consistently when developing concurrent software reuse. This section examines these technologies in
and networked applications. terms of their relationships and synergies. To make the dis-
 The pattern language also exposes the interdependencies cussion tangible, we focus on The ACE ORB (TAO) [29] as a
of these technical areas. For example, when selecting a case study to illustrate how patterns and frameworks can help
particular event-handling pattern for a networked appli- middleware developers build and evolve software by reducing
cation, not all potentially-available concurrency patterns the coupling between its components.
can be applied usefully.
 A pattern language describes an entire solution space for 5.1 Overview of CORBA and TAO
developing a particular type of system, system part, or
system aspect – by offering alternative solutions to cer- CORBA Object Request Brokers (ORBs) [30] allow clients to
tain problems. A pattern language can therefore be ap- invoke operations on distributed objects without concern for
plied many, many times without ever producing exactly object location, programming language, OS platform, commu-
the same architecture, design, or implementation. Yet nication protocols and interconnects, and hardware. Figure 4
each individual architecture, design, and implementation illustrates the components in the CORBA reference model,
follows the same timeless, thus reusable, design knowl- which collaborate to provide the portability, interoperability,
edge embedded in each pattern language [23]. and transparency mentioned above. The client stubs marshal
client operations into General Inter-ORB Protocol (GIOP) re-
These three points become clear only when connecting pat- quests that are transmitted to objects via the standard Internet
terns into a pattern language since each pattern in isolation
Inter-ORB Protocol (IIOP)3 implemented in the ORB Core.
only focuses on itself. In contrast, a pattern language-based The server ORB Core demultiplexes and receives these re-
design integrates the patterns consistently and synergistically quests using one or more threads and passes them to the Ob-
by giving concrete and precise guidance in developing a spe-
ject Adapter. The Object Adapter demultiplexes the requests
cific (type of) system or system aspect. In particular, a pattern to skeletons, which demarshal the requests and dispatch the
language conveys what are the key problems to be resolved, in
what order should they be tackled, what alternatives exist for 3 IIOP is implemented atop TCP/IP.
 in args CLIENT OBJECT/SERVANT
operation() OBJECT
CLIENT OBJ
(SERVANT)
REF out args + return STUB ADAPTER SKEL
value

PROXY MANAGER
IDL
SKELETON
DSI
DII IDL ORB OBJECT <<CREATES HANDLERS>>
ORB CORE <<CREATES HANDLERS>>
STUBS
INTERFACE ADAPTER
LEADER/
CONNECTOR FOLLOWERS
ORB CORE GIOP/IIOP/ESIOPS ACCEPTOR

STANDARD INTERFACE STANDARD LANGUAGE MAPPING REACTOR <<DISPATCHES>>

<<CONTAINS>>
ORB-SPECIFIC INTERFACE STANDARD PROTOCOL
STRATEGY <<CONTAINS>>

Figure 4: Components in the CORBA Reference Model

ABSTRACT COMPONENT
<<CREATES>> <<LINKS>> CONFIGURATOR
FACTORY
appropriate application-level servant method that implements
WRAPPER FACADES
the object’s operation.
OS KERNEL <<ENCAPSULATES>> OS KERNEL
The ACE ORB (TAO) [29] is a high-performance, real-time
implementation of the CORBA 3.0 specification [31] that sup- Figure 5: The Patterns Used in TAO
ports the distribution middleware capabilities shown in Fig-
ure 4 and described in Section 2. TAO is targeted for appli-
cations with deterministic and statistical QoS requirements, The key patterns used in the TAO ORB are shown in Fig-
as well as best effort requirements. As its name suggests, ure 5 and described below:
TAO is developed using the frameworks and components in  The Wrapper Facade pattern [5] simplifies the OS sys-
the ACE host infrastructure middleware. ACE and TAO are tem programming interface by combining multiple re-
open-source software that has evolved organically over the lated OS mechanisms, such as the socket API or POSIX
past decade. They are used in hundreds of production software threads, into cohesive OO abstractions. TAO uses this
systems in research labs and commercial projects, includ- pattern to enhance its reuse by encapsulating the te-
ing avionics mission computing systems at Boeing, satellite dious, non-portable, and non-typesafe low-level OS sys-
communication systems at Lockheed and Raytheon, telecom- tem functions within C++ classes.
munication systems at BBN, Cisco, Lucent, Motorola, Nor-  The Reactor pattern [5] allows event-driven applications
tel, and Siemens, medical systems at GE, and online trad- to react to events originating from a number of disparate
ing systems at Automated Trading Desk. Complete source sources, such as I/O handles, timers, and signals. TAO
code and documentation for ACE and TAO is available at uses this pattern to dispatch ORB connection and I/O
www.cs.wustl.edu/˜schmidt/TAO/. handlers in response to events that occur in the OS kernel.
 The Acceptor-Connector pattern [5] decouples the con-
nection and initialization of cooperating peer services in
5.2 Applying Patterns and Frameworks to TAO a networked application from the processing they per-
Middleware form after being connected and initialized. TAO uses this
pattern in its ORB Core to actively/passively establish
The interfaces, protocols, and components shown in Figure 4 connections and create I/O handlers that exchange GIOP
illustrate the primary capabilities provided by the CORBA ref- messages independently of the underlying transports.
erence architecture. As is often the case with architectural di-  The Leader Followers pattern [5] provides an effi-
agrams, however, it is not clear from this figure how the archi- cient concurrency model where multiple threads take
tecture behaves or why the architecture is designed the way it turns calling a synchronous event demultiplexer (such as
is. Naturally, a thorough understanding of these issues is es- select()) on sets of I/O handles to detect, demulti-
sential to develop, configure, optimize, and evolve the reusable plex, dispatch, and process service requests that occur.
middleware effectively. To address these issues, we outline the TAO uses this pattern to improve its performance and pre-
key patterns and frameworks used by TAO’s ORB Core to il- dictability by reducing context switching, synchroniza-
lustrate the synergies between these two reuse technologies in tion, and data allocation/movement overhead.
terms of improving the extensibility, maintainability, and per-  The Strategy pattern [3] provides a means to select one
formance of distribution middleware. of several candidate policies or algorithms and packaging
 it with an object. This pattern is the foundation of TAO’s CLIENT OBJECT/SERVANT

extensible software architecture and makes it possible to 3: run()

configure custom ORB strategies for connection manage-
ment, concurrency, and demultiplexing.
 The Abstract Factory pattern [3] provides a single com- 4: operation() ORB CORE 9: DISPATCH()
ponent that builds related objects. TAO uses this pattern GIOP
GIOP
to create and consolidate its many strategy objects into a Handler
Handler
GIOP
Connection Handler
manageable number of abstract factories that can be re-
Handler Connection
configured en masse into its ORB Core conveniently and GIOP 8: REQUEST/ Connection
Handler RESPONSE
Connection
HandlerHandler
0..N
consistently. TAO components use these factories to ac- Handler
cess related strategies without explicitly specifying their Cached 7: CREATE & ACTIVATE
Connect 5: connect() 6: accept()
subclass name. Strategy
 The Component Configurator pattern [5] permits dy- Strategy
namic run-time configuration of abstract factories and Acceptor
Strategy
strategies in an ORB [5]. TAO uses this pattern to dy- Connector
Reactor
namically link the abstract factories that produce custom
ORB personalities, such as a high-throughput ORB, a Service 1: process svc.conf file
predictable real-time ORB, or a small footprint ORB. Configurator 2: configure ORBs accordingly
 The Proxy pattern [4, 3] defines a object (the proxy) that svc.conf dynamic ORB Service_Object *
acts as surrogate for a (potentially remote) target object. FILE tao.dll:make_rtorb() "-ORBport 2001"
TAO uses this pattern to perform the (de)marshaling op-
erations defined by CORBA stubs. Figure 6: The ACE Frameworks Used in TAO
 The Adapter pattern [3] allows objects to work together
that have different interfaces. TAO uses this pattern in its
object adapters and skeletons to integrate object imple- in TAO, which accepts connections and receives/sends
mentations (servants) with the reusable ORB code. An client GIOP requests/responses via a pool of threads.
object adapter also implements the Manager pattern [4]
to control the lifecycle of the objects and servants it con-  The Acceptor-Connector framework leverages the
tains. Reactor framework and implements the Acceptor-
Connector and Strategy patterns to decouple the active
Knowing the patterns used in TAO is useful since it enables and passive initialization roles from application-defined
reuse of abstract design and architecture knowledge. However, service processing performed by communicating peer
reuse of patterns alone is insufficient since it does not directly services after initialization is complete. This ACE frame-
yield flexible and efficient software. We therefore found it nec- work enhances reuse by defining (1) strategy connec-
essary to augment our study of patterns with the creation and tor objects that automatically establish connections with
use of the frameworks provided by ACE. These frameworks servers and initialize handlers that transmit GIOP re-
help developers of TAO middleware avoid costly reinvention quests and (2) strategy acceptor objects that automati-
of common software artifacts by refactoring recurring imple- cally accept connections from clients and initialize han-
mentation roles. They also provide direct knowledge transfer dlers that process GIOP requests from clients.
by embodying patterns in a powerful toolkit that contains mid-
dleware domain experience and working code.  The Service Configurator framework implements the
The primary ACE frameworks used in TAO’s ORB Core Component Configurator pattern to support the flexible
are shown in Figure 6. Below, we describe each framework, configuration of ORBs whose strategies can be deter-
outline which pattern(s) it implements, and discuss how it en- mined and deployed at the appropriate time in the de-
hances reuse. sign cycle, e.g., via the svc.conf configuration script
 The Reactor framework implements the Reactor and at installation time and/or run time. This framework en-
Leader/Followers patterns to facilitate a concurrency hances reuse by enabling ORB abstract factories (and the
model where events indicating the ability to begin I/O strategies they embody) to be treated as interchangeable
operations. This framework enhances reuse in TAO by building blocks. Software with high availability require-
automating the detection, demultiplexing, and dispatch- ments, such as online transaction processing or real-time
ing of handlers in response to I/O, timer, and signal industrial process automation, often require these flexible
events. The ACE Reactor drives the main event loop configuration capabilities.
 The design of the ACE frameworks presented above is  Middleware codifies this expertise in the form of inter-
guided by many of the patterns shown in Figures 3 and 5. faces and standard components that provide applications
TAO uses these patterns and the ACE frameworks that reify with a simpler facade to access the powerful (and com-
them to develop an extensible ORB architecture. However, plex) internal component structure of frameworks.
the patterns and frameworks described here are not limited to For example, as shown in our case study above, TAO middle-
middleware. In fact, they have been applied in many other ware developers are more effective since the frameworks in
application domains, including telecom call processing [32] ACE implement the core patterns associated with service ac-
and switching [8], airplane flight control systems [15], multi- cess and configuration, event handling, interprocess commu-
media videoconferencing [33], distributed interactive simula- nication, concurrency, and synchronization.
tions [34], and enterprise business applications [20]. It is important to recognize that middleware, frameworks,
The patterns described above help to solve many common and patterns are highly synergistic concepts, with none subor-
problems that arise when developing and using frameworks dinate to the other [18]. Patterns can be characterized as more
for middleware and applications. In the context of TAO, for abstract descriptions of frameworks, which are often indepen-
example, a deep understanding of these patterns helps to dent of a particular programming language, operating system,
 Preserve important design information for developers network, or database environment. Patterns have been used to
who enhance and maintain the TAO middleware. Since document frameworks and middleware. Sophisticated middle-
scores of developers have worked on TAO over the past ware frameworks are concrete realizations of groups of dozens
decade, this information would be lost if it was not doc- to hundreds of patterns. A framework also integrates various
umented, which would increase software entropy and de- approaches to problems where there are no a priori context-
crease software maintainability and quality. The metrics independent and optimal solutions.
reported in [35] quantify the extent to which knowledge
of patterns helped to reduce the development and mainte-
nance effort for TAO.
6 Future R&D Focus Areas
 Guide design choices for developers who are building Over the past decade, R&D on patterns, frameworks, and mid-
new middleware and applications using TAO. The books dleware has focused largely on developing and refining the
in which the patterns outlined above appear document core concepts and infrastructure that can create the founda-
the common traps and pitfalls of developing middleware. tions for subsequent efforts [6, 7]. As a result of these ad-
This information helps TAO developers select suitable ar- vances, we expect the next generation of middleware will be
chitectures, protocols, algorithms, and platform features developed using frameworks that consciously embody time-
without wasting time and effort (re)implementing solu- proven patterns. Patterns will also increasingly be used to doc-
tions that have been shown to be inefficient or error prone. ument the form, content, and best practices of middleware and
frameworks. Other key topics and domains that will benefit
from the foundational work conducted thus far will include:
5.3 Evaluating the Synergies Between Middle-
 Distributed real-time and embedded systems. An in-
ware, Frameworks, and Patterns creasing number of patterns associated with middleware
The short case study above illustrates how patterns and frame- frameworks for concurrent and networked objects have
works are both important techniques to achieve large-scale been documented during the past five years [36, 5, 35]. A
reuse by capturing successful software development strategies key next step is to document the patterns for distributed
within a particular context, which in this case was distribution real-time and embedded (DRE) systems, which extends
and host infrastructure middleware. All three of these tech- earlier work to focus on effective strategies and tactics for
nologies help to simplify the development, configuration, and managing key QoS properties in DRE systems, includ-
optimization of software by codifying the accumulated exper- ing network bandwidth and latency, CPU speed, memory
tise of developers who have successfully confronted similar access time, and power levels. Since developing high-
problems before as follows: quality DRE systems is hard and remains somewhat of
a “black art,” relatively few reusable patterns [37, 38],
 Frameworks codify this expertise in the form of reusable frameworks [39], and middleware [29] exist for this do-
algorithms and component implementations. main today. We expect an increased focus on DRE sys-
 Patterns codify this expertise at a complementary level tems in the future, however, due to the maturation of
of reuse – recurring architectural design themes – which reusable object technology, together with the develop-
may be reused even when the algorithms or component ment tools, techniques, and processes that enable it to be
implementations are not directly reusable. applied successfully in the DRE domain.
  Mobile systems. Wireless networks are becoming perva- In today’s competitive, time-to-market-driven environ-
sive and embedded devices are become smaller, lighter, ments, it is increasingly infeasible to develop custom solu-
and more capable. Thus, mobile systems will soon tions manually from scratch. Such solutions are hard to cus-
support many consumer communication and computing tomize and tune, because so much effort is spent just try-
needs. Application areas for mobile systems include ing to make the software operational. Moreover, as require-
ubiquitous computing, mobile agents, personal assistants, ments change over time, evolving custom software solutions
position-dependent information provision, remote medi- becomes prohibitively expensive. End-users expect–or at least
cal diagnostics and teleradiology, and home and office desire–software to be affordable, robust, efficient, and agile,
automation. In addition, Internet services, ranging from which is hard to achieve without the solid architectural under-
Web browsing to on-line banking, will be accessed from pinnings achievable via systematic reuse.
mobile systems. Mobile systems present many chal- The past decade has yielded significant progress in reuse of
lenges, such as managing low and variable bandwidth and software in the form of the maturation of standard middleware,
power, adapting to frequent disruptions in connectivity the documentation of patterns, and the development and adop-
and service quality, diverging protocols, and maintaining tion of frameworks. These software technologies provide the
cache consistency across disconnected network nodes. following general types of improvement for developing and
We expect that experienced developers of mobile systems evolving application software:
will capture their expertise in the form of reusable pat-
tern, frameworks, and middleware to help meet the grow- 1. Open standards, which provide a portable and interoper-
ing demand for quality software in this area. able set of software artifacts, such as interoperable secu-
rity, layered distributed resource management, and fault
 Adaptive QoS for COTS systems. Distributed applica-
tolerance services. An increasingly important role is be-
tions, such as streaming video, Internet telephony, and
ing played by open and/or standard COTS middleware
large-scale interactive simulation systems, have increas-
frameworks that can be purchased or acquired via open-
ingly stringent QoS. To reduce development cycle-time
source means. COTS middleware frameworks are partic-
and cost, these applications are increasingly being devel-
ularly important for organizations facing time-to-market
oped using multiple layers of COTS hardware, operating
pressures and limited software development resources.
systems, and middleware components, such as those pre-
sented in Section 2. Historically, however, it has been 2. Strategic focus, which elevates application developer fo-
hard to configure COTS-based systems that can simul- cus beyond a preoccupation with low-level OS APIs.
taneously satisfy multiple QoS properties, such as secu- For example, the standard middleware artifacts outlined
rity, timeliness, and fault tolerance [40]. As developers above help to direct the focus of developers toward
and integrators continue to master the complexities of higher-level software application architecture and design
providing end-to-end QoS guarantees, it is essential that concerns. Without needing to worry as much about low-
they document the successful patterns and reify them in level details, developers can focus on more strategic,
the form of reusable adaptive and reflective middleware application-oriented concerns.
frameworks [41] to help others configure, monitor, and 3. Design reuse, patterns are essential to guiding developers
control COTS-based distributed systems that possess a through the steps necessary to ensure successful creation
range of interdependent QoS properties. and deployment of complex software systems. In particu-
lar, patterns enable developers to reuse higher-level soft-
ware application designs, such as publisher/subscriber ar-
7 Concluding Remarks chitectures, micro-kernels, and brokers [4]. These de-
sign artifacts represent some of the key strategic aspects
Application software has historically been developed largely of complex software. If they are understood and applied
from scratch. This development process has been applied properly, the impact of many vexing complexities can be
many times in many companies, by many projects in paral- alleviated greatly.
lel. Even worse, it has been applied by the same teams in 4. Implementation reuse, which amortizes software life-
a series of projects. Regrettably, this continuous rediscovery cycle effort by leveraging previous development exper-
and reinvention of core concepts and code has kept costs un- tise and reifying implementations of key patterns [5, 3]
necessarily high throughout the software development life cy- into reusable middleware frameworks. In the future, most
cle. This problem is exacerbated by the inherent diversity of applications will be assembled by integrating and script-
today’s hardware, operating systems, compilers, and commu- ing domain-specific and common “pluggable” middle-
nication platforms, which keep shifting the foundations of ap- ware service components, rather than being programmed
plication software development. entirely from scratch.
 Despite their natural synergies, however, middleware, [18] R. Johnson, “Frameworks = Patterns + Components,” Communications
frameworks, and patterns are not silver bullets. They cannot, of the ACM, vol. 40, Oct. 1997.
for example, absolve developers from responsibility for solv- [19] J. Coplien, D. Hoffman, and D. Weiss, “Commonality and Variability
in Software Engineering,” IEEE Software, vol. 15,
ing all complex concurrent and networked software analysis, November/December 1998.
design, implementation, validation, and optimization prob- [20] M. Fayad and R. Johnson, eds., Domain-Specific Application
lems. Ultimately there is no substitute for human creativity, Frameworks: Frameworks Experience by Industry. New York: Wiley
& Sons, 1999.
experience, discipline, diligence, and judgement. When used
[21] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson,
together properly, however, the technologies described in this I. Fiksdahl-King, and S. Angel, A Pattern Language. New York, NY:
paper help alleviate many inherent and accidental software Oxford University Press, 1977.
complexities. [22] J. O. Coplien and D. C. Schmidt, eds., Pattern Languages of Program
Design. Reading, Massachusetts: Addison-Wesley, 1995.
[23] C. Alexander, The Timeless Way of Building. New York, NY: Oxford
References University Press, 1979.
[24] W. Cunningham, “The CHECKS Pattern Language of Information
[1] P. Clements and L. Northrop, Software Product Lines: Practices and Integrity,” in Pattern Languages of Program Design (J. O. Coplien and
Patterns. Boston: Addison-Wesley, 2002. D. C. Schmidt, eds.), Reading, Massachusetts: Addison-Wesley, 1995.
[2] R. E. Schantz and D. C. Schmidt, “Middleware for Distributed [25] J. Borchers, “A Pattern Approach To Interaction Design”. New York:
Systems: Evolving the Common Structure for Network-centric Wiley & Sons, 2001.
Applications,” in Encyclopedia of Software Engineering (J. Marciniak
[26] K. Beck, Smalltalk Best Practice Patterns. Englewood Cliffs, NJ:
and G. Telecki, eds.), New York: Wiley & Sons, 2002.
Prentice-Hall, 1997.
[3] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software. Reading, MA: [27] K. Henney, “C++ Patterns - Reference Accounting,” in Proceedings of
Addison-Wesley, 1995. the EuroPLoP 2002 conference, (Irsee, Germany), July 2002.
[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, [28] A. Haase, “Java Idioms: Exception Handling,” in Proceedings of the
Pattern-Oriented Software Architecture—A System of Patterns. New EuroPLoP 2003 conference, (Irsee, Germany), July 2003.
York: Wiley & Sons, 1996. [29] D. C. Schmidt, D. L. Levine, and S. Mungee, “The Design and
[5] D. C. Schmidt, M. Stal, H. Rohnert, and F. Buschmann, Performance of Real-Time Object Request Brokers,” Computer
Pattern-Oriented Software Architecture: Patterns for Concurrent and Communications, vol. 21, pp. 294–324, Apr. 1998.
Networked Objects, Volume 2. New York: Wiley & Sons, 2000. [30] M. Henning and S. Vinoski, Advanced CORBA Programming with
[6] M. Fayad, R. Johnson, and D. C. Schmidt, eds., Implementing C++. Reading, MA: Addison-Wesley, 1999.
Application Frameworks: Object-Oriented Frameworks at Work. New [31] Object Management Group, The Common Object Request Broker:
York: Wiley & Sons, 1999. Architecture and Specification, 3.0 ed., June 2002.
[7] M. Fayad, R. Johnson, and D. C. Schmidt, eds., Building Application [32] G. Meszaros, “A Pattern Language for Improving the Capacity of
Frameworks: Object-Oriented Foundations of Framework Design. Reactive Systems,” in Pattern Languages of Program Design (J. O.
New York: Wiley & Sons, 1999. Coplien, J. Vlissides, and N. Kerth, eds.), Reading, Massachusetts:
[8] H. Hueni, R. Johnson, and R. Engel, “A Framework for Network Addison-Wesley, 1996.
Protocol Software,” in Proceedings of OOPSLA ’95, (Austin, TX), [33] D. C. Schmidt, V. Kachroo, Y. Krishnamurthy, and F. Kuhns,
ACM, Oct. 1995. “Applying QoS-enabled Distributed Object Computing Middleware to
[9] D. C. Schmidt and S. D. Huston, C++ Network Programming, Volume Next-generation Distributed Applications,” IEEE Communications
1: Mastering Complexity with ACE and Patterns. Boston: Magazine, vol. 38, pp. 112–123, Oct. 2000.
Addison-Wesley, 2002. [34] R. Noseworthy, “IKE 2 – Implementing the Stateful Distributed Object
[10] D. C. Schmidt and S. D. Huston, C++ Network Programming, Volume Paradigm ,” in 5th IEEE International Symposium on Object-Oriented
2: Systematic Reuse with ACE and Frameworks. Reading, Real-Time Distributed Computing (ISORC 2002), (Washington, DC),
Massachusetts: Addison-Wesley, 2002. IEEE, Apr. 2002.
[11] D. Alur, J. Crupi, and D. Malks, Core J2EE Patterns: Best Practices [35] D. C. Schmidt and C. Cleeland, “Applying Patterns to Develop
and Design Strategies. Prentice Hall, 2001. Extensible ORB Middleware,” IEEE Communications Magazine,
[12] M. Volter, A. Schmid, and E.Wolff, Server Component Patterns – vol. 37, Apr. 1999.
Component Infrastructures illustrated with EJB. New York: Wiley & [36] D. Lea, Concurrent Programming in Java: Design Principles and
Sons, 2002. Patterns, Second Edition. Boston: Addison-Wesley, 2000.
[13] M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, and R. Stafford, [37] D. Lea and J. Marlowe, “PSL: Protocols and Pragmatics for Open
Patterns of Enterprise Application Architecture. Reading, Systems,” in Proceedings of the 9th European Conference on
Massachusetts: Addison-Wesley, 2002. Object-Oriented Programming, (Aarhus, Denmark), ACM, Aug. 1995.
[14] F. Buschmann, A. Geisler, T. Heimke, and C. Schuderer, [38] J. Noble and C. Weir, Small Memory Software: Patterns for Systems
“Framework-Based Software Architectures for Process Automation with Limited Memory. Boston: Addison-Wesley, 2001.
Systems,” in Proceedings of the 9th IFAC Symposium on Automation in
Mining, Mineral, and Metal Processing, (Cologne, Germany), 1998. [39] D. C. Schmidt, “R&D Advances in Middleware for Distributed,
Real-time, and Embedded Systems,” Communications of the ACM
[15] D. C. Sharp, “Reducing Avionics Software Cost Through Component special issue on Middleware, vol. 45, pp. 43–48, June 2002.
Based Product Line Development,” in Proceedings of the 10th Annual
Software Technology Conference, Apr. 1998. [40] J. A. Zinky, D. E. Bakken, and R. Schantz, “Architectural Support for
Quality of Service for CORBA Objects,” Theory and Practice of Object
[16] B. S. Doerr and D. C. Sharp, “Freeing Product Line Architectures from Systems, vol. 3, no. 1, pp. 1–20, 1997.
Execution Dependencies,” in Proceedings of the 11th Annual Software
Technology Conference, Apr. 1999. [41] F. Kon, F. Costa, G. Blair, and R. H. Campbell, “The Case for
Reflective Middleware,” Communications ACM, vol. 45, pp. 33–38,
[17] R. Johnson and B. Foote, “Designing Reusable Classes,” Journal of June 2002.
Object-Oriented Programming, vol. 1, pp. 22–35, June/July 1988.