Applying a Pattern Language to Develop Extensible ORB ...schmidt/PDF/ORB-patterns.pdfdevelop The ACE...

Applying a Pattern Language to Develop Extensible ORB Middleware

Douglas C. Schmidt Chris [email protected] [email protected]

Electrical & Computer Engineering Dept. Object Computing Inc.University of California, Irvine, USA St. Louis, MO, USA�

This paper appeared as a chapter in the bookDesign Pat-terns in Communications, (Linda Rising, ed.), Cambridge Uni-versity Press, 2000. An abridged version appeared in the IEEECommunications Magazine Special Issue on Patterns (LindaRising, ed.), Volume 37, No. 4, April 1999.

Abstract

Distributed object computing forms the basis of next-generation communication software. At the heart of dis-tributed object computing are Object Request Brokers (ORBs),which automate many tedious and error-prone distributed pro-gramming tasks. Like much communication software, conven-tional ORBs use statically configured designs, which are hardto port, optimize, and evolve. Likewise, conventional ORBscannot be extended without modifying their source code, whichforces recompilation, relinking, and restarting running ORBsand their associated application objects.

This paper makes two contributions to the study of extensi-ble ORB middleware. First, it presents a case study illustratinghow a pattern language can be used to develop dynamicallyconfigurable ORBs that can be customized for specific appli-cation requirements and system characteristics. Second, wequantify the impact of applying this pattern language to re-duce the complexity and improve the maintainability of com-mon ORB tasks, such as connection management, data trans-fer, demultiplexing, and concurrency control.

1 Introduction

Four trends are shaping the future of commercial software de-velopment. First, the software industry is moving away fromprogrammingapplications from scratch tointegratingapplica-tions using reusable components [1]. Second, there is great de-mand fordistribution technologythat provides remote methodinvocation and/or message-oriented middleware to simplifyapplication collaboration. Third, there are increasing effortsto define standard software infrastructure frameworks that per-mit applications to interwork seamlessly throughoutheteroge-neousenvironments [2]. Finally, next-generation distributed

�This work was supported in part by ATD, BBN, Boeing, Cisco, DARPAcontract 9701516, Motorola Commercial Government and Industrial Solu-tions Sector, Motorola Laboratories, Siemens, and Sprint.

applications such as video-on-demand, teleconferencing, andavionics requirequality-of-service(QoS) guarantees for la-tency, bandwidth, and reliability [3].

A key software technology supporting these trends isdis-tributed object computing (DOC) middleware. DOC mid-dleware facilitates the collaboration of local and remote ap-plication components in heterogeneous distributed environ-ments. The goal of DOC middleware is to eliminate many te-dious, error-prone, and non-portable aspects of developing andevolving distributed applications and services. In particular,DOC middleware automates common network programmingtasks, such as object location, implementation startup (i.e.,server and object activation), encapsulation of byte-orderingand parameter type size differences across dissimilar architec-tures (i.e., parameter marshaling), fault recovery, and security.At the heart of DOC middleware areObject Request Brokers(ORBs), such as CORBA [4], DCOM [5], and Java RMI [6].

This paper describes how we have applied apattern lan-guageto develop and evolve dynamically configurable ORBmiddleware that can be extended more readily than staticallyconfigured middleware. In general, pattern languages help toalleviate the continual re-discovery and re-invention of soft-ware concepts and components by conveying a family of re-lated solutions to standard software development problems [7].For instance, pattern languages are useful for documenting theroles and relationships among participants in common com-munication software architectures [8]. The pattern languagepresented in this paper is a generalization of the one presentedin [9] and has been used successfully to build flexible, effi-cient, event-driven, and concurrent communication software,including ORB middleware.

To focus our discussion, this paper presents a case studythat illustrates how we have applied this pattern language todevelopThe ACE ORB(TAO) [10]. TAO is a freely avail-able, highly extensible ORB targeted for applications withreal-time QoS requirements, including avionics mission com-puting [11], multimedia applications [12], and distributed in-teractive simulations [13]. A novel aspect of TAO is its ex-tensible design, which is guided by a pattern language that en-ables the ORB to be customized dynamically to meet specificapplication QoS requirements and network/endsystem charac-teristics.

The remainder of this paper is organized as follows: Sec-

1

tion 2 presents an overview of CORBA and TAO; Section 3motivates the need for dynamic configuration and describesthe pattern language that resolves key design challenges facedwhen developing extensible ORBs; Section 3.5 evaluates andquantifies the contribution of the pattern language to ORBmiddleware; and Section 4 presents concluding remarks.

2 Overview of CORBA and TAO

This section outlines the CORBA reference model anddescribes the enhancements that TAO provides for high-performance and real-time applications.

2.1 Overview of the CORBA Reference Model

CORBA Object Request Brokers (ORBs) [14] allow clients toinvoke operations on distributed objects without concern forthe following issues:

Object location: A CORBA object either can be collocatedwith the client or distributed on a remote server, without af-fecting its implementation or use.

Programming language: The languages supported byCORBA include C, C++, Java, Ada95, COBOL, andSmalltalk, among others.

OS platform: CORBA runs on many OS platforms, includ-ing Win32, UNIX, MVS, and real-time embedded systems,such as VxWorks, Chorus, and LynxOS.

Communication protocols and interconnects: The com-munication protocols and interconnects that CORBA run oninclude TCP/IP, IPX/SPX, FDDI, ATM, Ethernet, Fast Ether-net, embedded system backplanes, and shared memory.

Hardware: CORBA shields applications from side effectsstemming from hardware diversity, such as different storagelayouts and data type sizes/ranges.

Figure 1 illustrates the components in the CORBA refer-ence model, all of which collaborate to provide the portability,interoperability and transparency outlined above.

Each component in the CORBA reference model is outlinedbelow:

Client: A client is a role that obtains references to objectsand invokes operations on them to perform application tasks.Objects can be remote or collocated relative to the client.Clients can access remote objects just like a local object,i.e.,object !operation(args) . Figure 1 shows how theunderlying ORB components described below transmit remoteoperation requests transparently from client to object.

INTERFACE

REPOSITORY

IMPLEMENTATION

REPOSITORY

IDLCOMPILER

DII ORBINTERFACE

ORBORB CORECORE GIOPGIOP//IIOPIIOP//ESIOPSESIOPS

IDLIDLSTUBSSTUBS

operation()operation()in args

out args + return value

CLIENTOBJECT(SERVANT)

OBJ

REF

STANDARD INTERFACE STANDARD LANGUAGE MAPPING

ORB-SPECIFIC INTERFACE STANDARD PROTOCOL

INTERFACE

REPOSITORY

IMPLEMENTATION

REPOSITORY

IDLCOMPILER

IDLSKELETON

DSI

OBJECT

ADAPTER

Figure 1: Components in the CORBA Reference Model

Object: In CORBA, an object is an instance of an OMGInterface Definition Language (IDL) interface. Each objectis identified by anobject reference, which associates one ormore paths through which a client can access an object on aserver. Anobject IDassociates an object with its implemen-tation, called a servant, and is unique within the scope of anObject Adapter. Over its lifetime, an object has one or moreservants associated with it to implement its interface.

Servant: This component implements the operations de-fined by an OMG IDL interface. In object-oriented (OO) lan-guages, such as C++ and Java, servants are implemented us-ing one or more class instances. In non-OO languages, suchas C, servants are typically implemented using functions andstruct s. A client never interacts with servants directly, butalways through objects identified by object references. To-gether, an object and its servant form an implementation ofthe Bridge pattern [15], withobjectas theRefinedAbstractionandservantas theConcreteImplementor.

ORB Core: When a client invokes an operation on an ob-ject, the ORB Core is responsible for delivering the requestto the object and returning a response, if any, to the client.An ORB Core is implemented as a run-time library linkedinto client and server applications. For objects executing re-motely, a CORBA-compliant ORB Core communicates via aversion of the General Inter-ORB Protocol (GIOP), such asthe Internet Inter-ORB Protocol (IIOP) that runs atop the TCPtransport protocol. In addition, custom Environment-SpecificInter-ORB protocols (ESIOPs) can also be defined [16].

ORB Interface: An ORB is an abstraction that can be im-plemented various ways,e.g., one or more processes or a setof libraries. To decouple applications from implementationdetails, the CORBA specification defines an interface to anORB. This ORB interface provides standard operations to ini-tialize and shut down the ORB, convert object references to

2

strings and back, and create argument lists for requests madethrough thedynamic invocation interface(DII).

OMG IDL Stubs and Skeletons: IDL stubs and skeletonsserve as a “glue” between the client and servants, respectively,and the ORB. Stubs implement theProxy pattern [15] andprovide a strongly-typed,static invocation interface(SII) thatmarshals application parameters into a common message-levelrepresentation. Conversely, skeletons implement theAdapterpattern [15] and demarshal the message-level representationback into typed parameters that are meaningful to an applica-tion.

IDL Compiler: An IDL compiler transforms OMG IDLdefinitions into stubs and skeletons that are generated automat-ically in an application programming language, such as C++or Java. In addition to providing programming language trans-parency, IDL compilers eliminate common sources of networkprogramming errors and provide opportunities for automatedcompiler optimizations [17].

Dynamic Invocation Interface (DII): The DII allowsclients to generate requests at run-time, which is useful whenan application has no compile-time knowledge of the inter-face it accesses. The DII also allows clients to makedeferredsynchronouscalls, which decouple the request and responseportions of two-way operations to avoid blocking the clientuntil the servant responds. CORBA SII stubs support bothsynchronous and asynchronoustwo-way, i.e., request/responseandone-way, i.e., request-only operations.

Dynamic Skeleton Interface (DSI): The DSI is the server’sanalogue to the client’s DII. The DSI allows an ORB to deliverrequests to servants that have no compile-time knowledge ofthe IDL interface they implement. Clients making requestsneed not know whether the server ORB uses static skeletons ordynamic skeletons. Likewise, servers need not know if clientsuse the DII or SII to invoke requests.

Object Adapter: An Object Adapter is a composite compo-nent that associates servants with objects, creates object refer-ences, demultiplexes incoming requests to servants, and col-laborates with the IDL skeleton to dispatch the appropriateoperation upcall on a servant. Object Adapters enable ORBsto support various types of servants that possess similar re-quirements. This design results in a smaller and simpler ORBthat can support a wide range of object granularities, lifetimes,policies, implementation styles, and other properties.

Interface Repository: The Interface Repository providesrun-time information about IDL interfaces. Using this infor-mation, it is possible for a program to encounter an objectwhose interface was not known when the program was com-piled, yet be able to determine what operations are valid on theobject and make invocations on it using the DII. In addition,the Interface Repository provides a common location to store

additional information associated with interfaces to CORBAobjects, such as type libraries for stubs and skeletons.

Implementation Repository: The Implementation Reposi-tory [18] contains information that allows an ORB to activateservers to process servants. Most of the information in the Im-plementation Repository is specific to an ORB or OS environ-ment. In addition, the Implementation Repository provides acommon location to store information associated with servers,such as administrative control, resource allocation, security,and activation modes.

2.2 Overview of TAO

TAO is a high-performance, real-time ORB endsystem tar-geted for applications with deterministic and statistical QoSrequirements, as well as best-effort requirements. TAO’s ORBendsystem contains the network interface, OS, communicationprotocol, and CORBA-compliant middleware components andservices shown in Figure 2. TAO supports the standard OMG

NETWORKNETWORK

ORBORB RUN RUN--TIMETIME

SCHEDULERSCHEDULER

operation()operation()

IDLIDLSTUBSSTUBS

IDLIDLSKELETONSKELETON

in argsin args

out args + return valueout args + return value

CLIENTCLIENT

OS KERNELOS KERNEL

HIGHHIGH--SPEEDSPEED

NETWORK INTERFACENETWORK INTERFACE

REALREAL--TIME ITIME I//OOSUBSYSTEMSUBSYSTEM

OBJECTOBJECT((SERVANTSERVANT))

OS KERNELOS KERNEL

HIGHHIGH--SPEEDSPEED

NETWORK INTERFACENETWORK INTERFACE

REALREAL--TIME ITIME I//OOSUBSYSTEMSUBSYSTEM

ACEACE COMPONENTSCOMPONENTS

OBJOBJ

REFREF

REALREAL--TIMETIME ORBORB CORECOREIOPIOP

PLUGGABLEPLUGGABLE

ORBORB & & XPORTXPORT

PROTOCOLSPROTOCOLS

IOPIOPPLUGGABLEPLUGGABLE

ORBORB & & XPORTXPORT

PROTOCOLSPROTOCOLS

REALREAL--TIMETIME

OBJECTOBJECT

ADAPTERADAPTER

Figure 2: Components in the TAO Real-time ORB Endsystem

CORBA reference model [14] and Real-time CORBA speci-fication [19], with enhancements designed to ensure efficient,predictable, and scalable QoS behavior for high-performanceand real-time applications. In addition, TAO is well-suited forgeneral-purpose distributed applications. Below, we outlinethe features of TAO’s components shown in Figure 2.

Optimized IDL Stubs and Skeletons: IDL stubs and skele-tons perform marshaling and demarshaling of application op-eration parameters, respectively. TAO’s IDL compiler gener-ates stubs/skeletons that can selectively use highly optimizedcompiled and/or interpretive (de)marshaling [20]. This flex-ibility allows application developers to selectively trade off

3

time and space, which is crucial for high-performance, real-time, and/or embedded distributed systems.

Real-time Object Adapter: An Object Adapter associatesservants with the ORB and demultiplexes incoming requeststo servants. TAO’s real-time Object Adapter uses perfect hash-ing [21] and active demultiplexing [22] optimizations to dis-patch servant operations in constantO(1) time, regardless ofthe number of active connections, servants, and operations de-fined in IDL interfaces.

Run-time Scheduler: TAO’s run-time scheduler [19] mapsapplication QoS requirements, such as bounding end-to-endlatency and meeting periodic scheduling deadlines, to ORBendsystem/network resources, such as CPU, memory, networkconnections, and storage devices. TAO’s run-time schedulersupports both static [10] and dynamic [23] real-time schedul-ing strategies.

Real-time ORB Core: An ORB Core delivers client re-quests to the Object Adapter and returns responses (if any) toclients. TAO’s real-time ORB Core [24] uses a multi-threaded,preemptive, priority-based connection and concurrency archi-tecture [20] to provide an efficient and predictable CORBAprotocol engine. TAO’s ORB Core allows customized proto-cols to be plugged into the ORB without affecting the standardCORBA application programming model [25].

Real-time I/O subsystem: TAO’s real-time I/O (RIO) sub-system [26] extends support for CORBA into the OS. RIO as-signs priorities to real-time I/O threads so that the schedulabil-ity of application components and ORB endsystem resourcescan be enforced. When integrated with advanced hardware,such as the high-speed network interfaces described below,RIO can (1) perform early demultiplexing of I/O events ontoprioritized kernel threads to avoid thread-based priority inver-sion and (2) maintain distinct priority streams to avoid packet-based priority inversion. TAO also runs efficiently and as pre-dictably as possible on conventional I/O subsystems that lackadvanced QoS features.

High-speed network interface: At the core of TAO’s I/Osubsystem is a “daisy-chained” network interface consistingof one or more ATM Port Interconnect Controller (APIC)chips [27]. The APIC is designed to sustain an aggregate bi-directional data rate of 2.4 Gbps using zero-copy buffering op-timization to avoid data copying across endsystem layers. Inaddition, TAO runs on conventional real-time interconnects,such as VME backplanes and multi-processor shared memoryenvironments, as well as TCP/IP.

TAO internals: TAO is developed using lower-level mid-dleware called ACE [28], which implements core concur-rency and distribution patterns [8] for communication soft-ware. ACE provides reusable C++ wrapper facades and frame-work components that support the QoS requirements of high-

performance, real-time applications and higher-level middle-ware like TAO. ACE and TAO run on a wide range of OS plat-forms, including Win32, most versions of UNIX, and real-timeoperating systems, such as Sun/Chorus ClassiX, LynxOS, andVxWorks.

To expedite our project goals, and to avoid re-inventing ex-isting components, we based TAO on SunSoft IIOP, which isa freely available C++ reference implementation of the Inter-net Inter-ORB Protocol (IIOP) version 1.0. Although SunSoftIIOP provides core features of a CORBA ORB it also has thefollowing limitations:

Lack of standard ORB features: Although SunSoft IIOPprovides an ORB Core, an IIOP 1.0 protocol engine, and aDII and DSI implementation, it lacks an IDL compiler, anInterface Repository and Implementation Repository, and aPortable Object Adapter (POA). TAO implements all thesemissing features and provides newer CORBA features, asyn-chronous method invocations [29], real-time CORBA [19] fea-tures [30], and fault tolerance CORBA features [31, 32].

Lack of IIOP optimizations: Due to the excessive marshal-ing/demarshaling overhead, data copying, and high-levels offunction call overhead, SunSoft IIOP performs poorly overhigh-speed networks. Therefore, we applied a range of opti-mization principle patterns [22] that improved its performanceconsiderably [33]. The principles that directed our optimiza-tions include: (1) optimizing for the common case, (2) elim-inating gratuitous waste, (3) replacing general-purpose meth-ods with efficient special-purpose ones, (4) precomputing val-ues, if possible, (5) storing redundant state to speed up expen-sive operations, (6) passing information between layers, and(7) optimizing for processor cache affinity.

This paper does not discuss how TAO solves the limitationswith SunSoft IIOP outlined above, which are described in de-tail in [10, 20]. Instead, we focus on how TAO uses patternsto implement an ORB that overcomes the following SunSoftIIOP limitations while simultaneously preserving its QoS ca-pabilities:

Lack of portability: Like most communication software,SunSoft IIOP is programmed directly using low-level net-working and OS APIs, such as sockets,select , and POSIXPthreads. Not only are these APIs tedious and error-prone,they are also not portable across OS platforms,e.g., many op-erating systems lack Pthreads support. Section 3.3.1 illustrateshow we used theWrapper Facadepattern [15] to improveTAO’s portability.

Lack of configurability: Like many ORBs and other mid-dleware, SunSoft IIOP is configuredstatically, which makesit hard to extend without modifying its source code directly.

4

This violated a key design goal of TAO, namelydynamicadap-tation to diverse application requirements and system environ-ments. Sections 3.3.7, 3.3.6, and 3.3.8 explain how we usedtheAbstract Factory[15], Strategy[15], andComponent Con-figurator [8] patterns to simplify the TAO’s configurability fordifferent use-cases.

Lack of software cohesion: Like many applications, Sun-Soft IIOP focuses on solving a specific problem,i.e., imple-menting an ORB Core and an IIOP protocol engine. It ac-complish this using a tightly-coupled,ad-hocimplementationthat hard-codes key ORB design decisions. Sections 3.3.7and 3.3.6 explain how we usedAbstract FactoryandStrategyto decrease the unnecessary coupling and increase cohesionwhen evolving SunSoft IIOP to TAO.

3 Applying a Pattern Language toBuild Extensible ORB Middleware

3.1 Why We Need Dynamically ConfigurableMiddleware

A key motivation for ORB middleware is to offload complex,lower-level distributed system infrastructure tasks from appli-cation developers to ORB developers. ORB developers are re-sponsible for implementing reusable middleware componentsthat handle connection management, interprocess communica-tion, concurrency, transport endpoint demultiplexing, schedul-ing, dispatching, (de)marshaling, and error handling. Thesecomponents are typically compiled into a run-time ORB li-brary, linked with application objects that use the ORB com-ponents, and executed in one or more OS processes.

Although this separation of concerns can simplify applica-tion development, it can also yield inflexible and inefficientapplications and middleware architectures. The primary rea-son is that many conventional ORBs are configuredstaticallyat compile-time and link-time by ORB developers, rather thandynamicallyat installation-time or run-time by applicationdevelopers. Statically configured ORBs have the followingdrawbacks [28]:

Inflexibility: Statically-configured ORBs tightly coupleeach component’simplementationwith the configurationofinternal ORB components,i.e., which components work to-gether and how they work together. As a result, extendingstatically-configured ORBs requires modifications to existingsource code. In commercial non-open-source ORBs, this codemay not be accessible to application developers.

Even if source code is available, extending statically-configured ORBs requires recompilation and relinking. More-over, any currently executing ORBs and their associated ob-jects must be shutdown and restarted. This static reconfigura-

tion process is not well-suited for application domains, suchas telecom call processing, that require 7�24 availability [34].

Inefficiency: Statically-configured ORBs can be inefficient,both in terms of space and time. Space inefficiency can oc-cur if unnecessary components are always statically config-ured into an ORB. This can increase the ORB’s memory foot-print, forcing applications to pay a space penalty for featuresthey do not require. Overly large memory footprints are par-ticularly problematic for embedded systems, such as cellularphones or telecom switch line cards [35].

Time inefficiency can stem from restricting an ORB to usestatically configured algorithms or data structures for key pro-cessing tasks, thereby making it hard for application develop-ers to customize an ORB to handle new use-cases. For in-stance, real-time avionics systems [11] often can instantiateall their servants off-line. These systems can benefit from anORB that uses perfect hashing or active demultiplexing [36] todemultiplex incoming requests to servants. Thus, ORBs thatare configured statically to use a general-purpose, “one-size-fits-all” demultiplexstrategy, such as dynamic hashing, mayperform poorly for mission-critical systems.

In theory, the drawbacks with static configuration describedabove areinternal to ORBs and should not affect applicationdevelopers directly. In practice, however, application devel-opers are inevitably affected since the quality, portability, us-ability, and performance of the ORB middleware is reduced.Therefore, an effective way to improve ORB extensibility isto develop ORB middleware that can be both staticallyanddynamically configured.

Dynamic configuration enables the selective integration ofcustomized implementations for key ORB strategies, such asconnection management, communication, concurrency, de-multiplexing, scheduling, and dispatching. This design allowsORB developers to concentrate on thefunctionalityof ORBcomponents, without committing themselves prematurely toa specificconfigurationof these components. Moreover, dy-namic configuration enables application developers and ORBdevelopers to change design decisions late in the system life-cycle,i.e., at installation-time or run-time.

Figure 3 illustrates the following key dimensions of ORBextensibility:

1. Extensibility to retarget the ORB on new platforms,which requires that the ORB be implemented using modularcomponents that shield it from non-portable system mecha-nisms, such as those for threading, communication, and eventdemultiplexing. OS platforms such as POSIX, Win32, Vx-Works, and MVS provide a wide variety of system mecha-nisms.

2. Extensibility via custom implementation strategies,which can be tailored to specific application requirements. For

5

1 POSIX,POSIX, WWININ32,32, RTOSRTOSSS,, MVSMVS

3 DLLDLLSS

2

strategy2

strategy1

strategy3 profile2

profile1

profile3

profile4

Figure 3: Dimensions of ORB Extensibility

instance, ORB components can be customized to meet peri-odic deadlines in real-time systems [11]. Likewise, ORB com-ponents can be customized to account for particular systemcharacteristics, such as the availability of asynchronous I/O orhigh-speed ATM networks.

3. Extensibility via dynamic configuration of customstrategies,which takes customization to the next level by dy-namically linking only those strategies that are necessary for aspecific ORB “personality.” For example, different applicationdomains, such as medical systems or telecom call processing,may require custom combinations of concurrency, scheduling,or dispatch strategies. Configuring these strategies at run-timefrom dynamically linked libraries (DLLs) can (1) reduce thememory footprint of an ORB and (2) make it possible for ap-plication developers to extend the ORB without requiring ac-cess or changes to the original source code.

Below, we describe the pattern language applied to enhancethe extensibility of TAO along each dimension outlined above.

3.2 Overview of a Pattern Language that Im-proves ORB Extensibility

This section uses TAO as a case study to illustrate a patternlanguage that can help developers of applications and ORBsbuild, maintain, and extend communication software by re-ducing the coupling between components. Figure 4 shows thepatterns in the pattern language that we applied to develop anextensible ORB architecture for TAO. It is beyond the scopeof this paper to describe each pattern in detail or to discussall the patterns used within TAO. Instead, we focus on howkey patterns can improve the extensibility and performance ofreal-time ORB middleware. The references in [9, 15] containcomprehensive descriptions of these patterns and [8] explainshow the patterns can be woven together to form a pattern lan-guage.

ACCEPTORCONNECTOR

ABSTRACTFACTORY

SERVANTCLIENT

OS KERNELOS KERNEL

LEADER /FOLLOWERS

THREAD -SPECIFICSTORAGE

COMPONENTCONFIGURATOR

REACTOR

WRAPPER FACADES

STRATEGY

Figure 4: Applying a Pattern Language to TAO

The intent and usage of the patterns in this language areoutlined below:

Wrapper Facade [8]: This pattern encapsulates the func-tions and data provided by existing non-OO APIs withinmore concise, robust, portable, maintainable, and cohesiveOO class interfaces. TAO uses this pattern to avoid tedious,non-portable, and non-typesafe programming of low-level,OS-specific system calls, such as the Socket API or POSIXthreads.

Reactor [8]: This pattern structures event-driven applica-tions, particularly servers, that receive requests from multipleclients concurrently but process them iteratively. TAO usesthis pattern to notify ORB-specific handlers synchronouslywhen I/O events occur in the OS. The Reactor pattern drivesthe main event loop in TAO’s ORB Core, which accepts con-nections and receives/sends client requests/responses.

Acceptor-Connector [8]: This pattern decouples connec-tion establishment and service initialization from service pro-cessing in a networked system. TAO uses this pattern in theORB Core on servers and clients to passively and actively es-tablish GIOP connections that are independent of the underly-ing transport mechanisms.

Leader/Followers [8]: This pattern provides an efficientconcurrency model in which multiple threads take turns toshare a set of event sources to detect, demultiplex, dispatchand process service requests that occur on the event sources.TAO uses this pattern uses this pattern to facilitate the use ofmultiple concurrency strategies that can be configured flexiblyinto its ORB Core at run-time.

Thread-Specific Storage [8]: This pattern allows multiplethreads to use a “logically global” access point to retrieve an

6

object that is local to a thread, without incurring locking over-head for each access to the object. TAO uses this pattern tominimize lock contention and priority inversion for real-timeapplications.

Strategy [15]: This pattern provides an abstraction for se-lecting one of several candidate algorithms and packaging itinto an object. TAO uses this pattern throughout its softwarearchitecture to extensibly configure custom ORB strategies forconcurrency, communication, scheduling, and demultiplexing.

Abstract Factory [15]: This pattern provides a single com-ponent that builds related objects. TAO uses this pattern toconsolidate its dozens ofStrategyobjects into a manageablenumber of abstract factories that can be reconfigureden masseinto clients and servers conveniently and consistently. TAOcomponents use these factories to access related strategieswithout specifying their subclass name explicitly.

Component Configurator [8]: This pattern allows an ap-plication to link and unlink its component implementations atrun-time without having to modify, recompile or statically re-link the application. It also supports the reconfiguration ofcomponents into different processes without having to shutdown and re-start running processes. TAO uses this patternto dynamically interchangeabstract factoryimplementationsin order to customize ORB personalities at run-time.

The patterns constituting this pattern language are not lim-ited to ORBs or communication middleware. They have beenapplied in many other communication application domains, in-cluding telecom call processing and switching, avionics flightcontrol systems, multimedia teleconferencing, and distributedinteractive simulations.

3.3 How to Use a Pattern Language to ResolveORB Design Challenges

In the following discussion, we outline the forces underlyingthe key design challenges that arise when developing extensi-ble real-time ORBs. We also describe which pattern(s) in ourpattern language resolve these forces and explain how thesepatterns are used in TAO. In addition, we show how the ab-sence of these patterns in an ORB leaves these forces unre-solved. To illustrate this latter point concretely, we compareTAO with SunSoft IIOP. Since TAO evolved from the SunSoftIIOP release, it provides an ideal baseline to evaluate the im-pact of patterns on the software qualities of ORB middleware.

3.3.1 Encapsulate Low-level System Mechanisms withthe Wrapper FacadePattern

Context: One role of an ORB is to shield application-specific clients and servants from the details of low-level sys-tems programming. Thus, ORB developers, rather than appli-

cation developers, are responsible for tedious, low-level net-work programming tasks, such as demultiplexing events, send-ing and receiving GIOP messages across the network, andspawning threads to execute client requests concurrently. Fig-ure 5 illustrates a common approach used by SunSoft IIOP,

POSIXPOSIXPthreadsPthreads

BSDBSDSocketsSockets

WinSockWinSock

SocketSocketMacrosMacros Other OSOther OS

System CallsSystem Calls

pthread_create()pthread_create()

pthread_mutex_*pthread_mutex_*

socket(), bind(),socket(), bind(),

recv(), send()recv(), send()

gettimeofday(),gettimeofday(),

select(), etc.select(), etc.

SunSoft IIOP's ORB CoreSunSoft IIOP's ORB Core

GENERALGENERAL

POSIXPOSIX &&WWININ3232

SERVICESSERVICES

Figure 5: SunSoft IIOP Operating System Interaction

which is programmed internally using system mechanisms,such as sockets,select , and POSIX threads.

Problem: Developing an ORB is hard. It is even harder ifdevelopers must wrestle with low-level system mechanismswritten in languages like C, which often yield the followingproblems:

� ORB developers must have intimate knowledge of manyOS platforms: Implementing an ORB using system-level CAPIs forces developers to deal with non-portable, tedious, anderror-prone OS idiosyncrasies, such as using untyped sockethandles to identify transport endpoints. Moreover, these APIsare not portable across OS platforms. For example, Win32lacks POSIX Pthreads and has subtly different semantics forsockets andselect .

� Increased maintenance effort: One way to build anORB is to handle portability variations via explicit conditionalcompilation directives in ORB source code. However, usingconditional compilation to address platform-specific variationsat all points of useincreases the complexity of the source code,as shown in Section 3.5. Extending such ORBs is hard sinceplatform-specific details are scattered throughout the imple-mentation source code files.

� Inconsistent programming paradigms: System mecha-nisms are accessed through C-style function calls, which causean “impedance mismatch” with the OO programming stylesupported by C++, the language we use to implement TAO.

How can we avoid accessing low-level system mechanismswhen implementing an ORB?

Solution ! the Wrapper Facade pattern: An effectiveway to avoid accessing system mechanisms directly is to usetheWrapper Facadepattern [8], which is a variant of the Fa-cade pattern [15]. The intent of the Facade pattern is to sim-plify the interface for a subsystem. The intent of the WrapperFacade pattern is more specific: it provides typesafe, modu-lar, and portable OO interfaces that encapsulate lower-level,

7

stand-alone system mechanisms, such as sockets,select ,and POSIX threads. In general, the Wrapper Facade patternshould be applied when existing system-level APIs are non-portable and non-typesafe.

Using the Wrapper Facade pattern in TAO: TAO accessesall system mechanisms via the wrapper facades provided byACE [28]. Figure 6 illustrates how the ACE C++ wrapperfacades improve TAO’s robustness and portability by encap-sulating and enhancing native OS concurrency, communica-tion, memory management, event demultiplexing, and dy-namic linking mechanisms with typesafe OO interfaces. The

TAO's ORB CoreTAO's ORB Core

spawn()spawn()

acquire()acquire()

open(),open(),close(),close(),

recv(), send()recv(), send()

dlopen()dlopen()

dlsym()dlsym()

COMMUNICATIONCOMMUNICATION

SUBSYSTEMSUBSYSTEM

VIRTUALVIRTUAL

MEMORY MEMORY

SUBSYSTEMSUBSYSTEM

GENERALGENERAL

POSIXPOSIX && WWININ3232

SERVICESSERVICES

PROCESSPROCESS//THREADTHREAD

SUBSYSTEMSUBSYSTEM

THREADTHREAD

WRAPPERSWRAPPERS

DYNAMIC

LINKING

SELECT/IO COMP

SOCKETS/TLI

ACEWRAPPER

FACADES

handle_events()

Figure 6: Using the Wrapper Facade Pattern to EncapsulateNative OS Mechanisms

OO encapsulation provided by ACE alleviates the need forTAO to access weakly-typed system APIs directly. Thus, C++compilers can detect type system violations at compile-timerather than waiting for the problems to occur at run-time.

The ACE wrapper facades use C++ features to eliminateperformance penalties that would otherwise be incurred fromits additional type safety and layer of abstraction. For instance,inlining is used to avoid the overhead of calling small meth-ods. Likewise, static methods are used to avoid the overheadof passing a C++this pointer to each invocation.

Although the ACE wrapper facades resolve several commonlow-level development problems, they are just the first step to-wards developing an extensible ORB. The remaining patternsdescribed in this section build on the encapsulation providedby the ACE wrapper facades to address more challenging ORBdesign issues.

3.3.2 Demultiplexing ORB Core Events Using the Reac-tor Pattern

Context: An ORB Core is responsible for demultiplexingI/O events from multiple clients and dispatching their asso-ciated event handlers. For instance, a server-side ORB Corelistens for new client connections and reads/writes GIOP re-quests/responses from/to connected clients. To ensure re-sponsiveness to multiple clients, an ORB Core uses OSevent demultiplexing mechanisms to wait forCONNECTION,

READ, andWRITE events to occur on multiple socket handles.Common event demultiplexing mechanisms includeselect ,WaitForMultipleObjects , I/O completion ports, andthreads.

Figure 7 illustrates a typical event demultiplexing se-quence for SunSoft IIOP. In (1), the server enters its event

ORB COREORB CORE

1: RUN EVENT LOOP

OBJECTOBJECT

ADAPTERADAPTER

APPLICATIONAPPLICATION

2: GET REQUEST

3: BLOCK FOR CONNECTION 6: INCOMING

MESSAGE

5: DISPATCH

SERVANTSERVANT

7: UPCALL

GIOPGIOP

EngineEngine4: select()

serverserver

endpointsendpoints

Figure 7: The SunSoft IIOP Event Loop

loop by (2) calling get request on the Object Adapter.The get request method then (3) calls the static methodblock for connection on the server endpoint .This method manages all aspects of server-side connectionmanagement, ranging from connection establishment to GIOPprotocol handling. The ORB remains blocked (4) onselectuntil the occurrence of I/O event, such as a connectionevent or a request event. When a request event occurs,block for connection demultiplexes that request to aspecificserver endpoint and (5) dispatches the event tothat endpoint. The GIOP Engine in the ORB Core then (6) re-trieves data from the socket and passes it to the Object Adapter,which demultiplexes it, demarshals it, and (7) dispatches theappropriate method upcall to the user-supplied servant.

Problem: One way to develop an ORB Core is to hard-code it to use one event demultiplexing mechanism, such asselect . Relying on just one mechanism is undesirable, how-ever, since no single scheme is efficient on all platforms or forall application requirements. For instance, asynchronous I/Ocompletion ports are highly efficient on Windows NT [37],whereas synchronous threads are an efficient demultiplexingmechanism on Solaris [33].

Another way to develop an ORB Core is to tightly couple itsevent demultiplexing code with the code that performs GIOPprotocol processing. For instance, the event demultiplexinglogic of SunSoft IIOP is not a self-contained component. In-stead, it is closely intertwined with subsequent processing of

8

client request events by the Object Adapter and IDL skele-tons. In this case, however, the demultiplexing code cannot bereused as a blackbox component by other communication mid-dleware applications, such as HTTP servers [37] or video-on-demand servers. Moreover, if new ORB strategies for thread-ing or Object Adapter request scheduling algorithms are in-troduced, substantial portions of the ORB Core must be re-written.

How then can an ORB implementation decouple itself froma specific event demultiplexing mechanism and decouple itsdemultiplexing code from its handling code?

Solution ! the Reactor pattern: An effective way to re-duce coupling and increase the extensibility of an ORB Coreis to apply theReactorpattern [8]. This pattern supportssynchronous demultiplexing and dispatching of multipleeventhandlers, which are triggered by events that can arrive concur-rently from multiple sources. The Reactor pattern simplifiesevent-driven applications by integrating the demultiplexing ofevents and the dispatching of their corresponding event han-dlers. In general, the Reactor pattern should be applied whenapplications or components, such as an ORB Core, must han-dle events from multiple clients concurrently, without becom-ing tightly coupled to a single low-level mechanism, such asselect .

Note that applying the Wrapper Facade pattern is not suffi-cient to resolve the event demultiplexing problems outlinedabove. A wrapper facade forselect may improve ORBCore portability somewhat. However, this pattern alone doesnot resolve the need to completely decouple the low-levelevent demultiplexing logic from the higher-level client requestprocessing logic in an ORB Core. Recognizing the limitationsof the Wrapper Facade pattern, and then applying the Reactorpattern to overcome the limitations, is one of the benefits ofapplying a pattern language, rather than just isolated patterns.

Using the Reactor pattern in TAO: TAO uses the Re-actor pattern to drive the main event loop in its ORBCore, as shown in Figure 8. A TAO server (1) initi-ates an event loop in the ORB Core’sReactor , whereit (2) remains blocked onselect until an I/O event oc-curs. When a GIOP request event occurs, theReactordemultiplexes the request to the appropriate event handler,which is the GIOPConnection Handler that is associ-ated with each connected socket. TheReactor (3) then callsConnection Handler::handle input , which (4) dis-patches the request to TAO’s Object Adapter. The ObjectAdapter demultiplexes the request to the appropriate upcallmethod on the servant and (5) dispatches the upcall.

The Reactor pattern enhances the extensibility of TAOby decoupling the event handling portions of its ORBCore from the underlying OS event demultiplexing mech-anisms. For example, theWaitForMultipleObjects

ORB COREORB CORE

1: RUN EVENT LOOP

OBJECTOBJECT

ADAPTERADAPTER

APPLICATIONAPPLICATION

3: handle_input()

4: DISPATCH

SERVANTSERVANT

5: UPCALL

ACTIVE OBJECT MAPACTIVE OBJECT MAP

2: select()

ReactorReactor

ConnectionConnectionHandlerHandler



Figure 8: Using the Reactor Pattern in TAO’s Event Loop

event demultiplexing system call can be used on Win-dows NT, whereasselect can be used on UNIX plat-forms. Moreover, the Reactor pattern simplifies the con-figuration of new event handlers. For instance, adding anew Secure Connection Handler that performs en-cryption/decryption of all network traffic will not affect theReactor ’s implementation. Finally, unlike the event demul-tiplexing code in SunSoft IIOP, which is tightly coupled toone use-case, the ACE implementation of the Reactor pattern[8] used by TAO has been applied in many other OO event-driven applications ranging from HTTP servers [37] to real-time avionics infrastructure [11].

3.3.3 Managing Connections in an ORB Using theAcceptor-Connector Pattern

Context: Managing connections is another key responsi-bility of an ORB Core. For instance, an ORB Core thatimplements the IIOP protocol must establish TCP connec-tions and initialize the protocol handlers for each IIOPserver endpoint . By localizing connection managementlogic in the ORB Core, application-specific servants can focussolely on processing client requests, rather than dealing withlow-level network programming tasks.

An ORB Core is notlimited to running over IIOP and TCPtransports, however. For instance, while TCP can transferGIOP requests reliably, its flow control and congestion controlalgorithms can preclude its use as a real-time protocol [10].Likewise, it may be more efficient to use a shared memorytransport mechanism when clients and servants are collocatedon the same endsystem. Thus, an ORB Core should be flexibleenough to support multiple transport mechanisms [16].

Problem: The CORBA architecture explicitly decouples (1)the connection management tasks performed by an ORB Core

9

from (2) the request processing performed by application-specific servants. However, a common way to implementan ORB’s internal connection management activities is touse low-level network APIs, such as Sockets. Likewise, theORB’s connection establishment protocol is often tightly cou-pled with its communication protocol.

For example, Figure 9 illustrates the connection manage-ment structure of SunSoft IIOP. The client-side of SunSoft

ORB COREORB CORE1: lookup()

2: connect() 4: accept()

5: read()/write()

5: read()/write()clientclient

endpointendpoint

clientclientendpointendpoint

clientclientendpointendpoint

serverserverendpointendpoint

listenerlistenerendpointendpoint

serverserverendpointendpoint

3: select()3: select()

SERVERCLIENT

Figure 9: Connection Management in SunSoft IIOP

IIOP implements a hard-coded connection cachingstrategythat uses a linked-list ofclient endpoint objects. Asshown in Figure 9, this list is traversed to find an unusedendpoint whenever (1) client endpoint::lookup iscalled. If no unusedclient endpoint to the server isin the cache, a new connection (2) is initiated; otherwise anexisting connection is reused. Likewise, the server-side usesa linked list ofserver endpoint objects to generate theread/write bitmasks required by the (3) select event de-multiplexing mechanism. This list maintains passive transportendpoints that (4) accept connections and (5) receive requestsfrom clients connected to the server.

The problem with SunSoft IIOP’s design is that it tightlycouples (1) the ORB’s connection management implemen-tation with the socket network programming API and (2)the TCP/IP connection establishment protocol with the GIOPcommunication protocol, thereby yielding the following draw-backs:

� Inflexibility: If an ORB’s connection management datastructures and algorithms are too closely intertwined, substan-tial effort is required to modify the ORB Core. For instance,tightly coupling the ORB to use the Socket API makes it hardto change the underlying transport mechanism,e.g., to useshared memory rather than Sockets. Thus, it can be hard toport such a tightly coupled ORB Core to new communicationmechanisms, such as ATM, Fibrechannel, or shared memory,or different network programming APIs, such as TLI or Win32Named Pipes.

� Inefficiency: Many internal ORB strategies can be op-timized by allowing both ORB developers and application de-velopers to select appropriate implementations late in the soft-ware development cycle,e.g., after systematic performanceprofiling. For example, to reduce lock contention and over-head, a multi-threaded, real-time ORB client may need to storetransport endpoints in thread-specific storage [8]. Similarly,the concurrency strategy for a CORBA server might requirethat each connection run in its own thread to eliminate per-request locking overhead. If connection management mech-anisms are hard-coded and tightly bound with other internalORB strategies, however, it is hard to accommodate efficientnew strategies.

How then can an ORB Core’s connection management com-ponents support multiple transports and allow connection-related behaviors to be (re)configured flexibly late in the de-velopment cycle?

Solution! the Acceptor-Connector pattern: An effectiveway to increase the flexibility of ORB Core connection man-agement and initialization is to apply theAcceptor-Connectorpattern [8]. This pattern decouples connection initializationfrom the processing performed after a connection endpoint isinitialized. TheAcceptor component in this pattern is re-sponsible forpassiveinitialization, i.e., the server-side of theORB Core. Conversely, theConnector component in thepattern is responsible foractive initialization, i.e., the client-side of the ORB Core. In general, the Acceptor-Connector pat-tern should be applied when client/server middleware must al-low flexible configuration of network programming APIs andmust maintain proper separation of initialization roles.

Using the Acceptor-Connector pattern in TAO: TAO usesthe Acceptor-Connector pattern in conjunction with the Reac-tor pattern to handle connection establishment for GIOP/IIOPcommunication. Within TAO’s client-side ORB Core, aConnector initiates connections to servers in response to anoperation invocation or an explicit binding to a remote object.Within TAO’s server-side ORB Core, anAcceptor creates aGIOP Connection Handler to service each new clientconnection. Acceptor s and Connection Handler sboth derive from anEvent Handler , which enable themto be dispatched automatically by aReactor .

TAO’s Acceptors andConnectors can be configuredwith any transport mechanisms, such as Sockets or TLI, pro-vided by the ACE wrapper facades. In addition, TAO’sAcceptor and Connector can be imbued with customstrategies to select an appropriate concurrency mechanism, asdescribed in Section 3.3.4.

Figure 10 illustrates the use ofAcceptor-Connectorstrate-gies in TAO’s ORB Core. When a client (1) invokesa remote operation, it makes aconnect call through aStrategy Connector . This Strategy Connector

10

GIOPGIOP

HandlerHandler

Strategy StrategyConnectorConnector

Cached Cached

ConnectConnect

StrategyStrategy


ReactorReactor

ORBORB CORECORE

SERVERSERVERCLIENTCLIENT

5:5: REQUEST REQUEST//RESPONSERESPONSE

2: connect()2: connect() 3: accept()3: accept()

0..N

6: DISPATCH()

4: CREATE & ACTIVATE

1: operation()

ConnectionHandler

ConnectionHandler

ConnectionHandler

Concurrency

Strategy

StrategyAcceptor

Figure 10: Using the Acceptor-Connector Pattern in TAO’sConnection Management

(2) consults itsconnection strategyto obtain a connection.In this example, the client uses a “caching connection strat-egy” that recycles connections to the server and only createsnew connections when existing connections are all busy. Thiscaching strategy minimizes connection setup time, thereby re-ducing end-to-end request latency.

In the server-side ORB Core, theReactor notifiesTAO’s Strategy Acceptor to (3) accept newly con-nected clients and createConnection Handlers . TheStrategy Acceptor delegates the choice of concurrencymechanism to one of TAO’sconcurrencystrategies,e.g., reac-tive, thread-per-connection, or thread-per-priority, describedin Section 3.3.4. After aConnection Handler is acti-vated (4) within the ORB Core, it performs the requisite GIOPprotocol processing (5) on a connection and ultimately dis-patches (6) the request to the appropriate servant via TAO’sObject Adapter.

3.3.4 Simplifying ORB Concurrency Using theLeader/Followers Pattern

Context: After the Object Adapter has dispatched a clientrequest to the appropriate servant, the servant executes the re-quest. Execution may occur in the same thread of control astheConnection Handler that received it. Conversely, ex-ecution may occur in a different thread, concurrent with otherrequest executions.

The Real-time CORBA specification [38] defines a threadpool API. In addition, the CORBA specification defines an in-terface on the POA for an application to specify that all re-quests be handled by a single thread or be handled using anORB’s internal multi-threading policy. To meet application

QoS requirements, it is important to develop ORBs that im-plement these various concurrency APIs efficiently [24]. Con-currency allows long-running operations to execute simulta-neously without impeding the progress of other operations.Likewise, preemptive multi-threading is crucial to minimizethe dispatch latency of real-time systems [11].

Concurrency is often implemented via the multi-threadingcapabilities available on OS platforms. For instance, Sun-Soft IIOP supports the two concurrency architectures shownin Figure 11: a single-threaded Reactive architecture anda thread-per-connection architecture. SunSoft IIOP’s reac-

select()select()

2: NOTIFY

ORB CORE

serverendpoint

REACTIVE

1: ARRIVAL

3: READ

serverendpoint

select()

2: NOTIFY

ORB CORE

serverendpoint

1: ARRIVAL

3: READ

serverendpoint

THREAD-PERCONNECTION

Figure 11: SunSoft IIOP Concurrency Architectures

tive concurrency architecture usesselect within a sin-gle thread to dispatch each arriving request to an individualserver endpoint object, which subsequently reads the re-quest from the appropriate OS kernel queue. In (1), a requestarrives and is queued by the OS. Then,select fires, (2) no-tifying the associatedserver endpoint of a waiting re-quest. Theserver endpoint finally (3) reads the requestfrom the queue and processes it.

In contrast, SunSoft IIOP’s thread-per-connection architec-ture executes eachserver endpoint in its own threadof control, servicing all requests arriving on that connectionwithin its thread. After a connection is established,selectwaits for events on the connection’s descriptor. When (1) re-quests are received by the OS, the thread performingselect(2) reads one from the queue and (3) hands it off to aserver endpoint for processing.

Problem: In many ORBs, the concurrency architecture isprogrammed directly using the OS platform’s multi-threadingAPI, such as the POSIX threads API [39]. However, there areseveral drawbacks to this approach:

� Non-portable: Threading APIs are highly platform-specific. Even IEEE standards, such as POSIX threads [39],

11

are not available on many widely-used OS platforms, includ-ing Win32, VxWorks, and pSoS. Not only is there no directsyntactic mapping between APIs, but there is no clear map-ping of semantics either. For instance, POSIX threads sup-port deferred thread cancellation, whereas Win32 threads donot. Moreover, although Win32 has a thread termination API,the Win32 documentation strongly recommendsnot using itsince it does not release all thread resources after a thread ex-its. Moreover, even POSIX Pthread implementations are non-portable since many UNIX vendors support different drafts ofthe Pthreads specification.

� Hard to program correctly: Portability aside, program-ming a multi-threaded ORB is hard since application and ORBdevelopers must ensure that access to shared data is serializedproperly in the ORB and its servants. In addition, the tech-niques required to robustly terminate servants executing con-currently in multiple threads are complicated, non-portable,and non-intuitive.

� Non-extensible: The choice of an ORB concurrencystrategy depends largely on external factors like applicationrequirements and network/endsystem characteristics. For in-stance, reactive single-threading [8] is an appropriate strategyfor short duration, compute-bound requests on a uni-processor.If these external factors change, however, an ORB’s designshould be extensible enough to handle alternative concurrencystrategies, such as thread pool or thread-per-priority [24].

When ORBs are developed using low-level threading APIs,they are hard to extend with new concurrency strategieswith-out affecting other ORB components. For example, adding athread-per-request architecture to SunSoft IIOP would requireextensive changes in order to (1) store the request in athread-specific storage(TSS) variable during protocol processing, (2)pass the key to the TSS variable through the scheduling anddemarshaling steps in the Object Adapter, and (3) access therequest stored in TSS before dispatching the operation on theservant. Thus, there is no easy way to modify SunSoft IIOP’sconcurrency architecture without drastically changing its in-ternal structure.

How then can an ORB support a simple, extensible, andportable concurrency mechanism?

Solution ! the Leader/Followers pattern: An effectiveway to increase the portability, correctness, and extensibilityof ORB concurrency strategies is to apply theLeader/Follwerspattern [8]. This pattern provides an efficient concurrencymodel in which multiple threads take turns to share a set ofevent sources to detect, demultiplex, dispatch and process ser-vice requests that occur on the event sources. In general,the Leader/Followers pattern should be used when an appli-cation needs to minimize context switching, synchronization,and data copying, while still allowing multiple threads to runconcurrently.

While Wrapper Facadesprovide the basis for portability,they are simply a thin syntactic veneer over the low-level na-tive OS APIs. Moreover, a facade’s semantic behavior maystill vary across platforms. Therefore, the Leader/Followerspattern defines a higher-level concurrency abstraction thatshields TAO from the complexity of low-level thread fa-cades. By raising the level of abstraction for ORB developers,the Leader/Followers pattern makes it easier to define moreportable, flexible, and conveniently programmed ORB concur-rency strategies. For example, if the number of threads in thepool is 1, the Leader/Followers pattern behaves just like theReactor pattern.

Using the Leader/Followers pattern in TAO: TAO usesthe Leader/Followers pattern to demultiplex GIOP events toConnection Handler s handlers within a pool of threads.When using this pattern, an application pre-spawns afixednumber of threads. When these threads invoke TAO’s stan-dardORB::run method, one thread will become the leaderand wait for a GIOP event. After the leader leader thread de-tects the event, it promotes an arbitrary thread to become thenext leader it and then demultiplexes the event to its associatedConnection Handler , which processes the event concur-rently with respect to other threads in the ORB. This sequenceof steps is shown in Figure 12.

ORB CORE

LEADER

FOLLOWERS

2: read()

Reactor

1: select()

3: release()

server endpoint

DISPATCHER

server endpoint

4: dispatch upcall POA

Figure 12: Using the Leader/Followers Pattern to StructureTAO’s Concurrency Strategies

As shown in Figure 12, a pool of threads is allocated anda leader thread is chosen toselect (1) on connections forall servants in the server process. When a request arrives, thisthread reads (2) it into an internal buffer. If this is a validrequest for a servant, a follower thread in the pool is released tobecome the new leader (3) and the leader thread dispatches theupcall (4). After the upcall is dispatched, the original leaderthread becomes a follower and returns to the thread pool. New

12

requests are queued in socket endpoints until a thread in thepool is available to execute the requests.

3.3.5 Reducing Lock Contention and Priority Inversionswith the Thread-Specific Storage Pattern

Context: The Leader/Followers pattern allows applicationsand components in the ORB to run concurrently. The primarydrawback to concurrency, however, is the need toserializeaccess to shared resources. In an ORB, common shared re-sources include the dynamic memory heap, an ORB pseudo-object reference created by theCORBA::ORBinit initial-ization factory, theActive ObjectMap in a POA [22], and theAcceptor , Connector , and Reactor components de-scribed earlier. A common way to achieve serialization is touse mutual-exclusion locks on each resource shared by multi-ple threads.

Problem: In theory, multi-threading an ORB can improveperformance by executing multiple instruction streams simul-taneously. In addition, multi-threading can simplify inter-nal ORB design by allowing each thread to execute syn-chronously, rather than reactively or asynchronously. In prac-tice, however, multi-threaded ORBs often perform no better,or even worse, than single-threaded ORBs due to (1) the costof acquiring/releasing locks and (2) priority inversions thatarise when high- and low-priority threads contend for the samelocks [40]. In addition, multi-threaded ORBs are hard to pro-gram due to complex concurrency control protocols used toavoid race conditions and deadlocks.

Solution ! the Thread-Specific Storage pattern: An ef-fective way to minimize the amount of locking required toserialize access to resources shared within an ORB is to usethe Thread-Specific Storagepattern [8]. This pattern allowsmultiple threads in an ORB to use one logically global accesspoint to retrieve thread-specific datawithoutincurring lockingoverhead for each access.

In general, the Thread-Specific Storage pattern should beused when the data shared by objects within each thread mustbe accessed through a globally visible access point that is “log-ically” shared with other threads, but “physically” unique foreach thread.

Using the Thread-Specific Storage Pattern in TAO: TAOuses the Thread-Specific Storage pattern to minimize lock con-tention and priority inversion for real-time applications. In-ternally, each thread in TAO uses thread-specific storage tostore its ORB Core components,e.g., Reactor , Acceptor ,andConnector . When a thread accesses any of these com-ponents, they are retrieved by using akey as an index intothe thread’s internal thread-specific state, as shown in Fig-ure 13. Thus, no additional locking is required to accessthread-specific ORB state.

THREAD ATHREAD A THREAD BTHREAD B

1: ACE_OS::thr_getspecific(key)

2: get_state(key)

ORB THREAD-SPECIFIC STATE

Reactor

Acceptor

Connector

Reactor

Acceptor

Connector

THREAD-SPECIFICOBJECT TABLES

INDEXED BY KEY

Figure 13: Using the Thread-Specific Storage Pattern in TAO

3.3.6 Support Interchangeable ORB Behaviors with theStrategy Pattern

Context: Extensible ORBs must support multiple requestdemultiplexing and scheduling strategies in their ObjectAdapters. Likewise, they must support multiple connection es-tablishment, request transfer, and concurrent request process-ing strategies in their ORB Cores.

Problem: One way to develop an ORB is to provide onlystatic, non-extensible strategies, which are typically config-ured in the following ways:

� Preprocessor macros: Some strategies are determinedby the value of preprocessor macros. For example, sincethreading is not available on all OS platforms, conditionalcompilation is often used to select a feasible concurrencymodel.

� Command-line options: Other strategies are controlledby the presence or absence of flags on the command-line. Forinstance, command-line options can be used to selectively en-able ORB concurrency strategies for platforms that supportmulti-threading [24].

While these two configuration approaches are widely used,they are inflexible. For instance, preprocessor macros onlysupport compile-time strategy selection, whereas command-line options convey a limited amount of information to anORB. Moreover, these hard-coded configuration strategies aredivorced completely from any code they might affect. Thus,ORB components that want to use these options must (1) knowof their existence, (2) understand their range of values, and (3)provide an appropriate implementation for each value. Suchrestrictions make it hard to develop highly extensible ORBsthat are composed from transparently configurable strategies.

How then does an ORB (1) permit replacement of subsets ofcomponent strategies in a manner orthogonal and transparentto other ORB components and (2) encapsulate the state and

13

behavior of each strategy so that changes to one componentdo not permeate throughout an ORB haphazardly?

Solution! the Strategy pattern: An effective way to sup-port multiple transparently “pluggable” ORB strategies is toapply theStrategypattern [15]. This pattern factors out sim-ilarities among algorithmic alternatives and explicitly asso-ciates the name of a strategy with its algorithm and state.Moreover, the Strategy pattern removes lexical dependencieson strategy implementations since applications access special-ized behaviors only through common base class interfaces. Ingeneral, the Strategy pattern should be used when an applica-tion’s behavior can be configured via multiple interchangeablestrategies.

Using the Strategy Pattern in TAO: TAO uses a varietyof strategies to factor out behaviors that are often hard-codedin conventional ORBs. Several of these strategies are illus-trated in Figure 14. For instance, TAO supports multiple re-

Thread-Thread-SpecificSpecificConnectConnectStrategyStrategy

Cached CachedConnectConnectStrategyStrategy

Reactive ReactiveConcurrencyConcurrency

StrategyStrategy

Threaded ThreadedConcurrencyConcurrency

StrategyStrategy

SERVANT SERVANT 11 SERVANT NSERVANT N

IDLIDL

SKEL SKEL 22IDLIDL

SKEL NSKEL N

ORB COREORB CORE

SERVERSERVERCLIENTCLIENT

...... ............

SE

RV

AN

TS

ER

VA

NTN

::N

::O

PE

RA

TIO

NO

PE

RA

TIO

NKK

SE

RV

AN

TS

ER

VA

NTN

::N

::O

PE

RA

TIO

NO

PE

RA

TIO

N11

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

KK

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

22

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

11

(B) ACTIVE DEMUXING STRATEGY

index(object key)......

......

(A) PERFECT HASHING

DEMUXING

STRATEGY

OP

ER

AT

ION

OP

ER

AT

ION

KK

OP

ER

AT

ION

OP

ER

AT

ION

22

......

OP

ER

AT

ION

OP

ER

AT

ION

11

hash(operation)

hash(object key) OBJECTOBJECT

ADAPTERADAPTER

IDLIDL

SKEL SKEL 11

SERVANT SERVANT 22

ORB COREORB CORE

ORB COREORB CORE

StrategyStrategyAcceptorAcceptor

StrategyStrategyConnectorConnector

Figure 14: ORB Core and POA Strategies in TAO

quest demultiplexing strategies (e.g., perfect hashing vs. activedemultiplexing [36]) and dispatching strategies (i.e., FIFO vs.rate-based) in its Object Adapter, as well as connection man-agement strategies (e.g., process-wide cached connections vs.thread-specific cached connections) and handler concurrencystrategies (e.g., Reactive vs. variations of Leader/Followers)in its ORB Core.

3.3.7 Consolidate ORB Strategies Using the AbstractFactory Pattern

Context: There are many potential strategy variants sup-ported by TAO. Table 1 shows a simple example of the strate-gies used to create two configurations of TAO. Configuration 1

Strategy ConfigurationApplication Concurrency Dispatching Demultiplexing Protocol

Avionics Thread-per Priority Perfect VMEpriority -based hashing backplane

Medical Thread-per FIFO Active TCP/IPImaging connection demultiplexing

Table 1: Example Applications and their ORB Strategy Con-figurations

is an avionics application with deterministic real-time require-ments [11]. Configuration 2 is an electronic medical imagingapplication [41] with high throughput requirements. In gen-eral, the forces that must be resolved to compose all ORBstrategies correctly are the need to (1) ensure the configura-tion of semantically compatible strategies and (2) simplify themanagement of a large number of individual strategies.

Problem: An undesirable side-effect of using the Strategypattern extensively in complex ORB software–as well as othertypes of software–is that it becomes hard to manage extensi-bility for the following reasons:

�Complicated configuration and evolution: ORB sourcecode can become littered with hard-coded references to strat-egy types, which complicates configuration and evolution. Forexample, within a particular application domain, such as real-time avionics or medical imaging, many independent strate-gies must act harmoniously. Identifying these strategies indi-vidually by name, however, requires tedious replacement ofselected strategies in one domain with a potentially differentset of strategies in another domain.

� Semantic incompatibilities: It is not always possiblefor certain ORB strategy configurations to interact compati-bly. For instance, the FIFO strategy for scheduling requestsshown in Table 1 may not work with the thread-per-priorityconcurrency architecture. The problem stems from semanticincompatibilities between scheduling requests in their order ofarrival (i.e., FIFO queueing) vs. dispatching requests based ontheir relative priorities (i.e., preemptive priority-based threaddispatching). Moreover, some strategies are only useful whencertain preconditions are met. For instance, the perfect hash-ing demultiplexing strategy is generally feasible only for sys-tems that statically configure all servants off-line [22].

How can a highly-configurable ORB reduce the complexi-ties required to manage its myriad strategies, as well as enforcesemantic consistency when combining discrete strategies?

14

Solution ! the Abstract Factory pattern: An effectiveway to consolidate multiple ORB strategies into semanticallycompatible configurations is to apply theAbstract Factorypat-tern [15]. This pattern provides a single access point thatintegrates all strategies used to configure an ORB. Concretesubclasses then aggregate compatible application-specific ordomain-specific strategies, which can be replaceden masseinsemantically meaningful ways. In general, the Abstract Fac-tory pattern should be used when an application must consoli-date the configuration of many strategies, each having multiplealternatives that must vary together.

Using the Abstract Factory pattern in TAO: All of TAO’sORB strategies are consolidated into two abstract factories thatare implemented as Singletons [15]. One factory encapsulatesclient-specific strategies, the other factory encapsulates server-specific strategies, as shown in Figure 15. These abstract fac-

Dispatching

Strategy

Demuxing

Strategy

ORB

Server

Abstract

Factory

Concurrency

Strategy Thread-

per-

Connection

FIFO

Dispatching

Perfect

Hashing

Avionics AvionicsConcreteConcreteFactoryFactory

Rate-based Rate-based

DispatchingDispatching

Thread- Thread-

per-per-

PriorityPriority

ActiveActive

DemuxingDemuxing

Medical MedicalImagingImagingConcreteConcreteFactoryFactory

Figure 15: Factories used in TAO

tories encapsulate request demultiplexing, scheduling, and dis-patch strategies in the server, as well as concurrency strategiesin both client and server. By using the Abstract Factory pat-tern, TAO can configure different ORB personalities conve-niently and consistently.

3.3.8 Dynamically Configure ORBs with the ComponentConfigurator Pattern

Context: The cost of many computing resources, such asmemory and CPUs, continues to drop. However, ORBs muststill avoid excessive consumption of finite system resources.This parsimony is particularly essential for embedded andreal-time systems that require small memory footprints andpredictable CPU utilization [20]. Many applications can alsobenefit from the ability to extend ORBsdynamically, i.e., byallowing their strategies to be configured at run-time.

Problem: Although the Strategy and Abstract Factory pat-terns simplify the customization of ORBs for specific appli-

cation requirements and system characteristics, these patternscan still cause the following problems for extensible ORBs:

� High resource utilization: Widespread use of the Strat-egy pattern can substantially enlarge the number of strategiesconfigured into an ORB, which can increase the system re-sources required to run an ORB.

� Unavoidable system downtime: If strategies are config-ured statically at compile-time or static link-time using ab-stract factories, it is hard to enhance existing strategies or addnew strategies without (1) changing the existing source codefor the consumer of thestrategyor theabstract factory, (2)recompiling and relinking an ORB, and (3) restarting runningORBs and their application servants.

Although it does not use the Strategy pattern explicitly, Sun-Soft IIOP does permit applications to vary certain ORB strate-gies at run-time. However, these different strategies mustbe configured statically into SunSoft IIOP at compile-time.Moreover, as the number of alternatives increases, so does theamount of code required to implement them. For instance,Figure 16 illustrates SunSoft IIOP’s approach to varying theconcurrencystrategy.

ORB COREORB CORE

OBJECTOBJECT ADAPTERADAPTER

DEMUXING

CODE

CONCURRENCY

CODE if (do_thread) // take lock...

...

if (do_thread) // releaselock...

CONNECTION

MANAGEMENT

CODE

if (do_thread)

// thread...

else

// single-threaded

Figure 16: SunSoft IIOP Hard-coded Strategy Usage

Each area of code that might be affected by the choiceof concurrency strategy is trusted to act independently ofother areas. This proliferation of decision points adverselyincreases the complexity of the code, complicating futureenhancement and maintenance. Moreover, the selection ofthe data type specifying the strategy complicates integrationof new concurrency architectures because the type (bool )would have to change, as well as the programmatic structure,if (do thread) then ... else ... , that decodesthe strategy specifier into actions.

In general, static configuration is only feasible for a small,fixed number of strategies. However, configuring complex

15

ORB middleware (1) statically complicates evolution, (2) in-creases system resource utilization, and (3) leads to unavoid-able system downtime to modify existing components.

How then does an ORB implementation reduce the “overly-large, overly-static” side-effects stemming from pervasive useof the Strategy and Abstract Factory patterns?

Solution ! the Component Configurator pattern: Aneffective way to enhance the dynamism of an ORB isto apply the Component Configuratorpattern [8]. Thispattern uses explicit dynamic linking [28] mechanisms toobtain, utilize, and/or remove the run-time address bind-ings of custom strategy and abstract factory objects intoan ORB at installation-time and/or run-time. Widelyavailable explicit dynamic linking mechanisms include thedlopen/dlsym/dlclose functions in SVR4 UNIX [42]and theLoadLibrary/GetProcAddress functions inthe WIN32 subsystem of Windows NT [43]. The ACE wrap-per facades used by TAO portably encapsulate these OS APIs.

By using the Component Configurator pattern, thebehav-iors of ORB strategies are decoupled fromwhenthe strategyimplementations are configured into an ORB. For instance,ORB strategies can be linked into an ORB from dynamicallylinked libraries (DLL)s at compile-time, installation-time, oreven during run-time. Moreover, the Component Configura-tor pattern can reduce the memory footprint of an ORB byallowing application developers and/or system administratorsto dynamically link only those strategies that are necessary fora specific ORB personality.

In general, the Component Configurator pattern should beused when (1) an application wants to configure its con-stituent components dynamically and (2) conventional tech-niques, such as command-line options, are insufficient due tothe number of possibilities or the inability to anticipate therange of values.

Using the Component Configurator pattern in TAO:TAO uses the Component Configurator pattern in conjunctionwith the Strategy and Abstract Factory patterns to dynamicallyinstall the strategies it requires without (1) recompiling or stat-ically relinking existing code or (2) terminating and restartingan existing ORB and its application servants. This design al-lows the behavior of TAO to be tailored for specific platformsand application requirements without requiring access to, ormodification of, ORB source code.

In addition, the Component Configurator pattern allows ap-plications to customize the personality of TAO at run-time. Forinstance, during TAO’s ORB initialization phase, it uses thedynamic linking mechanisms provided by the OS (and encap-sulated by the ACE wrapper facades) to link in the appropriateconcrete factory for a particular use-case. Figure 17 shows twofactories tuned for different application domains supported byTAO: avionics and medical imaging.

dynamic ORB Service_Object * avionics_orb:make_orb() "-ORBport 2001"

Priority-basedPriority-basedDispatchingDispatching

TAOTAOPROCESSPROCESS

DLLDLLSS

Thread-per Thread-perRateRate

ConcurrencyConcurrency

AvionicsAvionicsConcreteConcreteFactoryFactory

PerfectPerfectHashingHashing

Service ServiceRepositoryRepository

ActiveActiveDemuxingDemuxing

MedicalMedicalImagingImagingConcreteConcreteFactoryFactory

FIFOFIFODispatchingDispatching

Thread-perThread-perConnectionConnection

ConcurrencyConcurrency

svc.confFILE

Figure 17: Using the Component Configurator Pattern in TAO

In the configuration shown in Figure 17, the ComponentConfigurator has consulted thecomp.conf script and in-stalled the avionics concrete factory in the process. Appli-cations using this ORB personality will be configured with aparticular set of ORB concurrency, demultiplexing, and dis-patching strategies. The medical imaging concrete factory re-sides in a DLL outside of the existing ORB process. To config-ure a different ORB personality, this factory could be installeddynamically during TAO’s ORB server initialization phase.

3.4 Summary of Design Challenges and Pat-terns That Resolve Them

Table 2 summarizes the mapping between ORB design chal-lenges and the patterns in the pattern language that we ap-plied to resolve these challenges in TAO. This table focuses

Forces Resolving Pattern

Abstracting low-level system calls Wrapper FacadeORB event demultiplexing ReactorORB connection management Acceptor-ConnectorEfficient concurrency models Leader/FollowersPluggable strategies StrategyGroup similar initializations Abstract FactoryDynamic run-time configuration Component Configurator

Table 2: Summary of Forces and Their Resolving Patterns

on the forces resolved by individual patterns. However, TAOalso benefits from the collaborations amongmultiplepatternsin the pattern language. For example, the Acceptor and Con-nector patterns utilize the Reactor pattern to notify them whenconnection events occur at the OS level.

Moreover, patterns often must collaborate to alleviate draw-backs that arise from applying them in isolation. For instance,

16

the reason the Abstract Factory pattern is used in TAO is toavoid the complexity caused by its extensive use of the Strat-egy pattern. Although the Strategy pattern simplifies the effortrequired to customize an ORB for specific application require-ments and network/endsystem characteristics, it is tedious anderror-prone to manage a large number of strategy interactionsmanually.

3.5 Evaluating the Contribution of Patterns toORB Middleware

Section 3.3 described the pattern language used in TAO andqualitatively evaluated how these patterns helped to alleviatelimitations with the design of SunSoft IIOP. The discussionbelow goes one step further and quantitatively evaluates thebenefits of applying patterns to ORB middleware.

3.5.1 Where’s the Proof?

Implementing TAO using a pattern language yielded signif-icant quantifiable improvements in software reusability andmaintainability. The results are summarized in Table 3. Thistable compares the following metrics for TAO and SunSoftIIOP:

1. The number of methods required to implement key ORBtasks (such as connection management, request transfer,socket and request demultiplexing, marshaling, and dis-patching).

2. The total non-comment lines of code (LOC) for thesemethods.

3. The average McCabe Cyclometric Complexity metricv(G) [44] of the methods. Thev(G) metric uses graphtheory to correlate code complexity with the number ofpossible basic paths that can be taken through a codemodule. In C++, a module is defined as a method.

The use of patterns in TAO significantly reduced the amountof ad hoccode and the complexity of certain operations. Forinstance, the total lines of code in the client-sideConnectionManagementoperations were reduced by a factor of 5. More-over, the complexity for this component was substantially re-duced by a factor of 16. These reductions in LOC and com-plexity stem from the following factors:

� These ORB tasks were the focus of our initial work whendeveloping TAO.

� Many of the details of connection management andsocket demultiplexing were subsumed by patterns andcomponents in the ACE framework, in particular, the Ac-ceptor, Connector, and Reactor.

Other areas did not yield as much improvement. In par-ticular, GIOP Invocationtasks actually increased in size andmaintained a consistentv(G). There were two reasons for thisincrease:

1. The primary pattern applied in these cases was the Wrap-per Facade, which replaced the low-level system callswith ACE wrappers but did not factor out common strate-gies; and

2. SunSoft IIOP did not trap all the error conditions, whichTAO addressed much more completely. Therefore, theadditional code in TAO is necessary to provide a morerobust ORB.

The most compelling evidence that the systematic applica-tion of patterns can positively contribute to the maintainabilityof complex software is shown in Figure 18. This figure illus-

1 − 5 6 − 10 > 10MVG Range

0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0%

Met

hods

in R

ange

SunSoft IIOPTAO

Figure 18: Distribution ofv(G) Over ORB Methods

trates the distribution ofv(G) over the percentage of affectedmethods in TAO. As shown in the figure, most of TAO’s codeis structured in a straightforward manner, with almost 70% ofthe methods’v(G) falling into the range of 1-5.

In contrast, while SunSoft IIOP has a substantial percent-age (55%) of its methods in that range, many of the remainingmethods (29%) havev(G) greater than 10. The reason for thedifference is that SunSoft IIOP uses a monolithic coding stylewith long methods. For example, the average length of meth-ods with v(G) over 10 is over 80 LOC. This yields overly-complex code that is hard to debug and understand.

In TAO, most of the monolithic SunSoft IIOP methods weredecomposed into smaller methods when integrating the pat-terns. The majority (86%) of TAO’s methods havev(G) under10. Of that number, nearly 70% have av(G) between 1 and 5.

17

TAO SunSoft IIOPORB Task # Methods Total LOC Avg.v(G) # Methods Total LOC Avg.v(G)

Connection Management (Server) 2 43 7 3 190 14Connection Management (client) 3 11 1 1 64 16GIOP Message Send (client/Server) 1 46 12 1 43 12GIOP Message Read (client/Server) 1 67 19 1 56 18GIOP Invocation (client) 2 205 26 2 188 27GIOP Message Processing (client/Server) 3 41 2 1 151 24Object Adapter Message Dispatch (Server) 2 79 6 1 61 10

Table 3: Code Statistics: TAO vs. SunSoft IIOP

The relatively few (14%) methods in TAO withv(G) greaterthan 10 are largely unchanged from the original SunSoft IIOPTypeCode interpreter. Subsequent releases of TAO have com-pletely removed the TypeCode interpreter and replaced it withstubs and skeletons generated automatically by TAO’s IDLcompiler. Thus, there is no need for TAO ORB developersto maintain this code anymore.

In general, the use of monolithic methods in SunSoft IIOPnot only increased its maintenance effort, it also degrades itsperformance due to reduced processor cache hits [20]. There-fore, we plan to experiment with the application of other pat-terns, such asCommandandTemplate Method[15], to sim-plify and optimize these monolithic methods into smaller,more cohesive methods.

3.5.2 What are the Benefits?

In general, the applying a pattern language to TAO yielded thefollowing benefits:

Increased extensibility: Patterns such as Abstract Factory,Strategy, and Component Configurator simplify the configura-tion of TAO for a particular application domain by allowingextensibility to be “designed into” the ORB. In contrast, DOCmiddleware lacking these patterns is significantly harder to ex-tend.

Enhanced design clarity: By applying a pattern languageto TAO, not only did we develop a more extensible ORB, wealso devised a richer vocabulary for expressing ORB middle-ware designs. In particular, a pattern language captures andarticulates the design rationale for complex object-structuresin an ORB. Moreover, it helps to demystify and motivate thestructure of an ORB by describing its architecture in terms ofdesign forces that recur in many types of software systems.The expressive power of a pattern language enabled us to con-cisely convey the design of complex software systems, such asTAO. As we continue to learn about ORBs and the patterns ofwhich they are composed, we expect our pattern vocabularyto grow and evolve into an even more comprehensive patternlanguage.

Increased portability and reuse: TAO is built atop theACE framework, which provides implementations of manykey communication software patterns[28]. Using ACE sim-plified the porting of TAO to numerous OS platforms sincemost of the porting effort was absorbed by the ACE frame-work maintainers. In addition, since the ACE framework isrich with configurable high-performance, real-time network-oriented components, we were able to achieve considerablecode reuse by leveraging the framework. This is indicated bythe consistent decrease in lines of code (LOC) in Table 3.

3.5.3 What are the Liabilities?

The use of a pattern language can also incur some liabilities.We summarize these liabilities below and discuss how we min-imize them in TAO.

Abstraction penalty: Many patterns use indirection to in-crease component decoupling. For instance, the Reactor pat-tern uses virtual methods to separate the application-specificEvent Handler logic from the general-purpose event de-multiplexing and dispatching logic. The extra indirection in-troduced by using these pattern implementations can poten-tially decrease performance. To alleviate these liabilities, wecarefully applied C++ programming language features (suchas inline functions and templates) and other optimizations(such as eliminating demarshaling overhead [20] and demul-tiplexing overhead [36]) to minimize performance overhead.As a result, TAO is substantially faster than the original hard-coded SunSoft IIOP [20].

Additional external dependencies: Whereas SunSoft IIOPonly depends on system-level interfaces and libraries, TAO de-pends on wrapper facades in the ACE framework. Since ACEencapsulates a wide range of low-level OS mechanisms, theeffort required to port it to a new platform could potentiallybe higher than porting SunSoft IIOP, which only uses a sub-set of the OS’s APIs. However, since ACE has been ported tomany platforms already, the effort to port to new platforms isrelatively low. Most sources of platform variation have beenisolated to a few modules in ACE.

18

4 Concluding Remarks

