31.6. USAGE EXAMPLES OF AOP IN APPLICATION AWARENESS31.6.1. Location-Specific Functionality for RoboticsWe 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.
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.
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 AwarenessWhile 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. |