Patterns, frameworks, and middleware Their synergistic relationships

Patterns,Frameworks,and Middleware:

Their Synergistic Relationships

Douglas C.Schmidt Frank Buschmann

douglas.c.schmidt@https://www.wendangku.net/doc/3c521023.html, Frank.Buschmann@mchp.siemens.de Electrical Engineering&Computer Science Corporate Research

Vanderbilt University Siemens,AG

Nashville Tennessee,USA Munich,Germany

Abstract

The knowledge required to develop complex software has his-

torically existed in programming folklore,the heads of experi-

enced developers,or buried deep in the code.These locations

are not ideal since the effort required to capture and evolve

this knowledge is expensive,time-consuming,and error-prone.

Many popular software modeling methods and tools address

certain aspects of these problems by documenting how a sys-

tem is designed.However,they only support limited portions

of software development and do not articulate why a system

is designed in a particular way,which complicates subsequent

software reuse and evolution.

Patterns,frameworks,and middleware are increasingly

popular techniques for addressing key aspects of the chal-

lenges outlined above.Patterns codify reusable design ex-

pertise that provides time-proven solutions to commonly oc-

curring software problems that arise in particular contexts

and domains.Frameworks provide both a reusable product-

line architecture[1]–guided by patterns–for a family of

related applications and an integrated set of collaborating

components that implement concrete realizations of the ar-

chitecture.Middleware is reusable software that leverages

patterns and frameworks to bridge the gap between the func-

tional requirements of applications and the underlying oper-

ating systems,network protocol stacks,and databases.This

paper presents an overview of patterns,frameworks,and mid-

dleware,describes how these technologies complement each

other to enhance reuse and productivity,and then illustrates

how they have been applied successfully in practice to improve

the reusability and quality of complex software systems.

1Introduction

Emerging trends and challenges.Despite signi?cant ad-

vances in computers,networks,programming languages,and

software methodologies,developing quality applications on

organizations.

Solution approach Middleware,framework,and pat-terns.Middleware[2]is software that can signi?cantly in-crease reuse by providing readily usable,standard solutions to common programming tasks,such as persistent storage, (de)marshaling,message buffering and queueing,request de-multiplexing,and concurrency control.Developers who use middleware can therefore focus primarily on application-oriented topics,such as business logic,rather than wrestling with tedious and error-prone details associated with program-ming infrastructure software using lower-level OS APIs and mechanisms.

Over the past decade a number of middleware standards have emerged and matured.Some of these standards,such as the Common Object Request Broker Architecture(CORBA), are open systems sanctioned by international organizations, such as the Object Management Group(OMG).Other middle-ware standards,such as Java virtual machines,Jave2Enter-prise Edition(J2EE),https://www.wendangku.net/doc/3c521023.html,,have emerged from industry consortia and market leaders.

Crucial to the success of standard middleware are the pat-terns[3,4,5]and frameworks[6,7]that reify the knowledge of how to develop and apply the middleware and applications that run atop it.Patterns support the reuse of design expertise by articulating the static and dynamic aspects of successful solutions to problems that arise when building software in a particular context.Frameworks are concrete realizations of groups of patterns that enable reuse of code by(1)captur-ing the common abstractions of an application domain–both their structure and mechanisms–while(2)yielding control of application-speci?c structure and behavior to application de-velopers.

During the past decade a number of in?uential R&D ef-forts[4,8,5,9,10,11,12,13]have focused on documenting patterns and developing frameworks that enable the effective development and reuse of middleware.As a result,middle-ware is now commonly developed using frameworks based on strategized composition and optimization patterns.These pat-terns and frameworks guide the integration and con?guration of middleware that can meet the functional and QoS require-ments of particular application domains more effectively than can realistically be developed manually from scratch in time-to-market driven environments.

The relationship between middleware,frameworks,and pat-terns is highly synergistic.For example,patterns help guide framework design and use,thereby reducing software devel-opment effort and training costs.In turn,frameworks can be used to develop middleware for product-line architectures[1], whose interfaces then provide application software with a sim-pler facade to access the powerful(and complex)internal com-ponent structure of the frameworks.Likewise,frameworks and patterns support the development of product-line archi-tectures for speci?c application domains,such as warehouse management or hot rolling mill process automation[14],that apply particular types of middleware.A contribution of this paper is to illustrate by examples how these three technologies relate and complement each other.

Paper organization.The remainder of this paper is orga-nized as follows:Section2presents an taxonomy of the layers of middleware;Sections3and4describe the key properties of frameworks and patterns,respectively;Section5then illus-trates the synergies between all three technologies via a case study of how frameworks and patterns have been applied in practice to develop middleware for distributed real-time and embedded systems;Section6summarizes promising areas of future R&D;and Section7presents concluding remarks.

2An Overview of Middleware

