applying design patterns to flexibly configure network services in

Applying Design Patterns to Flexibly ConfigureNetwork Services in Distributed Systems

Douglas C. [email protected]

http://www.ece.uci.edu/�schmidt/Department of Electrical & Computer Science

University of California, Irvine 92607�

This paper appeared as a chapter in the bookDesign Pat-terns in Communications, (Linda Rising, ed.), Cambridge Uni-versity Press, 2000. An earlier version of this paper appearedin the International Conference on Configurable DistributedSystems, Annapolis, Maryland, May 6–8, 1996.

Abstract

This paper describes how design patterns help to enhance theflexibility and extensibility of communication software by per-mitting network services to evolve independently of the strate-gies used to passively initialize the services. The paper makesthree contributions to the study and development of config-urable distributed applications. First, it identifies five orthog-onal dimensions of passive service initialization: service ad-vertisement, endpoint listening, service handler creation, pas-sive connection establishment, and service handler activation.Second, the paper illustrates how design patterns have beenused to build a communication software framework that sup-ports flexible configuration of different strategies for each ofthese five dimensions. Third, the paper demonstrates how de-sign patterns and frameworks are being used successfully todevelop highly configurable production distributed systems.

1 Introduction

Despite dramatic increases in network and host performance,developing extensible communication software for distributedsystems remains hard.Design patterns[1] are a promisingtechnique for capturing and articulating proven techniques fordeveloping extensible distributed software. A design patterncaptures the static and dynamic structures and collaborationsof components in a software architecture. It also aids the de-velopment of extensible components and frameworks by ex-pressing the structure and collaboration of participants in asoftware architecture at a level higher than (1) source code

�This research is supported in part by a grant from Siemens MED.

or (2) object-oriented design models that focus on individualobjects and classes.

This paper examines design patterns that form the basis forflexibly configuring network services in applications built bythe author and his colleagues for a number of production dis-tributed systems. Due to stringent requirements for reliabilityand performance, these projects provided an excellent testbedfor capturing and articulating the key structure, participants,and consequences of design patterns for building extensibledistributed systems.

The primary focus of this paper is theAcceptor compo-nent in theAcceptor-Connectorpattern [2]. This design pat-tern decouples connection establishment and service initial-ization from service processing in a networked system. TheAcceptor component is a role in this pattern that enables thetasks performed by network services to evolve independentlyof the strategies used to initialize the servicespassively.

When instantiated and used in conjunction with other pat-terns, such as Reactor [2] and Strategy [1], the Acceptor-Connector pattern provides a reusable component in the ACEframework [3]. ACE provides a rich set of reusable object-oriented components that perform common communicationsoftwarekg tasks. These tasks include event demultiplexing,event handler dispatching, connection establishment, routing,dynamic configuration of application services, and concur-rency control.

This paper is organized as follows: Section 2 motivatesthe Acceptor-Connector pattern by illustrating how it hasbeen applied in production application-levelGateways ; Sec-tion 3 outlines theAcceptor component of the Acceptor-Connector pattern; Section 4 illustrates how to implementAcceptor ’s flexibly and efficiently by applying the Wrap-per Facade [2], Strategy, Bridge, Factory Method, and Ab-stract Factory design patterns [1]; Section 5 outlines howAcceptor s have been used to implement application-levelGateways ; Section 6 discusses related patterns; and Sec-tion 7 presents concluding remarks.

1

2 Background and Motivation

2.1 Separating Connection establishment andservice initialization

Many network services, such as remote login, file transfer, andWWW HTML document transfer, use connection-orientedprotocols, such as TCP, to deliver data reliably between twoor more communication endpoints. Establishing connectionsbetween endpoints involves the following two roles:

1. Thepassiverole, which initializes an endpoint of com-munication at a particular address and waits passively for theother endpoint(s) to connect with it.

2. Theactiverole, which actively initiates a connection toone or more endpoints that are playing the passive role.

The intent of the Acceptor-Connector pattern described inthis paper is to decouple passive initialization of a service fromthe tasks performed after the service is initialized. This pat-tern was discovered by generalizing from extensive experiencebuilding reusable communication frameworks for a range ofdistributed systems [3]. In all these systems, the tasks per-formed by a service are independent of the following:

� Which endpoint initiated the connection: Connec-tion establishment is inherently asymmetrical since the pas-sive endpointwaits whereas the active endpointinitiates theconnection. After the connection is established, however, datamay be transferred between endpoints in a manner that obeysa service’s communication protocol, which can be structuredas peer-to-peer, request-response, oneway streaming, etc.

� The network programming interfaces and underlyingprotocols used to establish the connection: Different net-work programming interfaces, such as sockets or TLI, pro-vide different routines to establish connections using variousunderlying transport protocols. After a connection is estab-lished, however, data may be transferred between endpointsusing standardread /write system calls that communicatebetween separate endpoints in a distributed application.

� The strategies used to initialize the service: The pro-cessing tasks performed by a service are typically independentof the initialization strategies used to (1) advertise the service,(2) listen for connection requests from peers, (3) create a ser-vice handler to process those requests, (4) establish the con-nection with the peers, and (5) execute the service handlerin one or more threads or processes. Explicitly decouplingthese initialization strategies from the service behavior itselfenhances the extensibility, reusability, and portability of theservice.

2.2 Motivating Example

Figure 1 illustrates how the Acceptor-Connector patternhas been used to implement multi-service, application-levelGateways , which is described further in [4]. AGateway

PEERS

1: send_msg()

PEERS

4: send_msg()

GATEWAY

2: recv_msg()3: route_msg()

Figure 1: A Connection-oriented, Multi-service Application-level Gateway

is a mediator [1] that routes data between services running onPeers located throughout a wide area and local area network.From theGateway ’s perspective,Peer services differ solelyby their message framing formats and payload types. Severaltypes of data, such as status information, bulk data, and com-mands, are exchanged by services running on theGatewayand thePeers . Peers are located throughout local area net-works (LANs) and wide-area networks (WANs) and are usedto monitor and control network resources, such as satellites,call centers, or remote branch offices.

The Gateway uses a connection-oriented interprocesscommunication (IPC) mechanism, such as TCP, to transmitdata between its connectedPeers . Connection-oriented pro-tocols simplify application error handling and can enhanceperformance over long-delay WANs. Each communicationservice in thePeers sends and receives status information,bulk data, and commands to and from theGateway usingseparate TCP connections. Each connection is bound to aunique address,e.g.,an IP address and port number. For in-stance, bulk data sent from a ground stationPeer through theGateway is connected to a different port than status informa-tion sent by a tracking station peer through theGateway to aground stationPeer . Separating connections in this mannerallows more flexible routing strategies and more robust errorhandling if connections fail or become flow controlled.

