1. 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
Title slide

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

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

4. 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

5. 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

6. 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

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

8. 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

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

10. 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

11. 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)

12. 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; };

13. 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.)

14. 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

15. 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)

16. 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)