Some of the most successful techniques and tools devised to enhance the reuse of software center on middleware that helps manage the complexity and heterogeneity of distributed appli-cations.This distributed computing middleware(henceforth referred to simply as middleware)provides reusable software that functionally bridges the gap between(1)end-to-end ap-plication functional requirements and(2)the lower-level op-erating systems,networking protocol stacks,databases,and hardware devices.Middleware provides reusable capabilities whose qualities are critical to help simplify and coordinate how application software is connected and how it interoper-ates.

Just as networking protocol stacks can be decomposed into multiple layers,such as the physical,data-link,network,trans-port,session,presentation,and application layers,so to can middleware be decomposed into the multiple layers[2]shown in Figure1and described in the remainder of this section. Host infrastructure middleware encapsulates and enhances native OS mechanisms to create reusable event demultiplex-ing,interprocess communication,concurrency,and synchro-nization objects,such as reactors;acceptors,connectors,and service handlers;monitor objects;active objects;and service con?gurators[9,10].By encapsulating the peculiarities of particular operating systems,these reusable objects help elim-inate many tedious,error-prone,and non-portable aspects of developing and maintaining application software via low-level OS programming APIs,such as Sockets or POSIX pthreads. Common host infrastructure middleware includes the Sun Java Virtual Machine(JVM)and Microsoft’s Common Lan-guage Runtime(CLR),which provide platform-independent ways of executing code by abstracting the differences be-tween operating systems and CPU architectures.The ADAP-TIVE Communication Environment(ACE)[9,10]is portable

layers summarized above have matured and become perva-sive throughout the industry,the total amount of software that application developers must write has shrunk substantially. However,reduction in application developer effort also im-plies more work for middleware developers since they be-come responsible for an increasing number of software lay-ers.While some believe that the techniques used to de-velop reusable middleware are simply implementation details, in practice these choices have a signi?cant impact on other key middleware qualities,such as its affordability,extensibil-ity,?exibility,portability,predictability,ef?ciency,reliability, scalability,and trustworthiness.

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-terns are increasingly applied to improve the reusability and quality of both middleware and application software.The re-mainder of this paper presents overviews of frameworks and patterns and then shows how these technologies can be com-bined with middleware to enhance software reuse.It is impor-tant to note,however,that the reuse potential of frameworks and patterns is not limited to middleware!

3Overview of Frameworks

As outlined in the previous section,in today’s competitive, fast-paced computing industry,successful middleware and ap-plication software must possess(1)affordability,to ensure that the total ownership costs of software acquisition and evo-lution are not prohibitively high,(2)extensibility,to support successions of quick updates and additions to address new re-quirements and take advantage of emerging markets,(3)?ex-ibility,to support a growing range of multimedia data types, traf?c?ows,and end-to-end QoS requirements,(4)portabil-ity,to reduce the effort required to support applications on heterogeneous OS platforms and compilers,(5)predictability and ef?ciency,to provide low latency to delay-sensitive real-time applications,high performance to bandwidth-intensive applications,and usability over low-bandwidth networks,such as wireless links,(6)reliability,to ensure that applications are robust and tolerant of faults,(7)scalability,to enable applica-tions to handle large numbers of clients simultaneously,and (8)trustworthiness,to ensure integrity,con?dentiality,and availability in distributed systems.

When software is developed monolithically,i.e.,as tightly coupled clumps of functionality that are not organized mod-ularly or hierarchically,it is hard to achieve these qualities. Frameworks[6,7]have emerged as a powerful technology for developing and reusing middleware and application software that possess the qualities listed above.Figure2illustrates the three characteristics of frameworks[17]described below that

-SPECIFIC

FRAMEWORK

CAPABILITIES

Figure2:Relationships Between Framework Components help them to achieve these qualities.1

A framework exhibits“inversion of control”at run

time via callbacks to component hook methods af-ter the occurrence of an event,such as a mouse click or data arriving on a network connection.When an event occurs,the framework calls back to a virtual hook method in a pre-registered component,which then per-forms application-de?ned processing in response to the event.The virtual hook methods in the components de-couple the application software from the reusable frame-work software,which makes it easier to extend and cus-tomize the applications as long as the interaction proto-cols and QoS properties are not violated.

A framework provides an integrated set of domain-

speci?c structures and functionality.Reuse of software depends largely on how well frameworks model the com-monalities and variabilities[19]in application domains, such as business data processing,telecom call process-ing,graphical user interfaces,or real-time middleware.

By leveraging the domain knowledge and prior efforts of experienced developers,frameworks embody common solutions to recurring application requirements and soft-ware design challenges that need not be recreated and revalidated for each new application.

A framework is a“semi-complete”application that