One way to design thePeers andGateway is to tightlycouple the connection roles with the network services. For in-stance, theGateway could be hard-coded to play the activeconnection role and initiate connections for all its services. Toaccomplish this, it could iterate through a list ofPeers andsynchronously connect with each of them. Likewise,Peerscould be hard-coded to play the passive role and accept theconnections and initialize their services. Moreover, the active

2

and passive connection code for theGateway andPeers , re-spectively, could be implemented with conventional networkprogramming interfaces like sockets or TLI. In this case, aPeer could callsocket, bind, listen, andacceptto initialize a passive-mode listener socket and theGatewaycould callsocket andconnect to actively initiate a data-mode connection socket. After the connections were estab-lished, theGateway could route data for each type of serviceit provided.

However, the tightly coupled design outlined above has thefollowing drawbacks:

� Limited extensibility and reuse of the Gateway andPeer software: For example, the mechanisms used to estab-lish connections and initialize services are independent of thetype of routing service,e.g.,status information, bulk data, orcommands, performed by theGateway . In general, these ser-vices tend to change more frequently than the connection andinitialization mechanisms.

� Inflexible connection roles: There are circumstanceswhere theGateway must play thepassiveconnection roleand thePeers play the active role. Therefore, tightly cou-pling the software that implements connection establishmentwith the software that implements the service makes it hardto (1) reuse existing services, (2) extend theGateway byadding new routing services and enhancing existing services,and (3) reconfigure the connection roles played byPeers andtheGateway .

� Non-portable and error-prone interfaces: Using low-level network programming, such as sockets or TLI, is non-portable and error-prone. These low-level interfaces do notprovide adequate type-checking since they utilize low-levelI/O handles. It is easy to accidentally misuse these interfacesin ways that cannot be detected until run-time.

Therefore, a more flexible and efficient way to design thePeers andGateway is to use theAcceptorpattern.

3 The Acceptor-Connector Pattern

This section presents a brief overview of the Acceptor-Connector pattern. A comprehensive discussion is availablein [2].

Intent: The intent of the Acceptor-Connector pattern is todecouple connection establishment and service initializationfrom service processing in a networked system.

Forces: The Acceptor-Connector pattern resolves the fol-lowing forces for distributed applications that use connection-oriented communication protocols:

1. The need to reuse connection establishment code foreach new service.Key characteristics of services, such as thecommunication protocol or the data format, should be able toevolve independently and transparently from the mechanismsused to establish the connections. Since service characteristicschange more frequently than connection establishment mecha-nisms, separating these concerns helps to reduce software cou-pling and increase code reuse.

2. The need to make the connection establishment codeportable across platforms that contain different networkprogramming interfaces. Parameterizing the Acceptor-Connector’s mechanisms for accepting connections and per-forming services helps to improve portability by allowing thewholesale replacement of these mechanisms. This makes theconnection establishment code portable across platforms thatcontain different network programming interfaces, such assockets but not TLI, or vice versa.

3. The need to enable flexible service concurrency poli-cies. After a connection is established, peer applications usethe connection to exchange data to perform some type of ser-vice, such as remote login or HTML document transfer. Aservice can run in a single-thread, in multiple threads, or mul-tiple processes, regardless regardless of how the connectionwas established or how the services were initialized.

4. The need to ensure that a passive-mode I/O handle isnot accidentally used to read or write data.By strongly decou-pling the connection establishment logic from the service pro-cessing logic, passive-mode socket endpoints cannot be usedincorrectly,e.g.,by trying to read or write data on a passive-mode listener socket used to accept connections. This elimi-nates an important class of network programming errors.

5. The need to actively establish connections with largenumber of peers efficiently.When an application must estab-lish connections with a large number of peers efficiently overlong-delay WANs it may be necessary to use asynchrony andinitiate and complete multiple connections in non-blockingmode.

Structure and participants: The structure of the key partic-ipants in the Acceptor-Connector pattern is illustrated in Fig-ure 2. TheAcceptor andConnector components are fac-tories that assemble the resources necessary to connect and ac-tivateSvc Handler s. Svc Handler s are components thatexchange messages with connectedPeers .

The participants in the Connection Layer of the Acceptor-Connector pattern can leverage off the Reactor pattern. For in-stance, theConnector ’s asynchronous initialization strategyestablishes a connection after areactor notifies it that a pre-viously initiated connection request to aPeer has completed.Using the Reactor pattern enables multipleSvc Handlers

3

1n

EventHandler

Connectorconnect_svc_handler()activate_svc_handler()handle_event()connect(sh, addr)

SVC_HANDLERPEER_CONNECTOR

ConcreteConnector

Concrete_Svc_HandlerSOCK_Connector1SOCK_Stream

open()

n

RE

AC

TIV

ELA

YE

RC

ON

NE

CT

ION

LAY

ER

AP

PLI

CA

TIO

NLA

YE

R

handle_event()

A

connect_svc_handler (sh, addr);1:

PEER_STREAM

open() A

INITIALIZES

activate_svc_handler (sh);2:

n

Reactor

Svc Handler

ConcreteSvc Handler

Acceptorcreate_svc_handler()accept_svc_handler()activate_svc_handler()handle_event()

SVC_HANDLERPEER_ACCEPTOR

ConcreteAcceptor

Concrete_Svc_HandlerSOCK_Acceptor1

A

sh = create_svc_handler();accept_svc_handler(sh);activate_svc_handler(sh);

INITIALIZES

Figure 2: Structure of Participants in the Acceptor-ConnectorPattern

to be initialized asynchronously within a single thread of con-trol.

To increase flexibility,Acceptor andConnector com-ponents can be parameterized by a particular type of IPCmechanism andSVCHANDLER. The IPC mechanism suppliesthe underlying transport mechanism, such as C++ wrapper fa-cades [2] for sockets or TLI, used to establish a connection.The SVCHANDLERspecifies an abstract interface for defin-ing a service that communicates with a connectedPeer . ASvc Handler can be parameterized by aPEERSTREAMendpoint. TheAcceptor andConnector components as-sociate this endpoint to itsPeer when a connection is estab-lished.

By inheriting from Event Handler , a Svc Handlercan register with aReactor and use the Reactor pattern tohandle its I/O events within the same thread of control as theAcceptor or Connector . Conversely, aSvc Handlercan use the Active Object pattern and handle its I/O events ina separate thread. The tradeoffs between these two patterns isdescribed in [4].

Figure 2 illustrates how parameterized types can be usedto decouple the Acceptor-Connector pattern’s connection es-tablishment strategy from the type of service and the type ofconnection mechanism. Application developers supply tem-plate arguments for these types to produce Application LayerAcceptor orConnectors . This design enables the whole-sale replacement of theSVCHANDLERand IPC mechanism,without affecting the Acceptor-Connectorpattern’s service ini-tialization strategy.

