E81 CSE 532S: Advanced Multi-Paradigm Software Development

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

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 • 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 • 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 • 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

E81 CSE 532S: Advanced Multi-Paradigm Software Development