Section 25.6. USING ASPECTS AT RUNTIME

25.6. USING ASPECTS AT RUNTIME

As indicated in the previous section, during component implementation, aspects are codified either using special aspect objects or using XML documents. We make use of these encoded aspects in many ways after component deployment. This is illustrated in Figure 25-7. Client components obtain aspect information from a component and use this to understand the component's provided or required services affected by a particular systemic aspect. They can dynamically compose method calls to invoke component functionality or call aspect object methods to indirectly invoke the component's functionality (1). We have developed a component repository that uses aspect information to index components (2). Aspect-based queries are issued by users (or even other components) to retrieve components whose functions and non-functional constraints meet those of the aspect-based query. We have developed validation agents that use aspect information to formulate tests on a deployed component (3). The agent then compares the test results to the aspect-described component constraints and informs developers whether the deployed component meets its specification in its current deployment context.

Figure 25-7. Examples of using aspects at runtime.

Figure 25-8 (top) shows how several user interface adaptations in the collaborative travel planner have been realized using dynamic discovery and invocation of component functions. The itinerary editor menu has been extended using the mechanism described in the previous section (1). Each itinerary item factory component obtains itinerary editor component's extensible affordance object and requests it to add (in this case) a menu item allowing the factory to be invoked by the user. The dialogue shown at the bottom of the figure is a similar example where a reusable version control component has added check-in and check-out buttons to the button panel of a reusable event history component (2). The version control component also obtains the distribution-providing component and persistency-supporting component of related components in its environment. It uses their facilities to store and retrieve versions and to allow sharing of versions across users. The same mechanism is used to achieve this, but different aspect objects are introspected and invoked. The map viewer has had a collaborative messaging bar added to it dynamically via the same mechanism (3).

Figure 25-8. Two examples of run-time usage of aspect information.

The use of aspect information at runtime in this way is an alternative to some of the other dynamic aspect-oriented programming approaches. These use run-time code injection or modification to achieve similar results. However, usually software components are self-contained, and their source code is often not available. Thus, we have tried to provide a way of dynamically changing running components by using aspects to understand component interfaces and behavioral constraints. The implementation of decoupled component interaction by the aspect information allows run-time adaptation.

As a final example of the use of aspects with software components, consider the issue of checking whether deployed components are correctly configured. The operation of most software components is affected by a variety of deployment scenario conditions, particularly the other components they are deployed with. We make use of aspect characterizations of components to enable run-time test construction and validation of component behavior. This approach is useful because many components cannot be adequately validated until they are actually deployed.

Figure 25-8 (bottom) illustrates how we use aspect information to support a concept of validation agents. These validation agents obtain aspect information about a component (1) that has been deployed in web or application servers (2). Different validation agents query parts of this aspect information (3) to work out the required constraints on the component's operation. Some agents also make use of deployment-specific test data (4) to formulate tests on the components. Some tests simply check that the component is accessible or that its functions work when invoked. Some check performance of components, transaction support, or resource utilization (memory, CPU, or disk space). Some validation agents run tests (5) by invoking deployed component functionality.