Note that a similar degree of decoupling could be achievedvia inheritance and dynamic binding by using the AbstractFactory or Factory Method patterns described in [1]. Pa-

rameterized types were used to implement this pattern sincethey improve run-time efficiency. In general, templates tradecompile- and link-time overhead and space overhead for im-proved run-time performance.

Dynamics: Figure 3 illustrates the dynamics among partic-ipants for theAcceptor component of the pattern. These

Server

REGISTER HANDLER

START EVENT LOOP

CONNECTION EVENT

REGISTER HANDLERFOR CLIENT I/O

FOREACH EVENT DO

EXTRACT HANDLE

INITIALIZE PASSIVE

ENDPOINT

acc :Acceptor

handle_event()

handle_close()

reactor :Reactor

select()

sh :Svc_Handler

handle_event()

register_handler(sh)

get_handle()EXTRACT HANDLE

DATA EVENT

CLIENT SHUTDOWN

svc()PROCESS MSG

open()

CREATE, ACCEPT,AND ACTIVATE OBJECT

SERVER SHUTDOWN handle_close()

SOCKAcceptor

handle_events()

get_handle()

register_handler(acc)

sh = make_svc_handler()accept_svc_handler (sh)activate_svc_handler (sh)

open()

EN

DP

OIN

TIN

ITIA

LIZ

AT

ION

PH

AS

E

SE

RV

ICE

INIT

IALI

ZA

TIO

NP

HA

SE

SE

RV

ICE

PR

OC

ES

SIN

GP

HA

SE

Figure 3: Dynamics for theAcceptor Component

dynamics are divided into the following three phases:

1. Endpoint initialization phase, which creates a passive-mode endpoint encapsulated byPEERACCEPTORthat isbound to a network address, such as an IP address and portnumber. The passive-mode endpoint listens for connectionrequests fromPeers . This endpoint is registered with theReactor , which drives the event loop that waits on the end-point for connection requests to arrive fromPeers .

2. Service activation phase.Since anAcceptor in-herits from anEvent Handler the Reactor can dis-patch theAcceptor ’s handle event method when con-nection request events arrive. This method performs theAcceptor ’s Svc Handler initialization strategy, which(1) assembles the resources necessary to create a newConcrete Svc Handler object, (2) accepts the connec-tion into this object, and (3) activates theSvc Handler bycalling itsopen hook method.

3. Service processing phase.After theSvc Handler isactivated, it processes incoming event messages arriving onthePEERSTREAM. A Svc Handler can process incomingevent messages in accordance with patterns, such as the Reac-tor or the Active Object [2].

The dynamics among participants inConnector compo-nent of the pattern can be divided into the following threephases:

4

1. Connection initiation phase, which actively connectsone or moreSvc Handlers with their peers. Connec-tions can be initiated synchronously or asynchronously. TheConnector ’s connect method implements the strategy forestablishing connections actively.

2. Service initialization phase, which activates aSvc Handler by calling its open method when its con-nection completes successfully. Theopen method of theSvc Handler then performs service-specific initialization.

3. Service processing phase, which performs theapplication-specific service processing using the data ex-changed between theSvc Handler and its connectedPeer .

4 Applying Design Patterns to DevelopExtensible Acceptors

This section describes how to implement a highly con-figurable instance of theAcceptor component from theAcceptor-Connector pattern by applying other design pat-terns, in particular Wrapper Facade [2], Strategy, Bridge, Fac-tory Method, and Abstract Factory [1]. These patterns en-able anAcceptor to flexibly configure alternative strategiesfor service advertisement, endpoint listening, service handlercreation, service connection acceptance, andservice activa-tion. In this section, we focus on theSvc Handler and theAcceptor components shown in Figure 2. TheConnectorcomponent can be implemented in similarly.

4.1 The SvcHandler Class

This abstract C++ class provides a generic interface for pro-cessing services. Applications customize this class to per-form a particular type of service. The C++ interface for theSvc Handler is shown below:

template <class PEER_STREAM>// Type of IPC mechanism.

class Svc_Handler {public:

// Pure virtual method (defined by subclass).virtual int open (void) = 0;

protected:// Instance of IPC mechanism.PEER_STREAM stream_;

};

Each Svc Handler contains a communication end-point, called peer stream , of parameterized typePEERSTREAM. This endpoint is used to exchange databetween theSvc Handler and its connected peer. After aconnection is successfully accepted, anAcceptor activates

a Svc Handler by calling itsopen method. This pure vir-tual method must be overridden by a concreteSvc Handlersubclass and performs service-specific initializations.

4.2 The Acceptor Class

This abstract C++ class implements the generic strategyfor passively initializing network services, which are imple-mented as concreteSvc Handler s. AnAcceptor instancecoordinates the following five orthogonal dimensions of pas-sive service initialization:

1. Service advertisement, which initializes thepeer acceptor endpoint and announces the availabilityof the service to interested peers.

2. Endpoint listening, which waits passively for peers toactively initiate connections on thepeer acceptor end-point.

3. Service handler creation, which creates and initializesa concreteSvc Handler that can communicate with the newpeer.

4. Passive connection establishment, which uses thepeer acceptor endpoint to accept a connection initiatedactively by a peer.

5. Service handler concurrency activation, which deter-mines the type of concurrency mechanism used to process dataexchanged with peers.

The Acceptor ’s open method is responsible for handlingthe first two dimensions. TheAcceptor ’s accept methodis responsible for handling the remaining three dimensions.

The following interface illustrates the methods and datamembers in theAcceptor class:

template <class SVC_HANDLER,// Type of service handler.class PEER_ACCEPTOR>// Type of passive connection mechanism.

class Acceptor {public:

// Defines the initialization strategies.typedef Strategy_Factory<SVC_HANDLER,

PEER_ACCEPTOR>STRATEGY_FACTORY;

// Initialize listener endpoint at <addr>// according to specified <init_strategies>.virtual void open

(const PEER_ACCEPTOR::PEER_ADDR &addr,STRATEGY_FACTORY *init_strategies);

// Embodies the strategies for creating,// connecting, and activating <SVC_HANDLER>’s.virtual void accept (void);

protected:// Defines strategy to advertise endpoint.virtual void advertise_svc

(const PEER_ACCEPTOR::PEER_ADDR &);

5

// Defines the strategy to listen for active// connections from peers.virtual void make_listener (PEER_ACCEPTOR *);

// Defines <SVC_HANDLER> creation strategy.virtual SVC_HANDLER *make_svc_handler (void);

// Defines <SVC_HANDLER> connection strategy.virtual void accept_svc_handler (SVC_HANDLER *);

// Defines <SVC_HANDLER> concurrency strategy.virtual int activate_svc_handler (SVC_HANDLER *);

private:// Pointers to objects that implement the// <Acceptor>’s initialization Strategies.Advertise_Strategy<PEER_ACCEPTOR::PEER_ADDR>

*listen_strategy_;Listener_Strategy<PEER_ACCEPTOR>

*listen_strategy_;Creation_Strategy<SVC_HANDLER>

*create_strategy_;Accept_Strategy<SVC_HANDLER, PEER_ACCEPTOR>

*accept_strategy_;Concurrency_Strategy<SVC_HANDLER>

*concurrency_strategy_;};

The Acceptor is a C++ template that is parameterized bya particular type ofPEERACCEPTORand SVCHANDLER.The PEERACCEPTORis the type of transport mechanismused by theAcceptor to passively establish the connec-tion. The SVCHANDLERis the type of service that pro-cesses the data exchanged with its connected peer. Parameter-ized types are used to efficiently decouple the service initial-ization strategies from the type ofSvc Handler , networkprogramming interface, and transport layer connection proto-col. This design improves the extensibility of theAcceptorand Svc Handler components by allowing the wholesalereplacement of various strategies.

Figure 4 visually depicts the relationship between theclasses that comprise theAcceptor implementation. Thefive strategies supported by theAcceptor to passively ini-tializeSvc Handlers are illustrated and described below.

1. Service advertisement strategies: The Acceptoruses its service advertisement strategy to initialize thePEERACCEPTORendpoint and to announce the availabilityof the service to interested peers. Figure 5 illustrates the com-mon strategies configured into theAcceptor to advertiseservices:

� Well-known addresses, such as Internet port numbers andhost names;

� Endpoint portmappers, such as those used by Sun RPCand DCE;

� X.500 directory service, which is a ISO OSI standard formapping names to values in a distributed system.

Acceptor


open()accept()make_listener()make_svc_handler()activate_svc_handler()accept_svc_handler()advertise_svc()

sh = make_svc_handler();accept_svc_handler (sh);activate_svc_handler (sh);

AcceptStrategy

accept_svc_handler()


2:

A

ConcurrencyStrategy

SVC_HANDLER

activate_svc_handler()A

CreationStrategy

SVC_HANDLER

make_svc_handler()A

advertise_svc()make_listener()1:

ListenerStrategy

make_listener()A

PEER_ACCEPTOR

AdvertiseStrategy

advertise_svc()A

ADDR

Figure 4: Class Structure of theAcceptor Class Implemen-tation

AdvertiseStrategy

advertise_svc()

PortmapperStrategy

Well-knownAddressStrategy

A

X.500Strategy

ADDR

ADDR

ADDR

ADDR

Figure 5: Alternative Service Advertising Strategies

2. Endpoint listener strategies: The Acceptor uses itsendpoint listening strategy to wait passively for peers to ac-tively initiate a connection to thePEERACCEPTORendpoint.Figure 6 illustrates the following common strategies config-

ListenerStrategy

make_listener()

ThreadedListenerStrategy

ReactiveListenerStrategy

A

PEER ACCEPTOR

PEER ACCEPTOR

PEER ACCEPTOR

Figure 6: Alternative Endpoint Listener Strategies

ured into theAcceptor to wait for connections:

6

� Reactive listeners, which use an event-demultiplexer,such as aReactor [2], to listen passively on a set ofendpoints in a single thread of control;

� Threaded listeners, which use a separate thread of controlfor each listener.

3. Service handler creation strategies: The Acceptoruses its creation strategy to initialize aSvc Handler thatwill communicate with the new peer. Figure 7 illustrates the

CreationStrategy

SVC_HANDLER

make_svc_handler()

SingletonStrategy

SVC_HANDLERDemandStrategy

SVC_HANDLER DynamicStrategy

SVC_HANDLER

A

Figure 7: AlternativeSvc Handler Creation Strategies

following common strategies configured into theAcceptorto createSvc Handlers :

� Demand creation, which allocates a newSvc Handlerfor every new connection;

� Singleton creation, which only creates a singleSvc Handler that is recycled for every connec-tion;

� Dynamic creation, which does not store theSvc Handler object in the application process untilit is required, at which point the object is dynamicallylinked into the process from a shared library.

4. Passive connection establishment strategies:TheAcceptor uses its passive connection establishment strategyto accept a new connection initiated actively by a peer. Fig-ure 8 illustrates the following common strategies configuredinto theAcceptor to accept connections from peers:

� Connection-oriented (CONS) establishment, which usesconnection-oriented protocols, such as TCP, SPX, orTP4;

� Connectionless (CLNS) establishment, which uses theAdapter pattern [1] to utilize a uniform interface for con-nectionless protocols.

CLNSStrategy

AcceptStrategy



CONSStrategy

SVC_HANDLERPEER_ACCEPTOR SVC_HANDLER

PEER_ACCEPTOR

A

Figure 8: AlternativeSvc Handler Connection AcceptanceStrategies

5. Service handler concurrency activation strategies: TheAcceptor uses its activation strategy to determine the typeof concurrency mechanism aSvc Handler will use to pro-cess data exchanged with its peer. Figure 9 illustrates the fol-

ConcurrencyStrategy

SVC_HANDLER

activate_svc_handler()

ThreadStrategy

SVC_HANDLER

ReactiveStrategy

SVC_HANDLER ProcessStrategy

SVC_HANDLER

ThreadPool

Strategy

SVC_HANDLER

A

Figure 9: AlternativeSvc Handler Concurrency ActivationStrategies

lowing common strategies configured into theAcceptor toactivateSvc Handlers :

� Reactive activation, where allSvc Handlers executewithin a single thread of control by using the Reactor pat-tern [2];

� Thread activation, where eachSvc Handler executeswithin its own separate thread;

� Thread pool activation, where eachSvc Handler exe-cutes within a pool of threads to increase performance onmulti-processors;

� Process activation, where eachSvc Handler executeswithin a separate process.

7

The next section illustrates how differentAcceptor s canbe configured flexibly to support alternative strategies withoutrequiring changes to its external interface design or internalimplementation.

4.3 Using Design Patterns to Implement an Ex-tensible Acceptor

The ACE implementation of the Acceptor-Connector patternapplies the Wrapper Facade [2], Factory Method, Strategy,Bridge, and Abstract Factory patterns described in [1]. Thesepatterns facilitate the flexible and extensible configuration anduse of the initialization strategies discussed above. Below,each pattern used in the ACEAcceptor is described, thedesign forces it resolves are outlined, and an example of howthe pattern is used to implement theAcceptor is presented.