programmers can customize to form complete applica-tions by extending reusable components in the frame-work.In particular,frameworks help abstract the canoni-cal control?ow of applications in a domain into product-line architectures and families of related components.At runtime,these components can collaborate to integrate customizable application-independent reusable code with customized application-de?ned code.

Since frameworks exhibit inversion of control,they can sim-

plify application design because the framework—rather than the application—runs the event loop to detect events,demul-tiplex events to event handlers,and dispatch hook methods on the handlers that process the events.Since frameworks reify the key roles and relationships of components in appli-cation domains,the amount of reusable code increases and the amount of code rewritten for each application decreases dra-matically.Since a framework is a semi-complete application, it enables larger-scale reuse of software than can be achieved by reusing individual components or stand-alone functions. Developers in certain domains have applied frameworks successfully for several decades.Early frameworks,such as MacApp,X-windows,and Interviews,originated in the do-main of graphical user interfaces(GUIs).Java Swing and Microsoft Foundation Classes(MFC)are contemporary GUI frameworks that are widely used to create graphical applica-tions on PC platforms.The broad adoption of reusable GUI frameworks has yielded many productivity and quality bene-?ts for business and desktop applications.

Building upon their success in the GUI domain,frameworks are now being applied to many new and more complex do-mains[6,7,20].For example,ACE and TAO described in Section5.1are frameworks for host infrastructure and dis-tribution middleware,JBoss and BEA’s WebLogic Server are component frameworks for application servers,and many re-cent R&D efforts,such as the Open Grid Service Infrastructure (OGSI),focus on frameworks for web services.There are also frameworks for speci?c application domains,such as SAP,and application frameworks for medical imaging systems,such as the Syngo platform.These frameworks are increasingly aligning with the layers of middleware standards and domain-speci?c product-line architectures discussed in Section2.

4Overview of Patterns

Developers of middleware and application software must ad-dress many challenges related to complex design and program-ming topics,such as persistence,data organization,connection management,service initialization,distribution,concurrency control,?ow control,error handling,event loop integration, and dependability.Many of these challenges occur repeatedly in many applications and domains.Until the mid-1990’s,the knowledge needed to resolve these challenges existed largely in programming folklore,the heads of expert researchers and developers,or buried deep in complex source code.These lo-cations are not ideal because

Discovering patterns from source code is expensive and time-consuming since it is hard to separate the essence of

a design from its implementation details.

If the insights and rationale of experienced designers are

not documented,they will be lost over time and thus can-not be used to guide subsequent software evolution.

Without guidance from earlier work,software developers must engineering complex systems from the ground up, rather than by reusing proven solutions.

Over the past decade,experienced software developers and architects have helped to address these problems by creating a body of literature that documents the following types of reusable knowledge:

Design patterns[3],which provide a scheme for re?ning the elements of a software system and the relationships between them,and describe a common structure of com-municating elements that solves a general design problem within a particular context.

Architectural patterns[4],which express the funda-mental,overall structural organization of software sys-tems and provide a set of prede?ned subsystems,specify their responsibilities,and include guidelines for organiz-ing the relationships between them.

Pattern languages[21],which weave together a web of related patterns to de?ne a vocabulary for talking about software development problems and provide a process for the orderly resolution of these problems.

Patterns help enhance reuse by capturing and reusing the static and dynamic structure and collaboration of key par-ticipants in software designs.They are particularly useful for documenting recurring micro-architectures,which are ab-stractions of software components that experienced developers apply to resolve common design and implementation prob-lems.By studying and applying patterns and pattern lan-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 design and programming activities,which helps improve team productivity and software quality.

Figure3illustrates the relationships amongst a pattern lan-guage[5]that addresses service access and con?guration, event handling,interprocess communication,concurrency,and synchronization dimensions in various networked applica-tion domains,such as online?nancial services,remote pro-cess control,avionics mission computing,and telecommuni-cations.2The relationships in this diagram reveal the follow-ing ways in which the patterns complement and complete each other in multiple ways to form a pattern language:

Although each pattern is useful in isolation,the pattern language is even more powerful,because it integrates so-lutions to particular problems in important technical ar-eas,such as event handling,connection management and

Figure 3:A Pattern Language for Network Programming service access,concurrency models,and synchronization strategies.Each problem in these areas must be resolved coherently and consistently when developing concurrent and networked applications.

The pattern language also exposes the interdependencies of these technical areas.For example,when selecting a particular event-handling pattern for a networked appli-cation,not all potentially-available concurrency patterns can be applied usefully.

