Learning from Components : Fitting AOP for System Software

Aspect-oriented programming (AOP) and implementation of system software are fairly complex tasks on their own. Combining these two severe challenges seems to be not very inviting to operating system and system software builders. To make AOP more appealing to the system software community, we limit the sometimes pervasive nature of AOP by applying lessons learned from component-oriented programming to make AOP more manageable and easier to verify. The result is AspectLagoona, a featherweight aspect language with very simple semantics and easily understandable and well specified aspect and component code interaction. 1. MOTIVATION At first, aspect-oriented programming [7] and componentoriented programming (COP) seem to be totally irreconcilable as far as their fundamental design principles are concerned. Components are defined as a unit of composition with contractually specified interfaces and explicit context dependencies only [13]. A component can be understood as a black box for which it is only known how to connect to it to request a certain service (Figure 1). How the request is processed internally is hidden from the client. This property makes components interchangeable, as all dependencies are on the interface level only. Aspects have a very different way of interconnecting with components. Instead of communicating with components through well defined interfaces, they have to reach directly inside the component to extract and modularize crosscutting concerns (which might very well even crosscut across component boundaries). In general, commercial operating system builders tend to be much more reluctant to adapt new technologies than software writers in other domains. Operating system implementors are this conservative for a good reason: it is the responsibility of the OS to facilitate all I/O operations and to manage all hardware resources. While a faulty application might affect a certain single task performed by that particular application, a software error inside the operating system can easily interfere with all applications at once, causing ∗This work was partially supported by the National Science Foundation under grants EIA-9975053 and CCR-0105710. damage to a much greater extent. Operating systems are in general also much more difficult to debug than standard applications as usually little control over the machine is left once the OS crashed. Probably the most repulsive property of AOP for system software programmers is its crosscutting nature. While a line of component code tends to be connected to one particular action resulting in some predictable local effect, aspect code can sometimes have a subtle, sometimes even “ghostly”, influence on the whole system by bypassing established communication protocols and interfaces between components and directly manipulating internal component state. The interdependence between aspect code and component code is particularly hard to grasp as existing general purpose aspect languages like AspectJ [6] and AspectC++ [12] offer a wide variety of mechanisms for aspects to attach to component code. To make AOP more attractive for system software developers, it is required to make aspect and component code interaction more obvious by simplifying the involved mechanisms and offering the programmer a mechanism to control where aspect code is allowed to interfere with component code and where not. In this position paper, we present the language Lagoona [3] and its aspect-oriented extension AspectLagoona. Lagoona is an object-oriented language based on the idea of standalone messages and message forwarding. In Section 2 we will discuss the fundamentals of the Lagoona language. Section 3 highlights why stand-alone messages greatly simplify the understanding of aspect-component interaction while still preserving the similar level of expressibility as other generalpurpose aspect languages. Section 4 discusses related work while Section 5 finally contains our conclusions and possible future extensions. 2. LAGOONA The most obvious feature that sets Lagoona apart from established object-oriented programming languages is standalone messages. In Lagoona messages are bound to (declared in) modules instead of types, whereas most other object-oriented statically-typed languages subordinate messages to classes (Figure 2). Stand-alone messages prevent well defined interface component component component