Section 31.6. USAGE EXAMPLES OF AOP IN APPLICATION AWARENESS

31.6. USAGE EXAMPLES OF AOP IN APPLICATION AWARENESS

31.6.1. Location-Specific Functionality for Robotics

We describe here the software architecture of the robots we use for experimenting with application-awareness (see Figure 31-5 (a)). A robot is equipped with a differential drive powered by two separate motors. A front bumper is attached to a touch sensor. Two optical sensors directed to the ground can be used to sense the ground markup. The system is physically distributed on two hardware components (see Figure 31-5 (b)). At the bottom, the RCX controller available in Lego's Robotics Invention System [10] is running the LeJOS operating system [11]. At the top, an iPAQ PDA is executing a robot task in Java. The program running on the RCX is very small (less than 11 Kbytes) and can efficiently control the hardware (adjust movements to sensor inputs). For its rapid reaction, it is called "spine." Conversely, the full-fledged Java program running on the iPAQ is called "brain." The brain is in charge of executing robot tasks by decomposing them into basic macros and sending the macros for execution to the spine.

Spine functionality. The spine is provided with macros dependent on the robot's physical design (by robot design we mean the physical attachment of motors and sensors and their functions). A typical macro example is a forward move. Internally, this macro would start both wheel motors at the same time and with the same power. However, precise commands may produce imprecise results (the command to move forward for 30 seconds does not precisely delimit where the robot stops). For this reason, macros may take into account sensor inputs. This feature can be used to stop the macro execution when a marker is detected on the floor.

The macro engine is responsible for executing macros. Before each macro execution, the API of the macro engine can be used to specify what events (sensor inputs) the current macro should be sensitive to. The execution of each macro either terminates normally (e.g., after the motors have been activated for 30 seconds), or when an expected event is detected. In both cases, the macro engine saves the state of the macro and notifies the brain application. The brain application may decide to continue the execution of the macro or start the execution of a new macro.

Brain functionality. Robot tasks are Java programs running on top of the brain application. Internally, they call the API of the macro engine. Because the macro engine resides on the RCX controller, robot tasks use a macro engine proxy that exposes the same API as the macro engine itself. A robot task may declare handlers to be executed when an event is encountered. It must also specify what macros should be executed, in which order, and with what parameters values. Depending on how sophisticated the available macros are, a brain program may consist of just one macro (e.g., "find the exit of the maze") or a sequence of basic macros ("move forward until the touch sensor is active, turn, move forward"). For example, the following code is a simple sequence of macros that instructs the robot to turn in place until it can move forward:

 (1)    beginSensitive(sensor1,handler1); (2)    while (sensor1Active) { (3)         turnRight(90); (4)         forward(); (5)    } (6)    endSensitive(sensor1); 

Figure 31-5. (a) A transporter robot and (b) software architecture of the robot.

Because the brain is much more powerful in terms of computational resources than the spine, a large number of simple macros increases the programmability of a robot. As part of the brain, the executor maintains the progress and state of the currently running task. Internally, it uses a state machine model reflecting transitions between execution modes (executing a macro, executing a handler, executing a sensitive macro, etc.). The overall functionality of the brain (executing tasks, enqueueing new tasks for later execution) is exported as a Jini [2] service to application clients.

Adaptation example. As a first adaptation example, we reconsider the monitoring aspect described earlier. We created an aspect that can be woven through the Java-based brain of moving robots. For each invocation of a macro, the aspect logs the time when the command was issued, its duration, and the identity of the robot. Whenever an event is received by an event handler (e.g., after having activated a sensor with a beginSensitive command), the aspects may log the values of the sensor inputs, as well as all invocations of Java methods within the control flow of the handler method. This data is first locally stored and then asynchronously sent to a base station. Thus, one can connect to the base station and query the database that stores all operations performed by robots being monitored by the base station.

The extension can be added or removed as needed. If the robot is moved to a different location, that location's aspect sender can add a new aspect that indicates where the data must be sent for persistent storage. Within the same location, the aspect can be exchanged for a new one that indicates that the data must be sent to a program that shows the movements in a graphic display. A clear advantage of this form of adaptability is that devices only need to carry their basic functionality.

More sophisticated adaptation examples imply changing the behavior of the robot. This is the case when a robot using line-following macros enters a location with different semantics of the guidance lines. Since robot tasks are built out of many macro calls, this type of adaptation requires consistently changing the parameters sent to a subset of macros and handlers. Programs, macros, and sensor handlers are separate entities; the semantics of sensor inputs may differ from one location to another. In addition, behavior adaptation may require simultaneous changes of several distinct robots. For this reason, dynamic AOP is highly useful in consistently expressing behavior changes. Both for monitoring and for behavior changes, dynamic AOP provides obliviousness (the robot program is not aware of the aspect and must not explicitly prepare for it) and has the ability to simultaneously change many parts of several executing tasks in one atomic weaving operation.

31.6.2. Other Examples of Application Awareness

While application awareness is used to perform dynamic adaptations in the space domain, it can be also used to perform adaptation in the temporal domain. One interesting application area would be to apply hot fixes to long-running web services, both mobile and fixed. A hot fix is an extension applied to a running application server that affects the behavior of a large number of deployed and running components. Hot fixes can be used for fixing bugs or security breaches or dealing with unexpected changes in network traffic, server availability, or client-specific services [34]. We have encountered such a case in the HEDC [28] project.

HEDC, the HESSI Experimental Data Center, is a multi-terabyte repository built for the recently launched HESSI satellite. HESSI observes the sun and builds catalogs with events of interest such as sun flares. In HEDC, scientific users are confronted with large catalogs that they need to browse and update. At a certain point in time, an older servlet-based web service for browsing database tuples was reintroduced. Since the main system had evolved in the meantime, the web service resulted in performance degradation for all users (including those who were not browsing the catalog via the web). The analysis identified the problem: for each http request, a session object was created that incurred a significant workload on the database server.

Fixing the problem (adding pooling for session objects) revealed how useful aspect-oriented application awareness can be. This solution is desirable for the following considerations. First, the problem has a clear crosscutting concern: It requires replacing code (e.g., new Session()), which is scattered through multiple servlet classes, with code that reuses sessions from previous invocations. Second, in a service environment, the load on the database can be decreased considerably when the first corrections are applied directly, without taking the service offline. This second issue is addressed by the ability of the application-aware infrastructure to apply crosscutting run-time changes. Third, a large web application is usually distributed on several nodes of a network (e.g., to ensure high availability); hence changes have to be applied simultaneously on several nodes. For this third problem, the aspect support for node communities offers a practical solution.