A pattern language describes an entire solution space for developing a particular type of system,system part,or system aspect –by offering alternative solutions to cer-tain problems.A pattern language can therefore be ap-plied many,many times without ever producing exactly the same architecture,design,or implementation.Yet each individual architecture,design,and implementation follows the same timeless,thus reusable,design knowl-edge embedded in each pattern language [23].These three points become clear only when connecting pat-terns into a pattern language since each pattern in isolation only focuses on itself.In contrast,a pattern language-based design integrates the patterns consistently and synergistically by giving concrete and precise guidance in developing a spe-ci?c (type of)system or system aspect.In particular,a pattern language conveys what are the key problems to be resolved,in what order should they be tackled,what alternatives exist for resolving a given problem,how are mutual dependencies be-tween the problems handled,and how is each individual prob-lem resolved effectively in the presence of its associated prob-lems.Many pattern languages exist today.Some support the cre-ation of a speci?c types of software,such as the pattern lan-guages for networked and concurrent computing [5]and enter-prise application architectures [13].Others pattern languages help to realize a certain part,subsystem,or large component of a software system.For instance,there is a pattern language for server components [12]that describes how to build well-structured server-side components.Yet other languages focus on a particular problem area of relevance in software,such as handling erroneous user input [24]and designing user-friendly interfaces to computer and information systems [25].There are also pattern languages for good programming style and practice,such as Smalltalk best practice patterns [26],C++reference accounting [27],and Java exception handling [28].Section 6describes other key areas where we expect future pattern languages will be published.5Illustrating the Synergies of Middle-ware,Frameworks,and Patterns Sections 2–4present overviews of middleware,frameworks,and patterns,emphasizing their particular contributions to software reuse.This section examines these technologies in terms of their relationships and synergies.To make the dis-cussion tangible,we focus on The ACE OR

B (TAO)[29]as a case study to illustrate how patterns and frameworks can help middleware developers build and evolve software by reducing the coupling between its components.5.1Overview of CORBA and TAO

CORBA Object Request Brokers (ORBs)[30]allow clients to invoke operations on distributed objects without concern for object location,programming language,OS platform,commu-nication protocols and interconnects,and hardware.Figure 4illustrates the components in the CORBA reference model,which collaborate to provide the portability,interoperability,and transparency mentioned above.The client stubs marshal client operations into General Inter-ORB Protocol (GIOP)re-quests that are transmitted to objects via the standard Internet Inter-ORB Protocol (IIOP)3implemented in the ORB Core.The server ORB Core demultiplexes and receives these re-quests using one or more threads and passes them to the Ob-ject Adapter.The Object Adapter demultiplexes the requests to skeletons,which demarshal the requests and dispatch the

CLIENT OBJECT (SERVANT )

OBJ

REF Figure 4:Components in the CORBA Reference Model

appropriate application-level servant method that implements the object’s operation.

The ACE ORB (TAO)[29]is a high-performance,real-time

implementation of the CORBA 3.0speci?cation [31]that sup-ports the distribution middleware capabilities shown in Fig-ure 4and described in Section 2.TAO is targeted for appli-cations with deterministic and statistical QoS requirements,as well as best effort requirements.As its name suggests,TAO is developed using the frameworks and components in the ACE host infrastructure middleware.ACE and TAO are open-source software that has evolved organically over the past decade.They are used in hundreds of production software systems in research labs and commercial projects,includ-ing avionics mission computing systems at Boeing,satellite communication systems at Lockheed and Raytheon,telecom-munication systems at BBN,Cisco,Lucent,Motorola,Nor-tel,and Siemens,medical systems at GE,and online trad-ing systems at Automated Trading https://www.wendangku.net/doc/3c521023.html,plete source code and documentation for ACE and TAO is available at https://www.wendangku.net/doc/3c521023.html,/?schmidt/TAO/.5.2Applying Patterns and Frameworks to TAO Middleware The interfaces,protocols,and components shown in Figure 4illustrate the primary capabilities provided by the CORBA ref-erence architecture.As is often the case with architectural di-agrams,however,it is not clear from this ?gure how the archi-tecture behaves or why the architecture is designed the way it is.Naturally,a thorough understanding of these issues is es-sential to develop,con?gure,optimize,and evolve the reusable middleware effectively.To address these issues,we outline the key patterns and frameworks used by TAO’s ORB Core to il-lustrate the synergies between these two reuse technologies in

terms of improving the extensibility,maintainability,and per-formance of distribution middleware.OBJECT /SERVANT CLIENT Figure 5:The Patterns Used in TAO The key patterns used in the TAO ORB are shown in Fig-ure 5and described below:

The Wrapper Facade pattern [5]simpli?es the OS sys-tem programming interface by combining multiple re-lated OS mechanisms,such as the socket API or POSIX threads,into cohesive OO abstractions.TAO uses this pattern to enhance its reuse by encapsulating the te-dious,non-portable,and non-typesafe low-level OS sys-tem functions within C++classes.The Reactor pattern [5]allows event-driven applications to react to events originating from a number of disparate sources,such as I/O handles,timers,and signals.TAO uses this pattern to dispatch ORB connection and I/O 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 a networked application from the processing they per-form after being connected and initialized.TAO uses this pattern in its ORB Core to actively/passively establish

