Section 13.1. ACHIEVING ILITIES BY CONTROLLING COMMUNICATION


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.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net