Eventizing applications in an adaptive middleware platform

IEEE DISTRIBUTED SYSTEMS ONLINE 1541-4922 © 2005 Published by the IEEE Computer Society Vol. 6, No. 4; April 2005

Eventizing Applications in an Adaptive Middleware Platform

Andreas Frei, Swiss Federal Institute of TechnologyAndrei Popovici, Swiss Federal Institute of TechnologyGustavo Alonso, Swiss Federal Institute of Technology

An architecture supporting dynamic aspect-oriented programming establishes an event infrastructure for to extend existing application's behavior at runtime.

Advances in hardware architectures and pervasive wireless networks have radically changed the computing environments a software application must face during its life cycle. Adaptive software architectures offer a way to cope with increasingly dynamic computing environments,1 and event-based systems offer many advantages for implementing such architectures.2 The main advantage is the high degree of decoupling between components. By using events to communicate, components can evolve independently. Furthermore, they can treat unexpected changes in the computing environment as new published event types to which they can adapt either by reacting dynamically or by generating other new events.

For example, consider technology changes that increase network bandwidth. Applications that today avoid network congestion by exchanging only a few compressed events might later have to manage a large number of more complex events that capitalize on additional bandwidth. Ideally, the older applications would be able to manage the new event stream without requiring significant redesign.

Policy changes are another example. They can force an application to cope with event types not foreseen during its design. An automobile control system, for instance, might have to generate an event when the engine's combustion falls below a certain efficiency level. While most modern cars monitor combustion, few of them have software that turns the information into an event. Ideally, we'd like to add this capability dynamically without having to change the installed software.

IEEE Distributed Systems Online April 2005

IEEE Distributed Systems Online April 2005 1

These examples both require dynamic extension of applications already deployed and possibly running. One way to do this is to dynamically add a software layer that handles the new events and acts as a translator for the older, less capable applications. We have developed an architecture that supports eventizing an application that is, extending it at runtime to publish relevant events in its own operations and react to events from its environment.

System architecture

Figure 1 depicts the basic system architecture. It supports three generic adaptation types:

l endowing an application with event-generation capabilities, either because the application failed to generate any event at all or because it didn't generate the necessary events;

l transforming applications into consumers of events again, because the application either didn't accept any events to start with or didn't accept the necessary events; and

l extending the dynamic resources themselves—the loaded application extensions and event system—to support further changes.

Figure 1. Basic system architecture. An application for adaptation shares a Java virtual machine with a two-layer middleware platform of basic and dynamic resources.



As Figure 1 shows, the architecture assumes the application to be adapted runs on the same Java virtual machine as the adaptive middleware. It implements the middleware on top of the JVM in two layers: the basic system resources for peer-to-peer messaging and for crosscutting extensions into the existing application (see the sidebar, "Aspect-Oriented Programming and Dynamic AOP"), and the dynamic system resources for publishing and subscribing events at runtime. The first dynamic resource is the event system.

The system architecture works as follows:

l A discovery mechanism informs the messaging layer when a new dynamic resource is available, and an application manager in the basic resources loads the discovered application extension.

l When the application extension is activated, the dynamic AOP platform inserts the AOP aspect into the AOP platform.

l The dynamic AOP platform intercepts the application's execution and monitors its progress. Whenever the application reaches selected points in the execution, the AOP platform redirects the execution to the appropriate application extension.

l Once the extension is executed, the control flow returns to the application, which then resumes its work. Exactly where and how the application resumes work depends on the nature of the executed extension.

The total architecture size is currently about 1 Mbyte, which includes the AOP engine and the event system for small devices.

Basic system resources

We designed the basic resources as a minimal required library that launches with the application.

Dynamic adaptation. The architecture bases adaptation on the dynamic AOP component,3-5 which we implemented through the Prose platform.6,7 The platform hooks into the JVM and intercepts method calls for points in the application's execution where aspects are to be executed. The figure assumes an application unaware of the events and depicts how extensions can be used to turn the application into an event consumer or producer.



Figure 2. The Prose platform handles events through extensions. In steps 1, 2, and 3, Application A is an event producer; in steps 3, 4, and 5, it is an event consumer.

Prose uses the debugger interface to intercept method calls.6 The application must therefore run on a Prose-enabled JVM. Figure 2 shows Prose first as an extension to the JVM and second as a library inside the basic resources. The Prose library registers new inserted aspects.