connections and create I/O handlers that exchange GIOP messages independently of the underlying transports.The Leader Followers pattern [5]provides an ef?-cient concurrency model where multiple threads take turns calling a synchronous event demultiplexer (such as select())on sets of I/O handles to detect,demulti-plex,dispatch,and process service requests that occur.TAO uses this pattern to improve its performance and pre-dictability by reducing context switching,synchroniza-tion,and data allocation/movement overhead.The Strategy pattern [3]provides a means to select one of several candidate policies or algorithms and packaging

it with an object.This pattern is the foundation of TAO’s extensible software architecture and makes it possible to con?gure custom ORB strategies for connection manage-ment,concurrency,and demultiplexing.

The Abstract Factory pattern[3]provides a single com-ponent that builds related objects.TAO uses this pattern to create and consolidate its many strategy objects into a manageable number of abstract factories that can be re-con?gured en masse into its ORB Core conveniently and consistently.TAO components use these factories to ac-cess related strategies without explicitly specifying their subclass name.

The Component Con?gurator pattern[5]permits dy-namic run-time con?guration of abstract factories and strategies in an ORB[5].TAO uses this pattern to dy-namically link the abstract factories that produce custom ORB personalities,such as a high-throughput ORB,a predictable real-time ORB,or a small footprint ORB.

The Proxy pattern[4,3]de?nes a object(the proxy)that acts as surrogate for a(potentially remote)target object.

TAO uses this pattern to perform the(de)marshaling op-erations de?ned by CORBA stubs.

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-mentations(servants)with the reusable ORB code.An object adapter also implements the Manager pattern[4] to control the lifecycle of the objects and servants it con-tains.

Knowing the patterns used in TAO is useful since it enables reuse of abstract design and architecture knowledge.However, reuse of patterns alone is insuf?cient since it does not directly yield?exible and ef?cient software.We therefore found it nec-essary to augment our study of patterns with the creation and use of the frameworks provided by ACE.These frameworks help developers of TAO middleware avoid costly reinvention of common software artifacts by refactoring recurring imple-mentation roles.They also provide direct knowledge transfer by embodying patterns in a powerful toolkit that contains mid-dleware domain experience and working code.

The primary ACE frameworks used in TAO’s ORB Core are shown in Figure6.Below,we describe each framework, outline which pattern(s)it implements,and discuss how it en-hances reuse.

The Reactor framework implements the Reactor and Leader/Followers patterns to facilitate a concurrency model where events indicating the ability to begin I/O operations.This framework enhances reuse in TAO by automating the detection,demultiplexing,and dispatch-ing of handlers in response to I/O,timer,and signal events.The ACE Reactor drives the main event loop

Figure6:The ACE Frameworks Used in TAO

in TAO,which accepts connections and receives/sends client GIOP requests/responses via a pool of threads. The Acceptor-Connector framework leverages the

Reactor framework and implements the Acceptor-Connector and Strategy patterns to decouple the active and passive initialization roles from application-de?ned service processing performed by communicating peer services after initialization is complete.This ACE frame-work enhances reuse by de?ning(1)strategy connec-tor objects that automatically establish connections with servers and initialize handlers that transmit GIOP re-quests and(2)strategy acceptor objects that automati-cally accept connections from clients and initialize han-dlers that process GIOP requests from clients.

The Service Con?gurator framework implements the Component Con?gurator pattern to support the?exible con?guration of ORBs whose strategies can be deter-mined and deployed at the appropriate time in the de-sign cycle,e.g.,via the svc.conf con?guration script at installation time and/or run time.This framework en-hances reuse by enabling ORB abstract factories(and the strategies they embody)to be treated as interchangeable building blocks.Software with high availability require-ments,such as online transaction processing or real-time industrial process automation,often require these?exible con?guration capabilities.

The design of the ACE frameworks presented above is

guided by many of the patterns shown in Figures3and5. TAO uses these patterns and the ACE frameworks that reify

them to develop an extensible ORB architecture.However,

the patterns and frameworks described here are not limited to middleware.In fact,they have been applied in many other

application domains,including telecom call processing[32] and switching[8],airplane?ight control systems[15],multi-

media videoconferencing[33],distributed interactive simula-

tions[34],and enterprise business applications[20].

The patterns described above help to solve many common problems that arise when developing and using frameworks

for middleware and applications.In the context of TAO,for example,a deep understanding of these patterns helps to Preserve important design information for developers who enhance and maintain the TAO middleware.Since

scores of developers have worked on TAO over the past

decade,this information would be lost if it was not doc-umented,which would increase software entropy and de-crease software maintainability and quality.The metrics reported in[35]quantify the extent to which knowledge of patterns helped to reduce the development and mainte-nance effort for TAO.

