Filman L. E., Elrad T., Clarke S. Aspect-Oriented Software Development / Chapter13.Inserting Ilities by Controlling Communications

Computers & Technology
Education & Reference
Business & Investing
Science & Math

Aspect-Oriented Software Development
Authors: Filman L. E., Elrad T., Clarke S.
Published year: 2003
Pages: 115-116/307

<< Previous page
Table of contents
Next page >>

Chapter 13. Inserting Ilities by Controlling Communications

ROBERT E. FILMAN, STUART BARRETT, DIANA D. LEE, AND TED LINDEN

For many applications, most code is not devoted to implementing the desired input-output behavior but to providing system-wide properties like reliability, availability, responsiveness, performance, security, and manageability. We call such qualities ilities . This article describes a system that enables a more complete separation of ility implementations from functional components , allowing ilities to be developed, maintained , and modified with minimal impact on functional implementations.

Ilities can seldom be entirely implemented simply as discrete services. For example, many replication algorithms require logging and distributed update on every object modification. Similarly, performance, security, and manageability enhancements demand systematic and widespread code changes, complicating a clean design. While object-oriented design and programming has provided effective ways to modularize functional requirements into separately maintainable components, it has been less successful in enabling programmers to modularize code devoted to ilities. Object orientation does not provide programming structures that allow ilities and functionality to evolve independently over the software lifecycle.

Separating ility support from functional components becomes significantly more important and complex in distributed applications. Distributed applications typically have more stringent ility requirements and need more complex ility algorithms. This article defines an approach that supplements standard object-oriented methods with a general mechanism for injecting ility implementations into the communications between functional components. Algorithms that support ilities are separated from functional components but may be invoked whenever functional components communicate. This allows ilities and functionality to be modified and maintained with minimal impact on each other.

13.1. ACHIEVING ILITIES BY CONTROLLING COMMUNICATION

Our research integrates the following key ideas:

Intercepting communications. Our primary claim is that ilities can be achieved by intercepting and manipulating communications among functional components and by invoking appropriate "services" on all inter-component communications.

Discrete injectors . Our communication interceptors are first class objects, discrete components that have (object) identity and can be sequenced , combined, and treated uniformly by utilities. We call them injectors . In a distributed system, an ility may require injecting behavior on both the client and the server. For instance, security requires authenticating on the server credentials generated on the client. Figure 13-1 illustrates injectors on communication paths between components.

Figure 13-1. Injectors on communication paths.

Injection by object/method. Each instance and each method on that object can have a distinct sequence of injectors.

Dynamic injection. Dynamic configuration allows us to place debugging and monitoring probes in running applications and to create software that detects its own obsolescence and updates itself. There is a tradeoff , however, since security and manageability require rigorous configuration control over injector changes.

Annotations. Injectors need to communicate among themselves . For example, the authentication injector needs to know the identity and credentials of a service requestor . Our solution is to provide a general mechanism for annotating communications with meta-information . Injectors are capable of reading and modifying the annotations of requests (and reading and modifying the request arguments and target function name ).

Thread contexts. Our goal is to keep the injection mechanism invisible to the functional components. However, sometimes clients and servers need to communicate with injectors. For example, a quality-of-service injector may want to process requests in order of their priority, but the only reasonable source of request priority is the client application. While some annotations must originate from the functional applications, separation of concerns would be destroyed if functional components have to be aware of all annotations. We make annotations largely transparent to functional components by providing an "alternative communication channel." Each client and server thread has its own set of annotations, the thread context . The system arranges to copy annotations among the client's thread context, the request, and the server's thread context.

High-level specification compiler. There is a large conceptual distance between abstract ilities and discrete sequences of injectors. To span this gap, we have created Pragma, a compiler that takes a high-level specification of desired properties and ways to achieve these properties, and maps that specification to an appropriate set of injector initializations.