Reconfigurable Middleware with the FraSCAti Platform

This page presents the activities of the ADAM project-team related to reconfigurable middleware with the FraSCAti platform.

A major concern of the ADAM team is to study adaptability in distributed software systems involving multi-scale environments. This concern has led to a major contribution, FraSCAti a run-time support for the Software Component Architecture (SCA) standard [1] with dynamic reconfiguration capabilities and run-time management features. This platform is considered as the back bone of the team because it provides a support to host the different technologies studied by ADAM team as Complex Event Processing (CEP) [2], Software Product Lines (SPL) or Cloud Computing [3].

Introduction: From services to components

The emergence of Service-Oriented Architecture (SOA) as an important design paradigm for online and Web-based services requires appropriate software platforms for the delivery, support and management of distributed applications. The Service Component Architecture (SCA) fulfills this requirement with an extensive set of specifications defining an SOA infrastructure that is technology independent, programming language and protocol—agnostic [4], and that reflects services as software components.

The main contribution of the FraSCAti platform is to provide:

1. run-time component configuration [5],
2. association of service components with non-functional services (e.g., transaction management, security management),
3. hooks for the management of the platform itself (to administer fault, performance, configuration, and security).

FraSCAti addresses the above issues in a systematic fashion, both at the business (application components) and at the platform (non-functional services, communication protocols, etc.) levels [6]. This is achieved through an extension of the SCA component model with reflective capabilities, and the use of this component model to implement both business-level service components conforming to the SCA specification and the FraSCAti platform itself.

References

[1] The OASIS Service Component Architecture (SCA)

[2] Towards Creating Context-Aware Dynamically-Adaptable Business Processes Using Complex Event Processing. Gabriel Hermosillo. PhD Thesis. University of Lille, France. June 2012.

[3] A Federated Multi-Cloud PaaS Infrastructure. F. Paraiso, N. Haderer, P. Merle, R. Rouvoy, L. Seinturier. 5th IEEE International Conference on Cloud Computing. Pages 392-399. Hawaii, USA. June 2012.

[4] Service-Oriented Middleware for the Future Internet: State of the Art and Research Directions. V. Issarny, N. Georgantas, S. Hachem, A. Zarras, P. Vassiliadis, M. Autili, M. Gerosa, A. Ben Hamida. Journal of Internet Services and Applications. 2(1):23-45. 2011.

[5] A Component-Based Middleware Platform for Reconfigurable Service-Oriented Architectures. L. Seinturier, P. Merle, R. Rouvoy, D. Romero, V. Schiavoni, J.-B. Stefani. Software Practice and Experience. 42(5):559-583. May 2012. Wiley.

[6] Service-Oriented Computing: State of the Art and Research Challenges. M. Papazoglou, P. Traverso, S. Dustdar, F. Leymann. IEEE Computer. 40(11):38-45. November 2007.

[7] The FraSCAti OW2 Project

Demonstration: Fire Emergency

Figure 1. Fire Emergency

The scenario of this demonstration is about managing a fire emergency alarm. This demonstration is composed of 6 actors:

1. Fire detector
2. Fire controller, that orchestrates the different actions to perform in case of emergency
3. Fire control center, a GUI to handle the different devices
4. Turnstile
5. Sprinkler
6. Twitter, a proxy to publish message on Twitter

When fire is detected, the fire detector broadcasts a message. The fire controller and fire control center receive this message. The fire controller orchestrates the emergency actions, opens turnstile, turns on the sprinkler and publishes an alert message on Twitter (INRIA_Frascati_Demo to receive notifications). Finally the different devices notify that their status has changed to the fire control center, that updates the GUI.

A support for heterogeneity

As illustrated on Figure 1, the components of this demonstration communicate via different communication protocols: Web Service, REST, Java Messaging Service (JMS), JGroups. This illustrates the interoperability capacity of the FraSCAti platform. These protocols can be sorted in two groups: Remote Procedure Call (RPC) and Message Oriented Middleware (MOM). This demonstrates the integration capacity of the FraSCAti platform to integrate other middleware.

A reflective middleware platform

The FraSCAti platform fulfills the SCA requirement in an homogeneous approach. Each paradigm is represented by components (i.e., business component, the middleware itself, communication binding, and non functional aspects). Moreover, in the FraSCAti platform, all components can be introspected and reconfigured remotely. This feature can be illustrated by using a tool named FraSCAti Web Explorer. This tool can be seen as a microscope for the platform, as illustrated on this Figure.

Figure 2. Fire Emergency with alarm

Runtime adaptability

The next step demonstrates the ability of FraSCAti to adapt at runtime. In this part, we start a new FraSCAti node, we use the FraSCAti web explorer to introspect this new node and deploy a new business component named Alarm. This component provides a service that can turn on and off an alarm sound. Next, we create a new binding to this service to expose it as a web service. Finally, we integrate this new component to the scenario by adding a binding to an alarm reference of the fire control center. All these changes are illustrated in Figure 2. Once these steps have been performed, whenever the demonstration is run again and the new service is invoked, then an alarm rings.

Behavioral introspection

When a component is composed by many components that communicate together, a global view on the behavior of the "parent component" is something that is not easy to obtain. To address this problem, FraSCAti provides non functional aspects, called intents, that are components that intercept message exchanges between components as show in the figure below. To operate behavioral introspection on our new component, we use the UML-intent that generates UML-diagram of the message exchanges. This also introduces the use of the FraSCAti Explorer, a Swing GUI that provides the same functionalities as the FraSCAti Web Explorer. We use this tool to add the intent on our new component and to display the generated UML diagram as shown in this figure.

Figure 3. FRASCATI Interception Mechanism

Figure 3. Fire Emergency with CEP fire detector

To illustrate this functionality we add to the demonstration a new type of fire detector based on Complex Event Processing engine as shown in Figure 3. This new actor is composed by 5 components :

1. Carbon monoxyde detector
2. Temperature detector
3. The CEP engine, that contains condition rules
4. Rule manager, that modify fire alert conditions
5. Fire listener, that launch the alarm

When CO rate or temperature change, the relative detector send an event to the CEP Engine. The CEP engine has been initialized with some rules, for example if CO rate is more than 15% launch Alarm Event. The Fire listener component is listening on this event, when notified it's forward the alarm message on the JGroups channel. A last component, named Rule manager, allow users to modify the different fire conditions at runtime, it's also display complex conditions like if CO rate > 15% and temperature > 45°.

See also

To know more about FraSCAti platform visit the OW2 FraSCAti web site, especially the user's guide.

For further details about the Fire Emergency demonstration watch this video or download the source.