Guide design choices for developers who are building new middleware and applications using TAO.The books in which the patterns outlined above appear document the common traps and pitfalls of developing middleware.

This information helps TAO developers select suitable ar-chitectures,protocols,algorithms,and platform features without wasting time and effort(re)implementing solu-tions that have been shown to be inef?cient or error prone.

5.3Evaluating the Synergies Between Middle-

ware,Frameworks,and Patterns

The short case study above illustrates how patterns and frame-works are both important techniques to achieve large-scale reuse by capturing successful software development strategies within a particular context,which in this case was distribution and host infrastructure middleware.All three of these tech-nologies help to simplify the development,con?guration,and optimization of software by codifying the accumulated exper-tise of developers who have successfully confronted similar problems before as follows:

Frameworks codify this expertise in the form of reusable algorithms and component implementations.

Patterns codify this expertise at a complementary level of reuse–recurring architectural design themes–which may be reused even when the algorithms or component implementations are not directly reusable.

Middleware codi?es this expertise in the form of inter-faces and standard components that provide applications with a simpler facade to access the powerful(and com-plex)internal component structure of frameworks.

For example,as shown in our case study above,TAO middle-ware developers are more effective since the frameworks in ACE implement the core patterns associated with service ac-cess and con?guration,event handling,interprocess commu-nication,concurrency,and synchronization.

It is important to recognize that middleware,frameworks, and patterns are highly synergistic concepts,with none subor-dinate to the other[18].Patterns can be characterized as more abstract descriptions of frameworks,which are often indepen-dent of a particular programming language,operating system, network,or database environment.Patterns have been used to document frameworks and middleware.Sophisticated middle-ware frameworks are concrete realizations of groups of dozens to hundreds of patterns.A framework also integrates various approaches to problems where there are no a priori context-independent and optimal solutions.

6Future R&D Focus Areas

Over the past decade,R&D on patterns,frameworks,and mid-dleware has focused largely on developing and re?ning the core concepts and infrastructure that can create the founda-tions for subsequent efforts[6,7].As a result of these ad-vances,we expect the next generation of middleware will be developed using frameworks that consciously embody time-proven patterns.Patterns will also increasingly be used to doc-ument the form,content,and best practices of middleware and frameworks.Other key topics and domains that will bene?t from the foundational work conducted thus far will include: Distributed real-time and embedded systems.An in-creasing number of patterns associated with middleware frameworks for concurrent and networked objects have been documented during the past?ve years[36,5,35].A key next step is to document the patterns for distributed real-time and embedded(DRE)systems,which extends earlier work to focus on effective strategies and tactics for managing key QoS properties in DRE systems,includ-ing network bandwidth and latency,CPU speed,memory access time,and power levels.Since developing high-quality DRE systems is hard and remains somewhat of a“black art,”relatively few reusable patterns[37,38], frameworks[39],and middleware[29]exist for this do-main today.We expect an increased focus on DRE sys-tems in the future,however,due to the maturation of reusable object technology,together with the develop-ment tools,techniques,and processes that enable it to be applied successfully in the DRE domain.

Mobile systems.Wireless networks are becoming perva-sive and embedded 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 medi-cal diagnostics and teleradiology,and home and of?ce automation.In addition,Internet services,ranging from Web browsing to on-line banking,will be accessed from mobile systems.Mobile systems present many chal-lenges,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.

We expect that experienced developers of mobile systems will capture their expertise in the form of reusable pat-tern,frameworks,and middleware to help meet the grow-ing demand for quality software in this area.

Adaptive QoS for COTS systems.Distributed applica-tions,such as streaming video,Internet telephony,and large-scale interactive simulation systems,have increas-ingly stringent QoS.To reduce development cycle-time and cost,these applications are increasingly being devel-oped using multiple layers of COTS hardware,operating systems,and middleware components,such as those pre-sented in Section2.Historically,however,it has been hard to con?gure COTS-based systems that can simul-taneously satisfy multiple QoS properties,such as secu-rity,timeliness,and fault tolerance[40].As developers and integrators continue to master the complexities of providing end-to-end QoS guarantees,it is essential that they document the successful patterns and reify them in the form of reusable adaptive and re?ective middleware frameworks[41]to help others con?gure,monitor,and control COTS-based distributed systems that possess a range of interdependent QoS properties.

7Concluding Remarks

Application software has historically been developed largely from scratch.This development process has been applied many times in many companies,by many projects in paral-lel.Even worse,it has been applied by the same teams in a series of projects.Regrettably,this continuous rediscovery and reinvention of core concepts and code has kept costs un-necessarily high throughout the software development life cy-cle.This problem is exacerbated by the inherent diversity of today’s hardware,operating systems,compilers,and commu-nication platforms,which keep shifting the foundations of ap-plication software development.