Using the Wrapper Facades Pattern: The Wrapper Fa-cade [2] pattern encapsulates the functions and data pro-vided by existing non-OO APIs within more concise, robust,portable, maintainable, and cohesive OO class interfaces. TheACE Acceptor uses the Wrapper Facade pattern to providea uniform interface that encapsulates differences between non-uniform network programming mechanisms, such as sockets,TLI, named pipes, and STREAM pipes.

Figure 10 illustrates how the ACEAcceptor uses theWrapper Facade patterns to enhance its portability across plat-

peer_stream_

PEER STREAM

SvcHandler

peer_stream_

TLI Stream

SvcHandler

TLIStream

SOCKStream

peer_stream_

SOCK Stream

SvcHandler

OS INTERFACES

(NON-UNIFORM)

WRAPPER FACADE

INTERFACES

(UNIFORM)

CLIENT INTERFACES

(UNIFORM)

TLIINTERFACE

SOCKET

INTERFACE

Figure 10: Using the Wrapper Facade Pattern

forms that contain different network programming interfaces,such as sockets but not TLI, or vice versa. In this example,thePEERSTREAMtemplate argument of theSvc Handlerclass can be instantiated with either aSOCKStream or aTLI Stream , depending on whether the platform supports

sockets or TLI. The Wrapper Facade pattern ensures that thesetwo classes can be used identically by different instantiationsof theSvc Handler class.

Using the Strategy Pattern: The Strategy pattern [1] de-fines a family of algorithms, encapsulates each one as an ob-ject, and makes them interchangeable. The ACEAcceptoruses this pattern to determine the passive initialization strate-gies used to create, accept, and execute aSvc Handler . Byusing the Strategy pattern, an application can configure dif-ferent initialization strategieswithoutmodifying the followingalgorithm used byaccept , as follows:

template <class SVC_HANDLER, class PEER_ACCEPTOR> voidAcceptor<SVC_HANDLER, PEER_ACCEPTOR>::accept (void){

// Create a new <SVC_HANDLER>.SVC_HANDLER *svc_handler =

make_svc_handler ();

// Accept connection from the peer.accept_svc_handler (svc_handler);

// Activate <SVC_HANDLER>.activate_svc_handler (svc_handler);

}

Figure 11 illustrates how the Strategy pattern is used toimplement theAcceptor ’s concurrency strategy. When

Acceptor

accept() A

ConcurrencyStrategy

SVC_HANDLER

activate_svc_handler()

A

ThreadStrategy

SVC_HANDLER

...activate_svc_handler(sh)...


Figure 11: Using the Strategy Pattern

theAcceptor is initialized, itsStrategy Factory con-figures the designated concurrency strategy. As shown inFigure 9, there are a number of alternative strategies. Theparticularly strategy illustrated in Figure 11 activates eachSvc Handler to run in a separate thread of control. Sinceall concurrency algorithms are encapsulated in a uniform in-terface, however, it is easy to replace this strategy with an al-ternative one, such as running theSvc Handler in a separateprocess.

Using the Bridge Pattern: The Bridge pattern [1] decou-ples an abstraction from its implementation so that the twocan vary independently. The ACEAcceptor uses this pat-tern to provide a stable, uniform interface that is both open

8

(i.e., extensible) and closed (i.e., does not require direct codechanges).

Figure 12 illustrates how the Bridge pattern is used toimplement theAcceptor ’s connection acceptance strategy

Acceptoraccept_svc_handler()accept_strategy_accept()...

A AcceptStrategy



CONS Strategy



A

2: accept_strategy_->accept_svc_handler(sh)

...1: accept_svc_handler(sh)...


Figure 12: Using the Bridge Pattern

(the Bridge pattern is used for all the otherAcceptorstrategies, as well). When a connection is establishedwith a peer, theAcceptor ’s accept method invokes theaccept svc handler method. Instead of performing thepassive connection acceptance strategy directly, however, thismethod forwards the method to the appropriate subclass ofAccept Strategy . In the example shown in Figure 12,this subclass establishes the connection using a connection-oriented protocol. Since the Bridge pattern is used, however,an application can change theAcceptor ’s connection accep-tance strategy to an alternative strategy. For example, it canchange to the connectionless version shown in Figure 8 with-out requiring any changes to the code inaccept .

Another advantage of using the Bridge pattern is that a sub-class of theAcceptor can override itsmake * methods toavoid the additional overhead of indirecting through strategyobjects on every call. In this case, theaccept method usesthe Template Method pattern [1]. In the Template Method ver-sion ofaccept the steps in theAcceptor ’s passive initial-ization algorithm are fixed, but can be overridden by derivedclasses.

Using the Factory Method Pattern: The Factory Methodpattern [1] defines a stable interface for initializing a compo-nent, but allows subclasses to specify the details of the initial-ization. The ACEAcceptor uses this pattern to allow eachinitialization strategy used by theAcceptor to be extendedwithout modifying theAcceptor or Svc Handler imple-mentations.

Figure 13 illustrates how the Factory Method pattern isused to transparently extend theAcceptor ’s creation strat-egy. The Creation Strategy base class contains a

SvcHandler

A

ConcreteSvc Handler

return new Concrete_Svc_HandlerCREATES

CreationStrategy

SVC_HANDLER

make_svc_handler()

DemandStrategy

ConcreteSvc Handler

A

make_svc_handler()

Figure 13: Using the Factory Method Pattern

factory method calledmake svc handler . This methodis invoked by themake svc handler Bridge method inthe Acceptor to create the appropriate type of concreteSvc Handler , as follows:

template <class SVC_HANDLER, class PEER_ACCEPTOR> voidAcceptor<SVC_HANDLER, PEER_ACCEPTOR>::accept (void){

creation_strategy_->make_svc_handler ();}

An implementation of a creation strategy based on thedemandstrategy could be implemented as follows:

template <class SVC_HANDLER> SVC_HANDLER *Demand_Strategy<SVC_HANDLER>::make_svc_handler (void) {

// Implement the ‘‘demand’’ creation// strategy by allocating a new <SVC_HANDLER>.return new SVC_HANDLER;

}

Note that it is the responsibility of theAcceptor ’sStrategy Factory to determine the type of subclass as-sociated with thecreation strategy .

Using the Abstract Factory: The Abstract Factory pattern[1] provides a single interface that creates families of relatedobjects without requiring the specification of their concreteclasses. TheAcceptor uses this pattern to simplify its in-terface by localizing all five of its initialization strategies intoa single class. The Abstract Factory pattern also ensures thatall selected strategies can work together correctly.

Figure 14 illustrates how the Abstract Factory pattern isused to implement theStatus Acceptor taken from theGateway example describe in Section 5. This example in-stantiates the followingStrategy Factory template:

template <class SVC_HANDLER,// Type of service handler.class PEER_ACCEPTOR>// Type of passive connection.

9

StrategyFactory

A