Messaging. Because we are mainly interested in pervasive and mobile computing applications, we chose a decentralized solution for peer-to-peer service discovery and activation. Specifically, the architecture is based on the JXTA (http://www.jxta.org/) peer-to-peer concept,8 rather than a centralized lookup service such as Jini (http://www.jini.org/). An independent lookup mechanism is a significant advantage in ad hoc application scenarios where a centralized server is not always feasible.

JXTA combines peers with similar services or behavior into peer groups. A peer can reside in different groups at the same time. This functionality lets us apply extensions to entire groups rather than to individual nodes; it is a significant advantage in scenarios that involve dozens of interacting devices.



However, JXTA was built for a wired Internet peer-to-peer network, so it is much too heavy for smaller devices. To provide a discovery mechanism in a wireless environment, we implemented a stripped-down JXTA, called JXME short for "JXTA for J2ME." JXME uses multicast to send out messages while it simultaneously listens for messages. A service provider can use this basic messaging approach to advertise services. The advertisements allow any other node in the multicast domain to discover the service and download it from the provider. This basic messaging lets us download the event system as a first service.

We implement the JXME layer directly on top of the Internet's User Datagram Protocol. This keeps the event service independent of a remote procedure call infrastructure like remote method invocation or CORBA . The result is a smaller infrastructure and the possible extension of the concept to environments not based on the chosen RPC infrastructure.

Dynamic system resources

Both the application extensions and the event system are dynamic resources.

Application extensions. An extension can include a dynamic AOP aspect or just a component or library. Upon activation, the dynamic AOP aspect inserts crosscuts into the application. On the other hand, the extension itself creates and publishes new events as well as subscribes and reacts to relevant events. The extensions for insertion are Java archive (jar) files containing a manifest file for the extension's meta information. Every extension is loaded in its own classloader so that it can be unloaded again when a specific environment no longer requires it. After an application extension is unloaded, its classloader gets garbage collected.

Extensions can use classes from other dynamic resources by specifying a list of dependencies to other extensions in their manifest. For example, the AppExt 1 in Figure 2 can use the EventSystem extension. The manifest specifies the activating class through the Main-Class entry. By taking jar specifications for a manifest to describe the application extension, the extension is activated inside JXME with the Main-Class's main method.

A node must load and activate the event system before application extensions can use it to publish and subscribe to events.

Event system implementation. We designed the event system as a dynamic resource based on a publish-and-subscribe concept.3,9-11 In this concept, a producer node publishes an event and a consumer node can subscribe to this event and receive notification if it occurs. TPS12 is a type-based publish-and-subscribe model built on top of JXTA. Our implementation uses an approach similar to TPS. Because we rely on only JXME for small devices we have implemented our own event system on top of this discovery and messaging layer.



The following code exemplifies the event system interface, which is also the interface that application extensions use:

interface Event {void init(Message msg);Message toMessage(Class class);}

interface Filter {boolean matches(Event event);}

interface EventListener {void processEvent(Event e);}

interface EventSystem {void subscribe(Filter filter, EventListener listener);void unsubscribe(Filter filter);void publish(Event event);}

The Event System interface implementation uses the JXME messaging layer to send an event to other nodes. Before sending an event, the event system serializes it into the JXME message format that can transmit as a multicast datagram packet. The event system on the receiving nodes deserializes the message into the event type. An event filter facilitates event subscription following a type- and attribute-based subscription model.10,12

Because we are targeting a decentralized infrastructure, each node manages its own subscriptions. Handling subscriptions locally eliminates related traffic on the wireless channel. On the other hand, publishing an event requires sending it to all nodes, where the event system must then check it for a registered subscription.

With some specific filtering attributes, we can mimic the JXTA peer group concept. This lets us publish new application extensions or messages by including the peer group attribute in the event.

Example adaptationsTwo brief examples illustrate how to use extensions to transform applications into event producers and consumers.



Event producers

Transforming an application into an event producer requires two things:

detecting the application state that should generate an event; and

publishing the event using whatever event system is available.

A single extension can handle both requirements. After identifying when to generate an eventsay, for example, after an application variable is updated or a method is invoked the

extension designer creates an AOP that traps the particular situation. In addition to the aspect, the application extension contains the logic necessary to publish the corresponding event. In Figure 2, step 1 indicates the execution points that are relevant for generating events. When the application reaches these points, Prose intercepts the call and invokes the extension to create an event. The event is passed on (step 2) to the underlying event system, which will then publish it (step 3).

Consider a calendar application running on a PDA. The following Prose extension can automatically generate an event for every meeting a user enters in the calendar:

1 class AddMeetingEventsAsProducer extends2 Pointcut {3 // mechanism for publishing events4 EventSystem eventSystem = EventSystem.Instance();567 // definition of the pointcut where events should be fired8 PointCutter pointCutter() {9 return Executions.before().AND(Within.methods("update")10 .OR(Within.methods("save"));11 }12 void METHOD_ARGS(MeetingDates mdates, REST arguments) {13 Event e = new Event(MeetingDate);14 eventSystem.publish(e);15 }16 }



People can use this aspect during a meeting to synchronize the entry with other calendars and send appropriate notifications to other people or applications for example, to reserve a meeting room. The aspect defines the operation that must be intercepted (line 8). As the code explains, the interception point corresponds to state changes in the MeetingDates class when the methods update or save are called. Line 13 defines the extension to be executed. This extension creates an event object with the information about the meeting and then calls the EventSystem component to publish the event.

Event consumers

To transform applications into consumers, an extension must include consumer behavior and perform two tasks:

subscribe to events of interest; and

upon an event's arrival, call the underlying application's corresponding method or methods.

The procedure is the reverse of the one used for event producers. In Figure 2, when an event arrives (step 3), the event system notifies the extension (step 4), which will then invoke the methods in the application (step 5).

Consider the calendar example again, this extension can automatically generate entries in users' calendars as a result of an entry made in a particular calendar. The following code extension performs this task:

1 class CalendarBecomesEventConsumer2 implements EventListener {34 EventSystem eventsystem;56 { eventSystem.subscribe(MeetingDateFilter, new CBEC()); }78 // action when events are received9 void processEvent(MeetingDate received) {10 // add the date to the calendar11 }

12 }



When the extension is discovered and inserted as a dynamic resource, it subscribes in the initialization phase (line 6) for MeetingDate events. When such an event arrives, the processEvent method is executed. This method inserts the date in the calendar and may notify the user of the new appointment or of potential conflicts.

Benchmarking

We conducted several experiments to test the viability of our approach. Results reported here are for local and two-node benchmarks of the architecture's basic resources and event system and for overall scalability of messaging and the event system's performance in a wireless environment. (Measurements for the dynamic AOP system's overhead are reported elsewhere.)6

We measured local benchmarks on our master laptop, an IBM ThinkPad A31 running Red Hat 9.0. For remote benchmark machines, we used IBM ThinkPad R32s running Red Hat 7.3 with built-in wireless cards.

In the first benchmark, we measured the architecture's behavior on the same node and on two different nodes with a wireless connection in ad hoc mode. In the scalability benchmark, we increased the involved nodes to nine and analyzed the behavior with various wireless parameters. The standard deviation for measurements in the first benchmark was less than 1 percent. In the scalability benchmark, the standard deviation was less than 5 percent. The higher percentage reflects other people's use of the access point during the test.

Local and two-node benchmark

The first measurement categorizes the architecture in parts:

Prose/JXME: Because Prose and JXME run as a basic resource in every node, we measured the time to send messages between two nodes. In the first test, the two nodes were running on the same machine; a second test sent messages over a wireless connection in ad hoc mode.

Event system: Because any application extension must use the event system, we measured the time spent inside the type- and attribute-based subscription mechanism.



First, we analyzed the application's overhead when it starts with the basic resources and no application extensions running. Prose uses the Java Debugger Interface on older JVMs. This creates a significant performance overhead because the whole application runs in debugger mode. The newer JVM 1.4 supports full-speed debugging and incurs no overhead when no aspects are inserted. This restricts the faster performance to devices that can run a JVM 1.4, which is not yet possible on PDAs. The second basic resource, JXME, does not slow the application down in this test because no messages are being processed.

Second, we measured JXME and the event system extension. A basic message's round-trip time (RTT) between two JVMs on the same machine takes 3.5 ms with JXME, as Figure 3 shows. On two machines and over wireless, the RTT is 10 ms. When the event system is included, an event RTT on the same machine averages 10.5 ms, which is significantly longer than a basic message; this increase goes back to the serialization and deserialization of an event type into a basic message and to the cost of the filtering mechanism involved in both JVMs. An event RTT over wireless in ad hoc mode is 13.7 ms.

Figure 3. Local and two-node benchmark: round-trip times for messages.

Scalability benchmarkIn the scalability benchmark, we analyzed the behavior of having many nodes in a wireless infrastructure publishing events and subscribing to events. The infrastructure represents a star topology, in which the master sends events and the other nodes respond immediately. The system architecture remains the same in all tests but the number of responding nodes increases. The master laptop sends out messages and events with a delay of 50 ms and 500 ms.



Figure 4 shows the average RTTs as well as the packet loss for up to nine nodes. We also compared the access point (AP) with the ad hoc (AH) mode.

Figure 4. Scalability benchmark for average round-trip time and percentage packet loss for up to nine nodes in access point (AP) and ad hoc (AH) infrastructure modes.

In our star topology, a client node must reply to a message, so the number of reply messages increases with the number of clients. The response messages are queued until the measuring thread can process them and stop the clock. The RTT in AH mode averages 14 percent less than in AP mode. The drawback is the message loss, which increases to 8 percent in AH mode compared to 2 percent in AP mode.

From this nine-node scalability benchmark, we see a strong RTT increase when the time interval for sending messages decreases. Therefore, the system currently will not scale for environments in which many nodes are sending messages in small time intervals. Switching the wireless AH infrastructure mode to an AP mode improves the packet loss for the nine-node infrastructure by 75 percent. A combination of AP mode and larger time intervals might scale better for more nodes.



Conclusion

The adaptive middleware platform we've described supports eventizing applications with extensions that are added at runtime in response to new requirements or necessary adaptations. We are currently completing its implementation and exploring more advanced forms of adaptation, including dynamic changes to the event management system itself. Furthermore, the implementation is still too heavy to run on resource-constrained devices like iPAQs, so we plan to take advantage of lighter virtual machines.

We are also using the first prototype in a variety of applications. One involves autonomous robots that coordinate their movements by exchanging events through wireless communication capabilities. Separating the software that controls robot movement from the software that deals with events and coordinated behavior is a significant advantage over existing designs greatly simplifying development and maintenance and enhancing flexibility.

For instance, one set of extensions can implement a train formation in which a group of robots follow a leading robot. The leading robot is remotely controlled with a joystick, and its movements are communicated to all other robots via events. Each robot interprets these events through extensions that control its movements as a function of its position in the formation and the leader's movement. At any time, new aspects can change the extensions to completely modify the system's behavior. For example, line formation extensions can replace the train formation extensions so that all robots move parallel to each other. Newer extensions can replace these to implement more sophisticated behavior by generating new event types, such as random departures from the formation, speed controls, and movement filters that prevent a formation from entering certain areas.

Acknowledgments

Our work was supported, in part, by the National Competence Center in Research on Mobile Information and Communication Systems (NCCR-MICS), a center supported by the Swiss National Science Foundation under grant number 5005-67322.



References

1. B.D. Noble et al., "Agile Application-Aware Adaptation for Mobility," http://doi.acm.org/10.1145/268998.266708, Proc. 16th ACM Symp. Operating Systems Principles, ACM Press, pp. 276-287.

2. J.A.D. Pace and M.R. Campo, "Analyzing the Role of Aspects in Software Design," http://doi.acm.org/10.1145/383845.383859, Comm. ACM, vol. 44, no. 10, 2001, pp. 66-73.

3. M. Haupt et al., Towards Event-Based Aspect-Oriented Runtime Environments, tech. report TUD-ST-2002-01, Software Technology Group, Darmstadt University of Technology, 2002.

4. R. Douence, P. Fradet, and M. Sadholt, "A Framework for the Detection and Resolution of Aspect Interactions,"Proc. ACM SIGPLAN/SIGSOFT Conf. Generative Programming and Component Eng. (GPCE 02), LNCS 2487, Springer-Verlag, 2002, pp. 173-188.

5. R. Pawlak et al., "JAC: A Flexible Solution for Aspect-Oriented Programming in Java,"Proc. 3rd Int'l Conf. Metalevel Architectures and Separation of Crosscutting Concerns (Reflection 2001), LNCS 2192, Springer-Verlag, 2001, pp. 1-24.

6. A. Popovici, T. Gross, and G. Alonso, "Dynamic Weaving for Aspect Oriented Programming," http://doi.acm.org/10.1145/508386.508404, Proc. 1st Int'l Conf. Aspect-Oriented Software Development, ACM Press, 2002, pp. 141-147.

7. A. Popovici, G. Alonso, and T. Gross, "Just-in-Time Aspects: Efficient Dynamic Weaving for Java," http://doi.acm.org/10.1145/643603.643614, Proc. 2nd Int'l Conf. Aspect-Oriented Software Development, ACM Press, 2003, pp. 100-109.

8. D. Brookshier, D. Govoni, and N. Krishnan, JXTA: Java P2P Programming, Sams Publishing, 2002.

9. G. Cugola, E. Di Nitto, and A. Fuggetta, "The JEDI Event-Based Infrastructure and Its Application to the Development of the OPSS WFMS," http://csdl.computer.org/comp/trans/ts/2001/09/e0827abs.htm, IEEE Trans. Software Eng., vol. 27, no. 9, 2001, pp. 827-850.

10. P. Pietzuch and J. Bacon, "Hermes: A Distributed Event-Based Middleware Architecture," http://csdl.computer.org/comp/proceedings/icdcsw/2002/1588/00/15880611abs.htm, Proc. 22nd Int'l Conf. Distributed Computing Systems (ICDCS 02), IEEE CS Press, 2002, pp. 611-618.

11. L. Fiege et al., "Engineering Event-Based Systems with Scopes,"Proc. European Conf. Object-Oriented Programming (ECOOP 02), LNCS 2374, Springer-Verlag, 2002, pp. 309-333.

12. S. Baehni, P.T. Eugster, and R. Guerraoui, "OS Support for P2P Programming: A Case for TPS," href="http://csdl.computer.org/comp/proceedings/icdcs/2002/1585/00/15850355abs.htm, Proc. 22nd Int'l Conf. Distributed Computing Systems (ICDCS 02), IEEE CS Press, 2002, pp. 355-362.



Andrei Popovici is a senior researcher in the Mobile Information and Communications Systems group at the Swiss National Science Foundation's National Centres of Competence in Research. His research interests include dynamic AOP and middleware adaptation for various platforms. He received a PhD in computer science from the Swiss Federal Institute of Technology,

Zurich. Contact him at EPFLIC PRN MICS, Station 14, CH-1015 Lausanne, Switzerland; [email protected].

Gustavo Alonso is a professor of computer science at the Swiss Federal Institute of Technology (ETH Zurich). His research interests include databases, distributed applications, mobile and pervasive computing, dynamic software adaptation, and proactive computing. He received a PhD in computer science from the University of California at Santa Barbara. He is a member of the

ACM and the IEEE Computer Society. Contact him at Institute for Pervasive Computing, ETH Zentrum, HRS G4, CH-8092 Zurich, Switzerland; [email protected].

Cite this article: Andreas Frei, Andrei Popovici, and Gustavo Alonso, "Eventizing Applications in an Adaptive Middleware Platform," IEEE Distributed Systems Online, vol. 5, no. 4, 2005.

Andreas Frei is a research scientist in the Communication Systems Research Group at the Swiss Federal Institute of Technology (ETH Zurich). His research interests include designing new middleware approaches for mobile devices. He received a masters degree in computer science from ETH. Contact him at Institute for Pervasive Computing, ETH Zentrum, HRS G2, CH-

8092 Zurich, Switzerland; [email protected].



References

1. G. Kiczales et al., "Aspect-Oriented Programming,"Proc. European Conf. Object-Oriented Programming (ECOOP 95), LNCS 1241, Springer-Verlag, pp. 220-242.

2. C. Zhang and H.-A. Jacobsen, Quantifying Aspects in Middleware Platforms," http://doi.acm.org/10.1145/643603.643617, Proc. 2nd Int'l Conf. Aspect-Oriented Software Development, ACM Press, 2003, pp. 130-139.

Aspect-Oriented Programming and Dynamic AOP

AOP software design lets us separate orthogonal concerns within an application.1 These orthogonal concerns can then be programmed as separate aspects rather than repeating them in many different places in the code. An aspect defines what to do when an application reaches a particular point in the code for example, a request to invoke methods with certain signatures or to modify a variable.

AOP's main advantage comes from abstracting concerns that crosscut through the application. Programmers can then treat these aspects as separate software modules, increasing design modularity. For instance, Charles Zhang and Hans-Arno Jacobsen2 argue that aspect-oriented re-factorization can enhance middleware modularity and reduce structural complexity.

Conventional AOP uses a weaver to merge the aspect code to the program's base code at compile time. For example, AspectJ (http://www.aspectj.org) works this way.

Dynamic AOP performs the weaving at runtime, inserting hooks in the program where additional code that is, the aspect must be executed. Whenever the application execution reaches the specified hooks, the aspect is executed. Aspects can also be dynamically withdrawn, or unwoven, leaving the application in its original state.



Documents

Eventizing applications in an adaptive middleware platform