In today’s competitive,time-to-market-driven environ-ments,it is increasingly infeasible to develop custom solu-tions manually from scratch.Such solutions are hard to cus-tomize and tune,because so much effort is spent just try-ing to make the software operational.Moreover,as require-ments change over time,evolving custom software solutions becomes prohibitively expensive.End-users expect–or at least desire–software to be affordable,robust,ef?cient,and agile, which is hard to achieve without the solid architectural under-pinnings achievable via systematic reuse.

The past decade has yielded signi?cant progress in reuse of software in the form of the maturation of standard middleware, the documentation of patterns,and the development and adop-tion of frameworks.These software technologies provide the following general types of improvement for developing and evolving application software:

1.Open standards,which provide a portable and interoper-

able set of software artifacts,such as interoperable secu-rity,layered distributed resource management,and fault tolerance services.An increasingly important role is be-ing played by open and/or standard COTS middleware frameworks that can be purchased or acquired via open-source means.COTS middleware frameworks are partic-ularly important for organizations facing time-to-market pressures and limited software development resources.

2.Strategic focus,which elevates application developer fo-

cus beyond a preoccupation with low-level OS APIs.

For example,the standard middleware artifacts outlined above help to direct the focus of developers toward higher-level software application architecture and design concerns.Without needing to worry as much about low-level details,developers can focus on more strategic, application-oriented concerns.

3.Design reuse,patterns are essential to guiding developers

through the steps necessary to ensure successful creation 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-chitectures,micro-kernels,and brokers[4].These de-sign artifacts represent some of the key strategic aspects of complex software.If they are understood and applied properly,the impact of many vexing complexities can be alleviated greatly.

4.Implementation reuse,which amortizes software life-

cycle effort by leveraging previous development exper-tise and reifying implementations of key patterns[5,3] into reusable middleware frameworks.In the future,most applications will be assembled by integrating and script-ing domain-speci?c and common“pluggable”middle-ware service components,rather than being programmed entirely from scratch.

Despite their natural synergies,however,middleware, frameworks,and patterns are not silver bullets.They cannot, for example,absolve developers from responsibility for solv-ing all complex concurrent and networked software analysis, design,implementation,validation,and optimization prob-lems.Ultimately there is no substitute for human creativity, experience,discipline,diligence,and judgement.When used together properly,however,the technologies described in this paper help alleviate many inherent and accidental software complexities.

References

[1]P.Clements and L.Northrop,Software Product Lines:Practices and

Patterns.Boston:Addison-Wesley,2002.

[2]R.E.Schantz and D.C.Schmidt,“Middleware for Distributed

Systems:Evolving the Common Structure for Network-centric

Applications,”in Encyclopedia of Software Engineering(J.Marciniak and G.Telecki,eds.),New York:Wiley&Sons,2002.

[3] E.Gamma,R.Helm,R.Johnson,and J.Vlissides,Design Patterns:

Elements of Reusable Object-Oriented Software.Reading,MA:

Addison-Wesley,1995.

[4] F.Buschmann,R.Meunier,H.Rohnert,P.Sommerlad,and M.Stal,

Pattern-Oriented Software Architecture—A System of Patterns.New

York:Wiley&Sons,1996.

[5] D.C.Schmidt,M.Stal,H.Rohnert,and F.Buschmann,

Pattern-Oriented Software Architecture:Patterns for Concurrent and

Networked Objects,Volume2.New York:Wiley&Sons,2000.

[6]M.Fayad,R.Johnson,and D.C.Schmidt,eds.,Implementing

Application Frameworks:Object-Oriented Frameworks at Work.New York:Wiley&Sons,1999.

[7]M.Fayad,R.Johnson,and D.C.Schmidt,eds.,Building Application

Frameworks:Object-Oriented Foundations of Framework Design.

New York:Wiley&Sons,1999.

[8]H.Hueni,R.Johnson,and R.Engel,“A Framework for Network

Protocol Software,”in Proceedings of OOPSLA’95,(Austin,TX),

ACM,Oct.1995.

[9] D.C.Schmidt and S.D.Huston,C++Network Programming,Volume

1:Mastering Complexity with ACE and Patterns.Boston:

Addison-Wesley,2002.

[10] D.C.Schmidt and S.D.Huston,C++Network Programming,Volume

2:Systematic Reuse with ACE and Frameworks.Reading,

Massachusetts:Addison-Wesley,2002.

[11] D.Alur,J.Crupi,and D.Malks,Core J2EE Patterns:Best Practices

and Design Strategies.Prentice Hall,2001.

[12]M.V olter,A.Schmid,and E.Wolff,Server Component Patterns–

Component Infrastructures illustrated with EJB.New York:Wiley&

Sons,2002.

[13]M.Fowler,D.Rice,M.Foemmel,E.Hieatt,R.Mee,and R.Stafford,

