Service Access and Configuration Patterns

This chapter presents four patterns for designing effective application programming interfaces (APIs) to access and configure services and components in stand-alone and networked systems: Wrapper Facade, Component Configurator, Interceptor, and Extension Interface.

Networked systems are inherently heterogeneous [HV99]. Therefore, a key challenge confronting researchers and developers is how to effectively design and configure application access to the interfaces and implementations of evolving service components. This chapter presents four patterns that address various aspects of service access and configuration:

• The Wrapper Facade design pattern encapsulates the functions and data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, and cohesive object-oriented class interfaces. Wrapper Facade is often applied to improve application portability by `wrapping' lower-level operating system APIs. It can also alleviate the accidental complexity associated with programming using low-level APIs.

To minimize redundancy in other patterns in the book, the Implementation section of the Wrapper Facade pattern contains detailed coverage of wrapper facades for threads, mutex locks, condition variables, and Sockets. Subsequent patterns, such as Reactor, Proactor, Acceptor-Connector, Strategized Locking, Active Object, and Monitor Object, use these wrapper facades in their own implementations. Therefore, we recommend you read Wrapper Facade first.

• The Component Configurator design pattern allows an application to link and unlink its component implementations at run-time without having to modify, recompile, or relink the application statically. Applications with high availability requirements, such as mission-critical systems that perform on-line transaction processing or real-time industrial process automation, often require such flexible configuration capabilities. Component Configurator therefore addresses aspects of service configuration and service evolution.

Other patterns in this section, particularly Extension Interface and Interceptor, can use the Component Configurator pattern to (re)configure various service roles into components in application processes without having to shut down and restart running application processes.

• The Interceptor architectural pattern allows services to be added to a framework transparently and to be triggered automatically when certain events occur. Interceptor therefore prepares a framework for its own evolution to accommodate services that are not configured or not even known during the framework's original development. Interceptor also allows other applications to integrate components and services with instances of the framework. Such services are often `out-of-band' or application-specific from the perspective of the framework instance, but are important for the productive and proper operation of applications that use the framework.
• The Extension Interface design pattern prevents the `bloating' of interfaces and breakage of client code when developers extend or modify the service functionality of existing components. Multiple extension interfaces can be attached to the same component. Extension Interface addresses both the challenge of component and service evolution and the provision of clients with an authorized and role-specific access to a component's functionality.

The topics of service access and configuration involve more challenges than are addressed by the patterns in this section. These challenges include:

• Mediating access to remote services via local proxies
• Managing the lifecycle of services, locating services in a distributed system and
• Controlling the operating system and computing resources a server can provide to the service implementations it hosts

Other patterns in the literature address these issues, such as Activator [Stal00], Evictor [HV99], Half Object plus Protocol [Mes95], Locator [JK00], Object Lifetime Manager [LGS99], and Proxy [POSA1] [GoF95]. These patterns complement those presented in this section and together describe key principles that well-structured distributed systems should apply to configure and provide access to the services they offer.