make_creation_strategy()make_concurrency_strategy()...


CommandStrategies

StatusAcceptor

DynamicStrategy


ThreadingStrategy Status_Router

SOCK Acceptor

ReactiveStrategy

StatusStrategies

Status_RouterSOCK Acceptor


CommandAcceptor

Command_RouterSOCK Acceptor

Command_RouterSOCK Acceptor

Figure 14: Using the Abstract Factory Pattern

class Strategy_Factory {public:

Strategy_Factory(Advertise_Strategy<PEER_ACCEPTOR::PEER_ADDR> *,

Listener_Strategy<PEER_ACCEPTOR> *,Creation_Strategy<SVC_HANDLER> *,Accept_Strategy<SVC_HANDLER, PEER_ACCEPTOR> *,Concurrency_Strategy<SVC_HANDLER> *);

// Factory methods called by Acceptor::open().Advertise_Strategy<PEER_ACCEPTOR::PEER_ADDR>

*make_advertise_strategy (void);Listener_Strategy<PEER_ACCEPTOR>

*make_listener_strategy (void);Creation_Strategy<SVC_HANDLER>

*make_create_strategy (void);Accept_Strategy<SVC_HANDLER, PEER_ACCEPTOR>

*make_accept_strategy (void);Concurrency_Strategy<SVC_HANDLER>

*make_concurrency_strategy (void);

// ...

Figure 14 shows the creation and concurrencystrategies–the other strategies are handled similarly.The Status Strategies factory instructs theStatus Acceptor to dynamically create eachStatus Router , which will execute in its own threadof control. This example illustrates the following points:

� The Abstract Factory pattern is often used in conjunc-tion with the Factory Method pattern. For example, theStrategy Factory abstract factory simplifies the inter-face to theAcceptor by consolidating all five initializationstrategy factory methods in a single class.

� The Abstract Factory pattern ensures that various thestrategies can work together correctly. For instance, theStrategy Factory can be subclassed and its various

make * Factory Methods can be overridden to create differenttypes of initialization strategies.

� Subclasses of theStrategy Factory abstract fac-tory can be used to ensure that conflicting initialization strate-gies are not configured accidentally. For example, thesingle-toncreation strategy may conflict with thethreadconcurrencystrategy since multiple threads of control will attempt to accessa single communication endpoint. AStrategy Factorysubclass can be defined to check for these conflicts and reportan error at configuration time.

5 Example: Implementing Extensi-ble Application-level Gateways Usingthe Acceptor

This section illustrates how the application-levelGatewaydescribed in Section 2 uses the pattern-basedAcceptorcomponent from Section 4 to simplify the task of passivelyinitializing services whose connections are initiated activelyby Peers . In this example thePeers play the active role inestablishing connections with theGateway .

Defining SvcHandlers for routing peer messages:The three classes shown below,Status Router ,Bulk Data Router , and CommandRouter , processrouting messages received fromPeers . These classes inheritfrom Svc Handler , which allows them to be passivelyinitialized by anAcceptor , as shown in Figure 15. Each

AC

CE

PT

OR

LAY

ER

GA

TE

WA

YLA

YE

R

Acceptor

SVC_HANDLERPEER_ACCEPTORSvc

Handler

PEER_STREAM

CommandAcceptor

Command_RouterSOCK_AcceptorSOCK_Stream

CommandRouter

1n

Bulk DataAcceptor

Bulk_Data_RouterSOCK_Acceptor

SOCK_Stream

Bulk DataRouter

1n

StatusAcceptor

Status_RouterSOCK_Acceptor

StatusRouter

SOCK_Stream

1n

INITS

INITS

INITS

Figure 15: Structure ofAcceptor Participants in theGateway

class is instantiated with a specific type of C++ IPC wrapperfacade that exchanges data with its connected peer. For

10

example, the classes below use aSOCKStream as the un-derlying data transport delivery mechanism.SOCKStreamis an ACE C++ wrapper facade that encapsulates the datatransfer functions in the socket interface. By virtue of theStrategy pattern, however, it easy to vary the data transfermechanism by parameterizing theSvc Handler with adifferentPEERSTREAM, such as aTLI Stream .

TheStatus Router class routes status data sent to andreceived fromPeers :1

class Status_Router :public Svc_Handler<SOCK_Stream>

{public:

// Performs router initialization.virtual int open (void);// Receive and route status data from/to peers.virtual int handle_event (void);// ...

TheBulk Data Router class routes bulk data sent to andreceived fromPeers .

class Bulk_Data_Router :public Svc_Handler<SOCK_Stream>

{public:

// Performs router initialization.virtual int open (void);// Receive and route bulk data from/to peers.virtual int handle_event (void);// ...

TheCommandRouter class routes bulk data sent to and re-ceived fromPeers :

class Command_Router :public Svc_Handler<SOCK_Stream>

{public:

// Performs router initialization.virtual int open (void);// Receive and route command data from/to peers.virtual int handle_event (void);//...

Defining Acceptor factories to create SvcHandlers: Thethree classes shown below are instantiations of theAcceptortemplate:

// Typedefs that instantiate <Acceptor>s for// different types of routers.typedef Acceptor<Status_Router, SOCK_Acceptor>

Status_Acceptor;typedef Acceptor<Bulk_Data_Router, SOCK_Acceptor>

Bulk_Data_Acceptortypedef Acceptor<Command_Router, SOCK_Acceptor>

Command_Acceptor;

1To save space, these examples have been simplified by omitting most ofthe detailed protocol logic and error handling code.

These typedefs instantiate theAcceptor template withconcrete parameterized type arguments forSVCHANDLERand PEERACCEPTOR. A SOCKAcceptor wrapper fa-cade is used as the underlyingPEERACCEPTORin or-der to accept a connection passively. Parameterizing theAcceptor with a different PEERACCEPTOR, such as aTLI Acceptor , is easy since the IPC mechanisms are en-capsulated in C++ wrapper facade classes. The three objectsshown below are instances of these classes that create andactivate Status Routers , Bulk Data Routers , andCommandRouters , respectively:

// Accept connection requests from// Gateway and activate Status_Router.static Status_Acceptor status_acceptor;

// Accept connection requests from// Gateway and activate Bulk_Data_Router.static Bulk_Data_Acceptor bulk_data_acceptor;

// Accept connection requests from// Gateway and activate Command_Router.static Command_Acceptor command_acceptor;

Defining strategies to initialize SvcHandlers: Thethree classes shown below are instantiations of theStrategy Factory described in Section 4.2:

// Typedefs that instantiate different types// of <Strategy_Factory>.typedef Strategy_Factory<Status_Router,

SOCK_Acceptor>Status_Strategies;

typedef Strategy_Factory<Bulk_Data_Router,SOCK_Acceptor>

Bulk_Data_Strategies;typedef Strategy_Factory<Command_Router,

SOCK_Acceptor>Command_Strategies;

These typedefs instantiate theStrategy Factory tem-plate with concrete parameterized type arguments forSVCHANDLER and PEERACCEPTOR. The three ob-jects shown below instantiate these classes to spec-ify the initialization strategies forStatus Routers ,Bulk Data Routers , and CommandRouters , respec-tively:

// Creates a multi-threaded <Status_Router>.Status_Strategies threaded

(new Well_Known_Addr,new Reactive_Listener (Reactor::instance ()),new Demand,new CONS,new Multi_Thread);

// Creates a multi-processed <Bulk_Data_Router>.Bulk_Data_Strategies process

(new Well_Known_Addr,new Reactive_Listener (Reactor::instance ()),new Demand,new CONS,new Multi_Process);

11

// Creates a single-thread reactive <Command_Router>.Command_Strategies reactive

(new Well_Known_Addr,new Reactive_Listener (Reactor::instance ()),new Demand,new CONS,new Reactive (Reactor::instance ());

Each Strategy Factory configuration shown aboveuses thewell known addressservice advertisement strategy,thereactivelistener strategy, thedemandSvc Handler cre-ation strategy, and theconnection-orientedacceptance strat-egy. To illustrate the flexibility of the Acceptor-Connectorpattern, however, eachStrategy Factory implements adifferent concurrency strategy, as follows:

� When the Status Router is activated byStatus Acceptor it runs in a separate thread.

� When activated by Bulk Data Acceptor , theBulk Data Router runs as a separate process.

� When activated by CommandAcceptor , theCommandRouter runs in the same thread as with theReactor singleton [1], which is used to demultiplexconnection requests for the threeAcceptor factories.

Note how changing the concurrency strategy does not af-fect theAcceptor class. Thus, theAcceptor ’s genericstrategy for passively initializing services can be reused, whilepermitting specific details, such as thePEERACCEPTOR,SVCHANDLER, and selected initialization strategies, tochange flexibly.

The main() gateway function: The main gateway initial-izes theAcceptor s with their well-known ports and initial-ization strategies, as follows:

// Main program for the Gateway.

int main (void) {// Initialize Acceptors with their well-known// ports and their initialization strategies.status_acceptor.open

(INET_Addr (STATUS_PORT), &threaded);bulk_data_acceptor.open

(INET_Addr (BULK_DATA_PORT), &process);command_acceptor.open

(INET_Addr (COMMAND_PORT), &reactive);

// Loop forever handling connection request// events and processing data from peers.for (;;)

Reactor::instance ()->handle_events ();}

The listener strategy configured for eachAcceptor is reac-tive, as shown in Section 5. Therefore, the program enters anevent loop that uses theReactor singleton to detect all con-nection requests fromPeers within a single thread of control.When connections arrive, theReactor singleton dispatches

the associatedAcceptor , which (1) creates an appropriatetype of Svc Handler on demand to perform the service,(2) accepts the connection into the handler, and (3) activatesthe handler. The concurrency strategy configured into eachAcceptor dictates how everySvc Handler it creates willprocesses events.

Figure 16 illustrates the relationship between Acceptor-Connector pattern components in theGateway after

ACTIVE

CONNECTIONS

: SvcHandler

: StatusRouter

: SvcHandler

: CommandRouter

: Reactor

: Acceptor

: Command

: Acceptor

: Bulk Data

: Acceptor

: Status

: SvcHandler

: StatusRouter

: SvcHandler

: Bulk DataRouter

PASSIVE

LISTENERS

Figure 16: Object Diagram for theGateway Acceptor-Connector Pattern

four connections have been established. The various*Routers exchange data with their connectedPeers us-ing the type of concurrency strategy designated by theirStrategy Factories . Meanwhile, the*Acceptor scontinue to listen for new connections.

5.1 Known Uses

UNIX network superservers: Superserver implementa-tions such as Inetd [5], Listen [6] and the Service Configura-tor [7] from the ACE framework use a master acceptor processthat listens for connections on a set of communication ports. InInetd, for example, each port is associated with a service, suchas the standard Internet servicesFTP, TELNET, DAYTIME , andECHO. The acceptor process decouples the functionality of theInetd superserver into two separate parts: one for establishingconnections and another for receiving and processing requestsfrom peers. When a service request arrives on a port monitoredby Inetd, it accepts the request and dispatches an appropriatepre-registered handler to perform the service.

CORBA Object Request Brokers (ORBs): The ORB Corelayer in many implementations of CORBA [8] uses theAcceptor-Connector pattern to passively and actively initializeconnection handlers when clients request ORB services. Forexample, [9] describes how the Acceptor-Connector pattern isused to implement the ORB Core portion in The ACE ORB(TAO), which is a high-performance and real-time implemen-tation of CORBA.

12

Web Browsers: The HTML parsing components in Webbrowsers such as Netscape and Internet Explorer use the asyn-chronous version of the connector component to establish con-nections with servers associated with images embedded inHTML pages. This pattern allows multiple HTTP connectionsto be initiated asynchronously. This avoids the possibility ofthe browser’s main event loop blocking.

Ericsson EOS Call Center Management System: Thissystem uses the Acceptor-Connector pattern to allowapplication-level Call Center Manager event servers [10] to es-tablish connections actively with passive supervisors in a net-worked center management system.

Project Spectrum: The high-speed medical image trans-fer subsystem of project Spectrum [11] uses the Acceptor-Connector pattern to establish connections passively and ini-tialize application services for storing large medical images.Once connections are established, applications send and re-ceive multi-megabyte medical images to and from the imagestores.

ACE: Implementations of the genericSvc Handler ,Connector , andAcceptor components described in theImplementation section are provided as reusable C++ classesin the ACE framework [3]. Java ACE [12] is a version of ACEimplemented in Java that provides components correspondingto the participants the Acceptor-Connector pattern.

6 Related Patterns

[1, 13, 2] identify and catalog many architectural and designpatterns. This section examines how the patterns described inthis paper relate to other patterns in the literature.

The intent of the Acceptor-Connector pattern is similar tothe Configuration pattern [14]. The Configuration pattern de-couples structural issues related to configuring services in dis-tributed applications from the execution of the services them-selves. This pattern has been used in frameworks for config-uring distributed systems, such as Regis [15], to support theconstruction of a distributed system from a set of components.In a similar way, the Acceptor-Connector pattern decouplesservice initialization from service processing. The primarydifference is that the Configuration pattern focuses more onthe active composition of a chain of related services, whereasthe Acceptor-Connector pattern focuses on the passive initial-ization of a service handler at a particular endpoint. In addi-tion, the Acceptor-Connector pattern also focuses on decou-pling service behavior from the service’s concurrency strate-gies.

The intent of the Acceptor-Connector pattern is similar tothat of the Client-Dispatcher-Server pattern [13] in that both

are concerned with the separation of active connection estab-lishment from subsequent service processing. The primarydifference is that the Acceptor-Connector pattern addressespassive and active connection establishment and initializa-tion of both synchronous and asynchronous connections. Incontrast, the Client-Dispatcher-Server pattern focuses on syn-chronous connection establishment.

The service handlers that are created by acceptors and con-nectors can be coordinated using the Abstract Session pat-tern [16], which allows a server object to maintain state formany clients. Likewise, the Half Object plus Protocol pat-tern [17] can help decompose the responsibilities of an end-to-end service into service handler interfaces and the protocolused to collaborate between them.

The Acceptor-Connector pattern may be viewed as an ob-ject creational pattern [1]. A creational pattern assembles theresources necessary to create an object and decouples the cre-ation and initialization of the object from subsequent use of theobject. The Acceptor-Connector pattern is a factory that cre-ates, passively connects, and initializes service handlers. Itsaccept method implements the algorithm that listens pas-sively for connection requests, then creates, accepts, and acti-vates a handler when the connection is established. The han-dler performs a service using data exchanged on the connec-tion. Thus, the subsequent behavior of the service is decoupledfrom its initialization strategies.

7 Concluding Remarks

This paper describes the Acceptor-Connector pattern and illus-trates how itsAcceptor component has been implementedusing other patterns to develop highly flexible communicationsoftware. In general, the Acceptor-Connector pattern is ap-plicable whenever connection-oriented applications have thefollowing characteristics:

� The behavior of a distributed service does not depend onthe steps required to passively or actively connect and ini-tialize a service.

� Connection requests from different peers may arrive con-currently, but blocking or continuous polling for incom-ing connections on any individual peer is inefficient.

The Acceptor-Connector pattern provides the following bene-fits for network applications and services:

It enhances the reusability, portability, and extensibilityof connection-oriented software: The Acceptor-Connectorpattern decouples mechanisms for connection establishmentand service initialization, which are application-independentand thus reusable, from the services themselves, which

13

are application-specific. For example, the application-independent mechanisms in theAcceptor are reusable com-ponents that know how to establish a connection passively andto create and activate its associatedSvc Handler . In con-trast, theSvc Handler knows how to perform application-specific service processing.

This separation of concerns decouples connection establish-ment from service handling, thereby allowing each part toevolve independently. The strategy for establishing connec-tions actively was written once, placed into the ACE frame-work, and reused via inheritance, object composition, andtemplate instantiation. Thus, the same passive connection es-tablishment code need not be rewritten for each application.In contrast, services may vary according to different applica-tion requirements. By parameterizing theAcceptor with aSvc Handler , the impact of this variation is localized to asingle point in the software.

Improves application robustness: By strongly decouplingthe Acceptor from the Svc Handler the passive-modePEERACCEPTORcannot accidentally be used to read or writedata. This eliminates a class of subtle errors that can arisewhen programming with weakly typed network programminginterfaces such as sockets or TLI.

However, the Acceptor-Connector pattern can also exhibit thefollowing drawbacks:

Additional indirection: The Acceptor-Connector patterncan incur additional indirection compared to using the under-lying network programming interfaces directly. However, lan-guages that support parameterized types, such as C++, Ada orEiffel, can implement these patterns with no significant over-head when compilers inline the method calls used to imple-ment the patterns.

Additional complexity: The Acceptor-Connector patternmay add unnecessary complexity for simple client applicationsthat connect with only one server and perform one service us-ing a single network programming interface. However, theuse of generic acceptor and connector wrapper facades maysimplify even these use cases by shielding developers fromtedious, error-prone and non-portable low-level network pro-gramming mechanisms.

Open-source implementations of the Acceptor-Connector and Reactor patterns are available at URLwww.cs.wustl.edu/ �schmidt/ACE.html . ThisURL contains complete source code, documentation, andexample test drivers for the C++ components developed aspart of the ACE framework [3] developed at the University ofCalifornia, Irvine and Washington University, St. Louis.

References[1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,Design Patterns: El-

ements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.

[2] 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.

[3] 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.

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

[5] W. R. Stevens,UNIX Network Programming, First Edition. EnglewoodCliffs, NJ: Prentice Hall, 1990.

[6] S. Rago, UNIX System V Network Programming. Reading, MA:Addison-Wesley, 1993.

[7] P. Jain and D. C. Schmidt, “Service Configurator: A Pattern for DynamicConfiguration of Services,” inProceedings of the3rd Conference onObject-Oriented Technologies and Systems, USENIX, June 1997.

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

[9] D. C. Schmidt and C. Cleeland, “Applying a Pattern Language to De-velop Extensible ORB Middleware,” inDesign Patterns in Communica-tions(L. Rising, ed.), Cambridge University Press, 2000.

[10] D. C. Schmidt and T. Suda, “An Object-Oriented Framework forDynamically Configuring Extensible Distributed Communication Sys-tems,”IEE/BCS Distributed Systems Engineering Journal (Special Issueon Configurable Distributed Systems), vol. 2, pp. 280–293, December1994.

[11] G. Blaine, M. Boyd, and S. Crider, “Project Spectrum: Scalable Band-width for the BJC Health System,”HIMSS, Health Care Communica-tions, pp. 71–81, 1994.

[12] P. Jain and D. Schmidt, “Experiences Converting a C++ CommunicationSoftware Framework to Java,”C++ Report, vol. 9, January 1997.

[13] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal,Pattern-Oriented Software Architecture - A System of Patterns. Wileyand Sons, 1996.

[14] S. Crane, J. Magee, and N. Pryce, “Design Patterns for Binding inDistributed Systems,” inThe OOPSLA ’95 Workshop on Design Pat-terns for Concurrent, Parallel, and Distributed Object-Oriented Sys-tems, (Austin, TX), ACM, Oct. 1995.

[15] J. Magee, N. Dulay, and J. Kramer, “A Constructive Development En-vironment for Parallel and Distributed Programs,” inProceedings ofthe 2nd International Workshop on Configurable Distributed Systems,(Pittsburgh, PA), pp. 1–14, IEEE, Mar. 1994.

[16] N. Pryce, “Abstract Session,” inPattern Languages of Program Design(B. Foote, N. Harrison, and H. Rohnert, eds.), Reading, MA: Addison-Wesley, 1999.

[17] G. Meszaros, “Half Object plus Protocol,” inPattern Languages of Pro-gram Design(J. O. Coplien and D. C. Schmidt, eds.), Reading, MA:Addison-Wesley, 1995.

14

applying design patterns to flexibly configure network services in

Documents