Patterns of Enterprise Application Architecture.Reading,

Massachusetts:Addison-Wesley,2002.

[14] F.Buschmann,A.Geisler,T.Heimke,and C.Schuderer,

“Framework-Based Software Architectures for Process Automation

Systems,”in Proceedings of the9th IFAC Symposium on Automation in Mining,Mineral,and Metal Processing,(Cologne,Germany),1998. [15] D.C.Sharp,“Reducing Avionics Software Cost Through Component

Based Product Line Development,”in Proceedings of the10th Annual Software Technology Conference,Apr.1998.

[16] B.S.Doerr and D.C.Sharp,“Freeing Product Line Architectures from

Execution Dependencies,”in Proceedings of the11th Annual Software Technology Conference,Apr.1999.

[17]R.Johnson and B.Foote,“Designing Reusable Classes,”Journal of

Object-Oriented Programming,vol.1,pp.22–35,June/July1988.[18]R.Johnson,“Frameworks=Patterns+Components,”Communications

of the ACM,vol.40,Oct.1997.

[19]J.Coplien,D.Hoffman,and D.Weiss,“Commonality and Variability

in Software Engineering,”IEEE Software,vol.15,

November/December1998.

[20]M.Fayad and R.Johnson,eds.,Domain-Speci?c Application

Frameworks:Frameworks Experience by Industry.New York:Wiley

&Sons,1999.

[21] C.Alexander,S.Ishikawa,M.Silverstein,M.Jacobson,

I.Fiksdahl-King,and S.Angel,A Pattern Language.New York,NY:

Oxford University Press,1977.

[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

University Press,1979.

[24]W.Cunningham,“The CHECKS Pattern Language of Information

Integrity,”in Pattern Languages of Program Design(J.O.Coplien and

D.C.Schmidt,eds.),Reading,Massachusetts:Addison-Wesley,1995.

[25]J.Borchers,“A Pattern Approach To Interaction Design”.New York:

Wiley&Sons,2001.

[26]K.Beck,Smalltalk Best Practice Patterns.Englewood Cliffs,NJ:

Prentice-Hall,1997.

[27]K.Henney,“C++Patterns-Reference Accounting,”in Proceedings of

the EuroPLoP2002conference,(Irsee,Germany),July2002.

[28] A.Haase,“Java Idioms:Exception Handling,”in Proceedings of the

EuroPLoP2003conference,(Irsee,Germany),July2003.

[29] D.C.Schmidt,D.L.Levine,and S.Mungee,“The Design and

Performance of Real-Time Object Request Brokers,”Computer

Communications,vol.21,pp.294–324,Apr.1998.

[30]M.Henning and S.Vinoski,Advanced CORBA Programming with

C++.Reading,MA:Addison-Wesley,1999.

[31]Object Management Group,The Common Object Request Broker:

Architecture and Speci?cation,3.0ed.,June2002.

[32]G.Meszaros,“A Pattern Language for Improving the Capacity of

Reactive Systems,”in Pattern Languages of Program Design(J.O.

Coplien,J.Vlissides,and N.Kerth,eds.),Reading,Massachusetts:

Addison-Wesley,1996.

[33] D.C.Schmidt,V.Kachroo,Y.Krishnamurthy,and F.Kuhns,

“Applying QoS-enabled Distributed Object Computing Middleware to Next-generation Distributed Applications,”IEEE Communications

Magazine,vol.38,pp.112–123,Oct.2000.

[34]R.Noseworthy,“IKE2–Implementing the Stateful Distributed Object

Paradigm,”in5th IEEE International Symposium on Object-Oriented Real-Time Distributed Computing(ISORC2002),(Washington,DC),

IEEE,Apr.2002.

[35] D.C.Schmidt and C.Cleeland,“Applying Patterns to Develop

Extensible ORB Middleware,”IEEE Communications Magazine,

vol.37,Apr.1999.

[36] D.Lea,Concurrent Programming in Java:Design Principles and

Patterns,Second Edition.Boston:Addison-Wesley,2000.

[37] D.Lea and J.Marlowe,“PSL:Protocols and Pragmatics for Open

Systems,”in Proceedings of the European Conference on

Object-Oriented Programming,(Aarhus,Denmark),ACM,Aug.1995.

[38]J.Noble and C.Weir,Small Memory Software:Patterns for Systems

with Limited Memory.Boston:Addison-Wesley,2001.

[39] D.C.Schmidt,“R&D Advances in Middleware for Distributed,

Real-time,and Embedded Systems,”Communications of the ACM

special issue on Middleware,vol.45,pp.43–48,June2002.

[40]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,pp.1–20,1997.

[41] F.Kon,F.Costa,G.Blair,and R.H.Campbell,“The Case for

Re?ective Middleware,”Communications ACM,vol.45,pp.33–38,

June2002.