This paper presented a case study illustrating how we applieda pattern language to enhance the extensibility of TAO, whichis a dynamically configurable ORB that is targeted for dis-tributed applications with high-performance and real-time re-quirements. We found qualitative and quantitative evidencethat the use of this pattern language helped to clarify the struc-ture of, and collaboration between, components that performkey ORB tasks. These tasks include event demultiplexing andevent handler dispatching, connection establishment and ini-tialization of application services, concurrency control, anddynamic configuration. In addition, patterns improved TAO’sperformance and predictability by making it possible to trans-parently configure lightweight and optimized strategies forprocessing client requests.

A principal benefit of applying a pattern language to guideTAO’s design is that the systematic application of patternsin the language improved the decoupling and object-orientedstructure of the ORB significantly. The patterns we used wereapplied in roughly the same order that they appear in Sec-tion 3.3. Each evolution of TAO leveraged upon the results ofprior evolutions. This iterative process revealed new insightson which patterns in the language could be applied and howthey might be applied in subsequent stages.

The complete C++ source code, examples, and docu-mentation for ACE and TAO is freely available at URLwww.cs.wustl.edu/ �schmidt/TAO.html .

References[1] R. Johnson, “Frameworks = Patterns + Components,”Communications

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

[2] S. Vinoski, “CORBA: Integrating Diverse Applications Within Dis-tributed Heterogeneous Environments,”IEEE Communications Maga-zine, vol. 14, February 1997.

[3] J. A. Zinky, D. E. Bakken, and R. Schantz, “Architectural Support forQuality of Service for CORBA Objects,”Theory and Practice of ObjectSystems, vol. 3, no. 1, 1997.

[4] Object Management Group,The Common Object Request Broker: Ar-chitecture and Specification, 2.2 ed., Feb. 1998.

[5] D. Box, Essential COM. Addison-Wesley, Reading, MA, 1997.

[6] A. Wollrath, R. Riggs, and J. Waldo, “A Distributed Object Modelfor the Java System,”USENIX Computing Systems, vol. 9, Novem-ber/December 1996.

[7] D. C. Schmidt, “Experience Using Design Patterns to Develop Reuse-able Object-Oriented Communication Software,”Communications ofthe ACM (Special Issue on Object-Oriented Experiences), vol. 38, Oc-tober 1995.

[8] D. C. Schmidt, M. Stal, H. Rohnert, and F. Buschmann,Pattern-Oriented Software Architecture: Patterns for Concurrency and Dis-tributed Objects, Volume 2. New York, NY: Wiley & Sons, 2000.

[9] D. C. Schmidt, “Applying a Pattern Language to Develop Application-level Gateways,” inDesign Patterns in Communications(L. Rising, ed.),Cambridge University Press, 2000.

[10] D. C. Schmidt, D. L. Levine, and S. Mungee, “The Design and Perfor-mance of Real-Time Object Request Brokers,”Computer Communica-tions, vol. 21, pp. 294–324, Apr. 1998.

[11] T. H. Harrison, D. L. Levine, and D. C. Schmidt, “The Design andPerformance of a Real-time CORBA Event Service,” inProceedings ofOOPSLA ’97, (Atlanta, GA), ACM, October 1997.

[12] S. Mungee, N. Surendran, and D. C. Schmidt, “The Design and Perfor-mance of a CORBA Audio/Video Streaming Service,” inProceedings ofthe Hawaiian International Conference on System Sciences, Jan. 1999.

[13] C. O’Ryan, D. C. Schmidt, and D. Levine, “Applying a ScalableCORBA Events Service to Large-scale Distributed Interactive Simula-tions,” in Proceedings of the5th Workshop on Object-oriented Real-time Dependable Systems, (Montery, CA), IEEE, Nov. 1999.

[14] Object Management Group,The Common Object Request Broker: Ar-chitecture and Specification, 2.3 ed., June 1999.

[15] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,Design Patterns: El-ements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.

[16] C. O’Ryan, F. Kuhns, D. C. Schmidt, and J. Parsons, “Applying Patternsto Develop a Pluggable Protocols Framework for ORB Middleware,” inDesign Patterns in Communications(L. Rising, ed.), Cambridge Uni-versity Press, 2000.

[17] E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom, “Flick: AFlexible, Optimizing IDL Compiler,” inProceedings of ACM SIGPLAN’97 Conference on Programming Language Design and Implementation(PLDI), (Las Vegas, NV), ACM, June 1997.

[18] M. Henning, “Binding, Migration, and Scalability in CORBA,”Com-munications of the ACM special issue on CORBA, vol. 41, Oct. 1998.

[19] Object Management Group,Realtime CORBA Joint Revised Submis-sion, OMG Document orbos/99-02-12 ed., March 1999.

[20] A. Gokhale and D. C. Schmidt, “Optimizing a CORBA IIOP Proto-col Engine for Minimal Footprint Multimedia Systems,”Journal on Se-lected Areas in Communications special issue on Service Enabling Plat-forms for Networked Multimedia Systems, vol. 17, Sept. 1999.

[21] D. C. Schmidt, “GPERF: A Perfect Hash Function Generator,” inPro-ceedings of the2nd C++ Conference, (San Francisco, California),pp. 87–102, USENIX, April 1990.

[22] I. Pyarali, C. O’Ryan, D. C. Schmidt, N. Wang, V. Kachroo, andA. Gokhale, “Using Principle Patterns to Optimize Real-time ORBs,”Concurrency Magazine, vol. 8, no. 1, 2000.

[23] C. D. Gill, D. L. Levine, and D. C. Schmidt, “The Design and Perfor-mance of a Real-Time CORBA Scheduling Service,”The InternationalJournal of Time-Critical Computing Systems, special issue on Real-TimeMiddleware, to appear 2000.

[24] D. C. Schmidt, S. Mungee, S. Flores-Gaitan, and A. Gokhale, “SoftwareArchitectures for Reducing Priority Inversion and Non-determinism inReal-time Object Request Brokers,”Journal of Real-time Systems, spe-cial issue on Real-time Computing in the Age of the Web and the Inter-net, To appear 2000.

[25] C. O’Ryan, F. Kuhns, D. C. Schmidt, O. Othman, and J. Parsons, “TheDesign and Performance of a Pluggable Protocols Framework for Real-time Distributed Object Computing Middleware,” inProceedings of theMiddleware 2000 Conference, ACM/IFIP, Apr. 2000.

[26] F. Kuhns, D. C. Schmidt, C. O’Ryan, and D. Levine, “Supporting High-performance I/O in QoS-enabled ORB Middleware,”Cluster Comput-ing: the Journal on Networks, Software, and Applications, 2000.

[27] Z. D. Dittia, G. M. Parulkar, and J. R. Cox, Jr., “The APIC Approachto High Performance Network Interface Design: Protected DMA andOther Techniques,” inProceedings of INFOCOM ’97, (Kobe, Japan),pp. 179–187, IEEE, April 1997.

[28] D. C. Schmidt, “Applying Design Patterns and Frameworks to DevelopObject-Oriented Communication Software,” inHandbook of Program-ming Languages(P. Salus, ed.), MacMillan Computer Publishing, 1997.

[29] A. B. Arulanthu, C. O’Ryan, D. C. Schmidt, M. Kircher, and J. Par-sons, “The Design and Performance of a Scalable ORB Architecture forCORBA Asynchronous Messaging,” inProceedings of the Middleware2000 Conference, ACM/IFIP, Apr. 2000.

19

[30] C. O’Ryan, D. C. Schmidt, F. Kuhns, M. Spivak, J. Parsons, I. Pyarali,and D. Levine, “Evaluating Policies and Mechanisms for SupportingEmbedded, Real-Time Applications with CORBA 3.0,” inProceedingsof the6th IEEE Real-Time Technology and Applications Symposium,(Washington DC), IEEE, May 2000.

[31] B. Natarajan, A. Gokhale, D. C. Schmidt, and S. Yajnik, “DOORS: To-wards High-performance Fault-Tolerant CORBA,” inProceedings of the2nd International Symposium on Distributed Objects and Applications(DOA 2000), (Antwerp, Belgium), OMG, Sept. 2000.

[32] B. Natarajan, A. Gokhale, D. C. Schmidt, and S. Yajnik, “ApplyingPatterns to Improve the Performance of Fault-Tolerant CORBA,” inProceedings of the 7th International Conference on High PerformanceComputing (HiPC 2000), (Bangalore, India), ACM/IEEE, Dec. 2000.

[33] J. Hu, S. Mungee, and D. C. Schmidt, “Principles for Developing andMeasuring High-performance Web Servers over ATM,” inProceeedingsof INFOCOM ’98, March/April 1998.

[34] F. Kon, M. Roman, P. Liu, J. Mao, T. Yamane, L. Magalhaes, andR. Campbell, “Monitoring, Security, and Dynamic Configuration withthe dynamicTAO Reflective ORB,” inProceedings of the Middleware2000 Conference, ACM/IFIP, Apr. 2000.

[35] M. Roman, M. D. Mickunas, F. Kon, and R. Campbell, “LegORB andUbiquitous CORBA,” inReflective Middleware Workshop, ACM/IFIP,Apr. 2000.

[36] A. Gokhale and D. C. Schmidt, “Measuring and Optimizing CORBALatency and Scalability Over High-speed Networks,”Transactions onComputing, vol. 47, no. 4, 1998.

[37] J. Hu and D. C. Schmidt, “JAWS: A Framework for High PerformanceWeb Servers,” inDomain-Specific Application Frameworks: Frame-works Experience by Industry(M. Fayad and R. Johnson, eds.), Wiley& Sons, 1999.

[38] Object Management Group,OMG Real-time Request for Proposal,OMG Document ptc/97-06-20 ed., June 1997.

[39] IEEE, Threads Extension for Portable Operating Systems (Draft 10),February 1996.

[40] D. C. Schmidt, S. Mungee, S. Flores-Gaitan, and A. Gokhale, “Alleviat-ing Priority Inversion and Non-determinism in Real-time CORBA ORBCore Architectures,” inProceedings of the4th IEEE Real-Time Tech-nology and Applications Symposium, (Denver, CO), IEEE, June 1998.

[41] I. Pyarali, T. H. Harrison, and D. C. Schmidt, “Design and Perfor-mance of an Object-Oriented Framework for High-Performance Elec-tronic Medical Imaging,”USENIX Computing Systems, vol. 9, Novem-ber/December 1996.

[42] R. Gingell, M. Lee, X. Dang, and M. Weeks, “Shared Libraries inSunOS,” inProceedings of the Summer 1987 USENIX Technical Con-ference, (Phoenix, Arizona), 1987.

[43] D. A. Solomon,Inside Windows NT, 2nd Ed.Redmond, Washington:Microsoft Press, 2nd ed., 1998.

[44] T. J. McCabe, “A Complexity Measure,”IEEE Transactions on SoftwareEngineering, vol. SE-2, Dec. 1976.

20

Date post:	14-Jul-2020
Category:	Documents
Upload:	others
View:	24 times
Download:	0 times

Applying a Pattern Language to Develop Extensible ORB ...schmidt/PDF/ORB-patterns.pdfdevelop The ACE...

Documents