Component Configurator E81 CSE 532S: Advanced Multi-Paradigm Software Development Component Configurator (The Pattern Formerly Known As Service Configurator) Chris Gill, Bryan Thrall, Matt Barnes Department of Computer Science and Engineering Washington University, St. Louis cdgill@cse.wustl.edu Title slide

Component Configurator: Motivating Examples 7x24 server upgrades “always on, always connected” Web server load balancing Work flows (re-)distributed to available endsystems Mobile agents Service reconfiguration on agent arrival/departure

Problem Services, broadly speaking, are needed Typical static design approach tightly couples The implementation of a particular service The configuration of that service Static approach is inflexible with respect to other services, changing requirements, upgrades to the implementation

Solution Approach Decouple implementations over time Allow different behaviors of services at run-time Offer points where implementations are re-configured Allows configuration decisions to be deferred until service initiation Allows a running server to be reconfigured

Distinguishing Characteristics Compared to other related patterns E.g., Façade, Bridge, Strategy, Decorator, etc. Component Configurator Separate single interface for service (re-)configuration Repository may maintain the states of services Very useful for fault tolerance, restart, resynch Configuration is dynamic and flexible at runtime

Service Lifecycle Compare picture to Can “park” a service Thread states Process states E.g., Silberschatz & Galvin 4th ed, Fig. 4.1 Can “park” a service Users wait for a bit Or, upgrade a copy Background reconfig Hot swap when ready

Context Implementation must be chosen or changed late in the design cycle Multiple independently selectable services Services need or would benefit from optimization/reconfiguration at run-time Dependencies between services exist and must be addressed

Context II (the other side of the coin) When is Component Configurator not appropriate? When dynamic configuration undesirable due to security, safety certification, real-time assurances Initialization or termination are tightly coupled, and/or non-uniform across components Time cost of dynamic configuration too high

Benefits Uniformity Centralized administration Modularity, testability, and reusability Configuration dynamism and control Tuning and optimization

Liabilities Lacks temporal predictability (a.k.a. non-deterministic) Ordering dependencies add complexity Potentially reduced security & reliability Increased run-time overhead and infrastructure complexity Overly narrow common interfaces

Implementation - Step 1 Define the service control interface How? Initialization Termination Suspension Resumption Information How? Inheritance-based interfaces Message-based protocols (non-OO languages, Half-Object plus Protocol)

Control Interface Example (from ACE) class Service { public: virtual int init (int argc, char *argv[]) = 0; virtual int fini (void) = 0; virtual int suspend (void); virtual int resume (void); virtual int info (char **, size_t) = 0; };

Implementation - Step 2 Define a Service Repository Responsibilities Table, list, database, etc. with references to: Objects Executable Programs Dynamically Linked Libraries (DLLs / SO libraries) Responsibilities Give access to existing services Insert and remove service “references” Track status of services (active, suspended, etc.)

Implementation - Step 3 Select reconfiguration mechanisms Location of the service’s implementation Executable program (e.g., image in flash memory) Dynamically Linked Library (in a .dll or .so file) Host / port for communication Process ID Initialization parameters Command line Graphical interface Dedicated (re-)configuration file or socket

Implementation - Step 4 Determine a service concurrency model Reactive / proactive execution Single thread of control handles everything Straightforward, but may not scale well Multi-thread/process concurrent execution Each service runs in its own thread or process More complex, possibly more efficient / robust These features themselves may be exposed as configuration options (e.g., in an ORB or Web Server)

Additional Source of Information “Service Configurator: A Pattern for Dynamic Configuration of Services” Prashant Jain and Douglas C. Schmidt CS Department, Washington University Proceedings of the Third USENIX Conference on Object-Oriented Technologies and Systems (Portland OR, June ’97) www.usenix.org/publications/library/proceedings/coots97/full_papers/jain/jain.pdf