System software is characterized by two important constraints: As the underlying foundation for applications, it is expected to present a relatively unchanging interface while nevertheless adapting to the tempest of technological changes below it. System software must juggle the implementation of a large variety of often interfering and crosscutting concerns such as synchronization, scheduling, fault tolerance, and logging. A typical operating system will need sections of code responding to each of these requirements. That code is not usually segregate into neat modules, but instead interacts and tangles with the underlying functionality. System developers want to be able to evolve this code easily as new services are demanded, new devices are invented, and new protocols are implemented. An open system is characterized by its ability to modify the semantics of existing policies and by its ability to add new policies.
Systems are often implemented using the layering approach [5]; a familiar example of such layering is network protocol stacks. Here, we describe the Layered Aspect Moderator Framework, which is an extension of our prior work on framework-based AOP [4] to the development of open systems software.
Architecture
Systems can be modularized in many ways. One of the most popular is the layered approach. The system is decomposed into a number of layers (levels). Each layer relies on the functionality and interface of the layer just below it. In operating systems the bottom layer interfaces with the hardware; the top layer provides the interface for applications. Layers provide abstraction: a layer does not need to know how the operations of the layer below it are implemented. This has a great advantage in information hiding. However, information hiding is a double-edged sword for aspectual properties such as security, performance, and scheduling. Some implementation parts of the underlying, hidden implementation might eventually be critical to support a specific aspect that emerges later during a lifetime of a system. An application might need to be aware of these implementation details, and might need to overwrite some of these properties.
To overcome the hidden information duality, the Open Layered Aspect-Oriented System Framework aims at supporting two dimensions of open system implementation. The first dimension manages intralayer compositions. Each layer separates services and their aspectual properties. Each aspectual property, such as scheduling, may have more than one possible policy to realize it. Moreover, each aspectual property is extensible with evolving new policies. A moderator negotiates weaving intralayer services and aspects at runtime. The horizontal branch of our framework is responsible for this dimension of intralayer coordination. The second dimension is an open layers interface supporting interlayers compositions. Components of a higher layer can call services on the neighboring lower layer with a particular choice of aspects provided. For example, a file service can be called with either a FIFO scheduling policy or priority scheduling policy assuming these policies are provided in the lower layer. The interlayer negotiation is achieved though the vertical branch of our framework. Both the intralayer and the interlayer branches provide dynamic adaptability to system aspectual properties.
A layer consists of components and aspectual properties controlled by the Aspect Moderator using horizontal branches of the framework as illustrated on the left side of the figure appearing here. A system consists of layers and interlayer interfaces controlled by the Aspect Moderator using a vertical branch of the framework as illustrated on the right side of the figure.
Implementation
In [4] we introduced the Aspect-Moderator Framework (AMF). Components of the framework have well-defined roles and interactions:
- Each object (component) provides its services (methods) stripped of any aspectual properties (for example, no synchronization is included in Buffer objects).
- A proxy object intercepts called methods and transfers the calls to the Aspect Moderator.
- An Aspect Moderator object consists of the rules and strategies to bind aspects at runtime. Aspects are selected from the AspectBank. The Aspect Moderator orders the execution of aspects. The order of execution can be static or dynamic.
- An AspectBank object consists of aspect objects that implement different policies of variety of aspects.
The Layered Aspect Moderator Framework (L-AMF) [8] extends and modifies the basic AMF, adding an interlayer control to enable the design of open layered aspect-oriented systems. The AbstractFactory, the Adaptor, and Bridge patterns [6] are used to define abstraction and support dynamic binding of aspects. Upper-layer components can select services, and alter the specific aspectual properties by choosing from the set of different policies, which are provided by the lower layer. It may also either add new policies to an existing aspect or create a new aspect (add a security aspect and its different policies). Reconfigurability is built into the software architecture. An important property of the framework is its closure under both intralayer weaving of aspects and components and interlayer reuse. A layer application framework (the horizontal branch) and the system framework (the vertical branch) are unified in one framework. A user can employ an application framework for application software and a system framework for system software. This provides a structured discipline to resolve the information-hiding dilemma with respect to aspectual properties of systems. By using well-known patterns and the UML representation of our framework, UML tools can be used to develop both application and system software. Automated code generation can produce target code for a specific system.
Performance
Software performance is application dependent. Each application might have different tradeoffs for performance and other software properties. Moreover, the same application may need to switch policies that can affect performance at runtime. By providing openness on both cross-layer reuse and interlayer composition, each application can either alter aspectual properties from a predefined set or add an application-specific property to achieve a desired balance. Quality of Service (QoS) may depend on lower-level system implementation of specific aspects. By making these accessible and modifiable at the application level and using a structured discipline, we can make better choices between QoS policies. System software is often critical to performance and also critical to understanding system development. System performance normally requires tuning to the particular kinds of traffic and use that a given application requires. We have applied AO software technology [7] to this problem to build system software that can be tunable for each application. In fact, the mechanism is sufficiently dynamic to monitor its own behaviors and change algorithms on the fly, matching current needs.
By using a layered approach, we inherit both the advantages and disadvantages of this particular modularization of systems. One disadvantage is the overhead associated with interlayer system calls. Open implementation also has its own overhead: there is an unavoidable cost for complex systems with evolving requirements and customized features, and such systems must address certain tradeoffs.
Conclusion
The open L-AMF facilitates the separation of aspects, components, and layers and provides closure under composition rules. This closure under composition of aspects, components, and layers gives the framework its desired applicability.
As OO operating systems have emerged from OOP to provide OO advantages for systems software, we believe that AO systems have the potential to support the next generation of software systems. Such systems use aspect orientation to enhance comprehension, organization, and manipulation of system aspectual properties. Other applications of AOP to system software can be found in [2, 3].
With design patterns and language independence, software developers can use CASE tools, especially UML, to deploy open L-AMF in their target languages and systems. An example of UML AO modeling to support our framework has been presented in [1]. The L-AMF has been implemented using C++ and tested with the classic OS benchmarks such as producer/consumer and reader/writer problems. We have tested system evolution by statically removing or adding new aspects such as mutual exclusion, logging, tracing, and fault tolerance. For each system evolution the Aspect Moderator made only localized modifications [8].
Further information can be found at www.iit.edu/~concur.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment