adds monitoring and reconfiguration facilities to services of a service-based application and deploys them in the cloud using a scalable micro-container.
2013 IEEE 27th International Conference on Advanced Information Networking and Applications
Adding Monitoring and Reconfiguration Facilities for Service-based Applications in the Cloud Mohamed Mohamed, Djamel Bela¨ıd and Samir Tata Institut TELECOM, TELECOM SudParis, UMR CNRS Samovar Evry, France Email: {Mohamed.Mohamed, Djamel.Belaid, Samir.Tata}@it-sudparis.eu application properties. That can be done by polling or by notification on a regular way or whenever a change has occurred. When applied to service-based applications in a cloud environment, monitoring faces many challenges. First, this task should be done at different granularities of applications and it must deal with different kind of resources (i.e., network, compute, storage, software, etc.). The nature of these resources’ properties and the way their values should be retrieved depends on the application being monitored. Second, monitoring solutions have to be themselves scalable when they are applied to scalable applications deployed in cloud environments. Many attempts to provide monitoring of service-based applications in the Cloud exist, but almost all the proposed solutions give tooling solutions (i.e., these approaches use a monitoring tool, whose role is to expose sensors to collect information about the application) without allowing the tuning of monitoring at different granularities of the application. Moreover, at the best of our knowledge, all of the existing monitoring solutions either do not take care at all of scalability issue, or do not include an efficient solution to that problem. In this paper, we propose a framework that adds monitoring and reconfiguration facilities automatically to services allowing the fine tuning of monitoring and reconfiguration at different granularities of the application. This framework provides the needed mechanisms to render services able to be monitored (monitorable) and to be reconfigured (reconfigurable) even if they were not designed with these facilities. In addition, in order to tackle the scalability challenge, our framework extends and makes use of a scalable micro-container, we proposed in a previous work [3], to host services in the Cloud. To validate our approach, we performed a list of experiments showing the efficiency of our approach in a Cloud environment. The first version of our framework was presented in [4]. It did not deal with reconfiguration, nor with method monitoring aspects. Moreover, the used mechanisms to add monitoring facilities was intrusive (byte-code modification of the service). Finally, no experimental validation was proposed. The rest of this paper is organized as follow: Section II presents the state of the art in monitoring systems. Then, Section III presents a background for our work. Section IV details our framework and the different transformations to apply on services to render them monitorable and reconfigurable.
Abstract—Cloud computing is a recent paradigm in information technology enabling an economic model for virtual resources provisioning. For this paradigm, service oriented Architecture (SOA) is a pillar block to build applications. To efficiently manage service-based applications in the cloud, monitoring and reconfiguration remain important tasks but it is still a challenge to find a solution that reconciles the scalability, the memory consumption, and the efficiency. In this paper, we propose a framework that adds monitoring and reconfiguration facilities to services of a service-based application and deploys them in the cloud using a scalable micro-container. Unlike the existing initiatives, our framework adds dynamically these facilities to services that were not designed to be monitored or reconfigured. This makes the developers’ task easier, letting them focusing on the business of their services instead of the non functional property of monitoring and reconfiguration. Moreover, our framework uses a scalable micro-container for services’ deployment in the cloud to be inline with the scalability of this environment. The evaluation that we performed proves the efficiency and the flexibility of our approach for service-based applications in the cloud. Index Terms—Cloud Computing; Monitoring; Reconfiguration; Component Model; Scalability; Service Containers;
I. I NTRODUCTION Cloud Computing is a recent trend in information technology, it refers to a model for enabling ubiquitous, convenient, on demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal effort or service provider interaction [1]. In this paradigm, there are three well discussed layers of services known as ”IaaS” for Infrastructure as a Service, ”PaaS” for Platform as a Service and ”SaaS” for Software as a Service. Other ”XaaS” terms are used nowadays to name different resources provided as services in the cloud. Cloud environments can be used to host service-based applications that follow Service Oriented Architecture (SOA). SOA is a collection of services which communicate with each other [2]. Each service must be self-contained (i.e., it can always provide the same functionality, independently of other services). As any type of applications, for a service-based one deployed in a cloud environment, monitoring and reconfiguration remain important and challenging tasks. Reconfiguration consists of changing the state of an application, while monitoring process consists of informing an interested part (a user, a service, an application, etc.) about the status of the monitored 1550-445X/13 $26.00 © 2013 IEEE DOI 10.1109/AINA.2013.46
756
Section V describes the platform that combines monitoring and reconfiguration with a scalable micro-container to deploy services in the Cloud. In Section VI, we present the implementation of our work followed by the evaluation showing the efficiency of our approach in Section VII. Finally, in Section VIII, we conclude the paper and present our future work.
a complete copy of the cluster monitoring data. Aggregation of monitoring data is done by polling child nodes at periodic intervals. Monitoring data is exported using a TCP connection to the node being polled followed by a read operation of its monitoring data. Ganglia Monitoring is implemented by a monitoring daemon, which is organized as a collection of threads, each assigned a specific task: 1) Collect and publish thread: collects local node information and publishes it on a well known multicast channel. It sends periodic heartbeats, 2) Listening threads: listen on the multicast channel for monitoring data from other nodes and updates monitoring data storage, and 3) XML export threads: accept and process client requests for monitoring data. Ganglia Monitoring system assumes the presence of a native multicast capability, an assumption which does not hold for the internet in general. The mOSAIC framework [8] offers a Monitoring/Warning system that monitors applications’ components and cloud resources. From authors’ point of view, this system should realize the following tasks: monitor cloud resources, monitor applications’ components and discover warning conditions. The proposed framework contains four basic elements: 1) Monitoring event buses that collect monitoring events from the resources, 2) Connectors related to the event buses to enable the interception of monitoring events by the suitable components, 3) Connectors receiving the events from applications to the event buses, and 4) Monitoring/Warning component. In this system, only one archiver collects monitoring information from different collectors and stores the messages in a storage system, and one component called the observer accesses the storage filled by the archiver and generates events in order to distribute selected information to all the interested components. In their work [9], G. Katsaros et al. proposed an architectural approach spanning over virtualization and physical levels to collect monitoring data. They combined many existing open source solutions (e.g. Lattice [10], Ganglia [7], Nagios [6]) to get one holistic application that cover different layers. They use collectors to extract data from different layers (virtual and physical) and externalize it to the upper layer using an external data collector. Moreover, a monitoring manager serves as the orchestrator of the whole monitoring process by controlling and providing the needed interfaces to add or to consume monitoring information. In this approach, only one aggregator is responsible of aggregating and storing all the collected data. Almost all of these monitoring approaches target monitorable components and do not tackle the case where components are not designed to be monitored. In contrast, in our approach, we provide transformations to apply on components to render them monitorable even if they were not designed with monitoring facilities. Moreover, in the stated works, the monitoring systems do not address scalability issues. In fact, the use of only one component as a channel for sending monitoring information (buse, channel, integrator, etc) can form a bottleneck for all the system. In our work, we propose to use a scalable micro-container enhanced with monitoring facilities to reconcile monitoring and scalibility issues. Our approach
II. S TATE OF THE A RT In the literature, there are many attempts to provide monitoring applications in the cloud and in distributed systems. In this section, we present some proposed approaches in the monitoring area. We conclude by explaining the limitations of these approaches and giving our objectives to overtake these limits. JASMINe Monitoring [5] is a Java enterprise application running on JOnAS JavaEE server to offer functionalities to supervise distributed middleware infrastructure. When JASMINe Monitoring is started, a JOnAS server instance is started and the application is deployed on that server. Some monitoring probes are started at the same time and periodically collect data about the servers resources such as CPU and memory usage. JASMINe probes are Java applications aiming at monitoring Java middleware targets (e.g. JEE servers, Enterprise Service Bus, Virtual Machines, OS). Probes use a technique based on Java Management Standard JMX which allows collecting monitoring data from Managed Beans exposed by targets. Probes interact with Managed Beans by sending commands to poll the exposed data. Nagios [6] is an open-source core system for network monitoring. It allows monitoring IT infrastructure to ensure that systems, applications and services are functioning properly. Monitoring can be applied on private or public services (private services are services and attributes of a server and public services are those available across network). To monitor any target, Nagios uses a list of plug-ins that would be executed to poll the target status. A plug-in acts as an abstraction layer between the monitoring daemon and the monitored targets. It enables remote command execution to know the status of the monitored target. There are several plug-ins for different protocols as SNMP, NRPE or SSH. Monitoring using Nagios can result in high load on the monitoring server if applied on a large number of targets. Ganglia [7] is an open-source monitoring system for highperformance computing systems. It is based on a hierarchical design targeted at federations of clusters. It uses a multicastbased listen/publish protocol within a cluster. Within each cluster, Ganglia uses heart beats messages on a well known multicast address as the basis of a membership protocol. Membership is maintained by using the reception of a heartbeat as a sign that a node is available. Each node monitors its local resources and sends multicast packets containing monitoring data on a well known multicast address. All nodes listen for monitoring packets on the agreed multicast address to collect and maintain monitoring data for all other nodes. Each cluster can be represented with one node, since all the nodes contain
757
adds more flexibility enabling one channel monitoring (i.e., one channel for all monitored components) and multi channel monitoring (i.e., one channel per monitored component). In the next section, we introduce the component model that we use to represent services and we define the monitoring aspects that we use in our work.
offers the requested property, thus, solving the dependency. Components can be combined together in a composite as an assembly of components to build service-based applications. The required property may be that of a primitive component or calculated from the properties of a composition of components (composite component) as is done in COSMOS [17]. This required property description is important in Monitoring process which consists of informing the interested component about the changes of required properties or notifying it on a regular way or for each property variation. We consider two models of monitoring: monitoring by polling or by subscription. Polling is the simpler way of monitoring, as it allows the observer to request the current state of a property whenever there is a need. To make it possible, the interested service can generally interact with a specific interface that provides a getter of the needed property. Monitoring by subscription model is based on a publish/subscribe system which is defined as a set of nodes divided into publishers and subscribers. Subscribers express their interests by subscribing for specific notifications independently of the publishers. Publishers produce notifications that are asynchronously sent to subscribers whose subscriptions match these notifications [18]. There are two modes of monitoring by subscription: on interval and on change. For the on interval mode, the publisher (producer) broadcasts the state of its properties periodically to the subscribers (consumers). The on change mode contains three types of monitoring: ∙ Property Changed Monitoring (PCM): the monitored component has to send notifications to all subscribers whenever a monitored property is changed; ∙ Method Call Monitoring (MCM): the monitored component sends notifications whenever one of the service’s methods is invoked; and ∙ Execution Time Monitoring (ETM): the monitored component notifies the subscribers about the execution time whenever a service invocation is occurred. A component may specify the starting time and the duration of subscription. For subscription on interval it must specify the notification interval value. For the two modes, the interested component of monitoring must implement a notification callback through which it will receive appropriate notification. In the next section, we describe our framework and different transformations to apply on components to render them monitorable and reconfigurable.
III. BACKGROUND In this section, we will present the component model we use in our work. Then, we will define the different monitoring aspects that we are interested in. In an object-oriented paradigm, an object provides its services through a well-known interface, which specifies the functionality offered by the object. In the relatively newer component-oriented paradigm components may specify, in addition to their provided interfaces, their dependencies on the offered services of other components using required interfaces. A component may also define one or more properties representing its state. As defined by Szyperski et al. [11] ”A software component is a unit of decomposition with contractually specified interfaces and explicit context dependencies only”. Thus, a component not only exposes its services but it also specifies its dependencies. Components can be combined together in a composite as an assembly of components to build service-based applications. Most of the existing component models [12][13][14][15] allow specification of their dependencies for business services external to the component. However, they do not allow specification of their dependency for external properties. The ability to specify dependency for external properties has two important implications. First, it results in specification at relatively fine granularity thus helping the architects and designers in fine tuning the component’s requirements. Second, this fine tuning helps in elaborating the contract between two components because the properties can be enriched with additional attributes that constrain the nature of the contract through appropriate policies. To achieve this objective, in one of our previous work [16], we have proposed a component model that allows expressing this dependency explicitly in terms of required properties, which are provided by other components.
Fig. 1.
IV. M ONITORING F RAMEWORK
Component model describing required properties.
Our objective is that given a component without monitoring and reconfiguration facilities that we would like to transform in order to be able to monitor or reconfigure its properties. A transformation may apply on this component by encapsulating it in a new composite delivering the same functionality of the original component and enhancing it with non functional services of monitoring and reconfiguration. A transformation of a component is applied dynamically and is carried out by some predefined components of our framework. In the next
Fig. 1 shows main characteristics of a component that provides a service through an interface and may require a service from other components through a reference. The component may expose properties through which it can be configured. In addition, the component can specify its dependency on a certain property. This required property, which appears at the bottom of the component, will be satisfied if we can link this component with another component that
758
subsections, we introduce the main features of the transformation processes.
reconfigured using the setPropertyValue() method provided by the GenericProxy component. The framework then replaces the original component with the newly created composite in the application. 2) Monitoring by Polling: A component may express its need to monitor by polling a required property provided by another component. Similarly to the reconfiguration, we need to transform the component to make its properties to be monitorable by offering an appropriate interface of monitoring. This can be done dynamically by our framework, as shown in Fig. 3, by encapsulating the component with a generated GenericProxy component as defined above. The component can be then monitored using the getPropertyValue() method provided by the composite. The framework then uses the newly created composite instead of the original component.
A. Generic Proxy Service We have defined a general purpose interface GenericProxy that provides four generic methods. These methods are described in Fig. 2. Each implementation of this interface is associated with a component for which the first method getProperties() returns the list of the properties of the component, the getPropertyValue() returns the value of a property, the setPropertyValue() changes the value of a property and the invoke() method invokes a given method on the associated component and returns the result. public interface GenericProxy { Property[] getProperties(); Object getPropertyValue(String propertyName); void setPropertyValue(String propertyName, Object propertyValue); Object invoke(String methodName, Object[] params); } Fig. 2.
PropertyOfB BService ComponentB
BService
Description of the GenericProxy interface.
GenericProxyService
The transformations that render a component monitorable and reconfigurable uses a GenericProxy Component that implements the GenericProxy interface and the (proxy) services of that component. The byte-code of this implementation is generated dynamically by our framework.
Fig. 3.
GenericProxy
Reconfiguration and monitoring by polling.
3) Monitoring by Subscription: For the monitoring by subscription we encapsulate the original component with a generated GenericProxy component and a predefined NotificationService component as shown in Fig. 4. The NotificationService component is responsible of managing client subscriptions (Subscription service), receiving notifications (Notification service) from producers and sending them to interested subscribers. If the monitoring mode is on interval, each time the NotificationService component have to notify the subscribers, it gets (or monitor by polling) the value of the required property of the component B via the GenericProxyService.
B. Service Transformations In our approach, we have considered services’ reconfiguration and two types of monitoring: monitoring by polling and monitoring by subscription. In the first hand, reconfiguration allows the change of the current state of a property. In the other hand, polling allows the observer to request the current state of a property whenever there is a need while subscription allows an observing component to be notified about changes of monitored properties. 1) Reconfiguration: A component may express its need to reconfigure a required property of another component. The reconfiguration of a property can be made by calling its setter method. However, the component that wishes to reconfigure a property of another component does not know a priori the type of this component. To complete the reconfiguration of any component from only the name and type of a property, the reconfigurator component uses an appropriate interface that provides the method setPropertyValue() to change the value of a property. However, the component to be reconfigured may not define its properties as reconfigurable resources despite the request. So we need to transform the component to make its properties reconfigurable by offering an appropriate reconfiguration interface. This can be done dynamically by our framework, as shown in Fig. 3, by encapsulating the component with a generated GenericProxy component as defined above. The two components are combined together in a single composite that offers the services of the original component as well as the GenericProxy interface. The component can be then
PropertyOfB BService ComponentB BService GenericProxyService
GenericProxy
Notification NotificationService
Subscription callback=Notification
Fig. 4.
Monitoring by subscription multi NotificationService.
When the notification mode is on change for a required property of B, the NotificationService component offers a (callback) service of notification Notification to the GenericProxy component so that it can be notified of the changes of a required property and in turn inform all the subscribers of this change. The dynamically generated byte-code of the
759
GenericProxy allows to notify the NotificationService for the change of component B properties. The same transformations are used for the Method Call Monitoring and Time Execution Monitoring. PropertyOfA AService
PropertyOfB BService
ComponentA AService GenericProxyService
Processing Module: orchestrates all the steps to generate a micro-container; ∙ Parser: extracts data from deployment descriptors; ∙ Communication Generic Package: contains different packages implementing communication protocols; ∙ Monitoring Module: supports different monitoring models and transformations mechanisms; ∙ Assembly Module: generates a micro-container with monitoring capabilities. To generate a micro-container with a service hosted in, one must provide the service’s implementation and a deployment descriptor which describes how to assemble and deploy the micro-container into a cloud environment (Fig. 6 Actions 1 and 2). The processing module sends directly this descriptor to the assembly module before analyzing the implementation and generating the corresponding description (Fig. 6 Action 3). Then, the generated description is transmitted to the parser which notifies the processing module by service’s binding types and monitoring aspects (Fig. 6 Actions 4 and 5). The processing module instantiates the communication packages implementing the described bindings available at the Communication Generic Package (Fig. 6 Actions 6 and 7) and uses the chosen monitoring module to apply the needed transformations on the service (Fig. 6 Actions 8 and 9). Finally, it sends the new resulting implementation to the assembly module (Fig. 6 action 10) whose responsibility is to generate the new microcontainer enhanced with monitoring capabilities (Fig. 6 Action 11). As shown in Fig. 6, the Monitoring and Reconfiguration module supports service reconfiguration, monitoring by polling and monitoring by subscription with its two modes: on interval and on change. Monitoring on change mode includes Property Changed Monitoring (PCM), Method Call Monitoring (MCM) and Time Execution Monitoring (TEM). The generated micro-container (Fig. 6(b)) is responsible of managing its communication with the clients, holding its service and processing all incoming or outgoing messages. Moreover, it is important to notice that the client can interact with the micro-container to invoke the contained service, to reconfigure the service or to request monitoring information. It can also send subscription requests to receive notifications on change or on interval. To prove the efficiency of our approach, in the next section, we describe the implementation of our scalable microcontainer enhanced with monitoring capabilities. ∙
ComponentB BService
GenericProxy
GenericProxyService
GenericProxy
Notification Subscription callback=Notification
Fig. 5.
NotificationService
Monitoring by subscription one NotificationService.
In order to add more flexibility to our framework, we propose to use one NotificationService monitoring (Fig. 5) or multi NotificationService monitoring (Fig. 4). One NotificationService monitoring implies that this NotificationService manages all client subscriptions and all component notifications. In contrast, the multi NotificationService monitoring implies that every monitored component has its own NotificationService and will so manage just its subscribers and the notifications of the monitored component. The next section describes the scalable micro-container that we use to deploy services in the cloud in order to reconcile monitoring and scalability for service-based applications. V. M ONITORING WITHIN A S CALABLE M ICRO - CONTAINER In [3], we introduced a new scalable and platform independent micro-container that enables services deployment and execution in the cloud. In this paper, we want to enhance this micro-container with monitoring capabilities. For optimality and performance constraints, features of the micro-container are as minimal as possible. After studying the features provided by the container architectures of Axis2 [19], Tomcat 6 [20] and WSCRA [21], we drew up a list of basic features that should satisfy our micro-container which directly reflects the different modules that make up its architecture. These basic modules ensure the minimal main functionalities of our micro-container which are: 1) enabling the communication with clients, 2) query marshalling and demarshalling and 3) hosting the concerned service and its context. We thought of designing a deployment framework able to generate this micro-container. This framework should contain not only processing modules to ensure minimal microcontainers generation process (Parser, Compiler, etc.) but also a set of generic elements on the submission and treatment of non-functional features to be included in the microcontainer (HTTP, RMI or another generic communication, service administration tools, service billing, etc.). In order to add monitoring capabilities to the micro-container, we used the component model that we presented in paragraph III to represent components, then we added a monitoring module to the deployment framework. This latter contains several modules shown in Fig. 6 and are as follows:
VI. I MPLEMENTATION To validate our work, we took the choice to exploit a particular type of services namely Java Web services with WSDL 2.0 description. A Web service is an elementary servicebased application. The implementation process took place in different phases. We have first developed a minimal Java deployment framework, which allows developers to deploy a Java Web service on a hardcoded micro-container before deploying both of them in the cloud. After that, we developed the processing module for generating and deploying an optimal
760
Client
Communication Module
Processing Module Property Service
Composite Service
GenericProxyService Subscription
(a) Deployment Framework. Fig. 6.
(b) Generated micro-container.
Extension of the Micro-container architecture with monitoring.
and minimal micro-container. All generation steps were then carried out exclusively by this module before implementing gradually any other module. The purpose of the distribution of workload across multiple modules enhances the performance of the platform and facilitates updates and future changes. We have also developed Java clients which send requests and subscriptions to the service micro-containers and display results and notifications returned by the deployed Web services.
a new class and to modify a class file when the Java Virtual Machine (JVM) loads it. The next section presents some experiments of our microcontainer enhanced with monitoring and reconfiguration capabilities, related to memory consumption and notifications’ latency time. VII. E XPERIMENTATION In our work, we propose a platform able to deploy services in the cloud on top of scalable micro-containers, with the capability of transforming services to be monitorable and reconfigurable even if they were not designed with monitoring or reconfiguration facilities. The proposed monitoring system is flexible in the way of choosing the best deployment scenario to meet the deployer requirements. As far as we know, almost all of the existing monitoring solutions use one NotificationService to deliver monitoring information, but in our approach we exhibit the possibility of using a NotificationService at the granularity of a component. In our experiments, we compare the results obtained using one NotificationService for all publishers and using one NotificationService per publisher. To this end, we have considered two criteria: 1) Memory consumption: Memory size consumed by the micro-container and 2) Notification Latency Time: The elapsed time between the occurrence of the event and the notification reception from all subscribers. To perform these tests we used the NCF (Network and Cloud Federation) experimental platform deployed at Telecom SudParis France. The NCF experimental platform aims at merging networks and cloud concepts, technologies and architectures into one common system. NCF users can acquire virtual resources to deploy and validate their own solutions and architectures. The network is in constant evolution and has for information: 380 Cores Intel Xeon Nehalem, 1.17 TB RAM and 100 TB as shared storage. Two cloud managers allow managing this infrastructure and virtual resources i.e.
To alleviate as much as possible the generated microcontainer for performance reasons and scalability constraints, we had to refine the generation process. For this purpose, we defined a generic communication package in the deployment platform to identify and contain all the communication protocols that can support a service (e.g. HTTP, RMI, etc.). The generation process is based primarily on results Bindings components and monitoring aspects detected by the parser and secondly by the activation of corresponding communication modules from the generic communication package and the needed transformation to add monitoring facilities. The interactions between these platform modules are orchestrated by the processing module. The last phase was implementing a prototype of the monitoring framework as services that offer the transformation mechanisms to the applications. The byte-code of a GenericProxy component is generated dynamically. For this required byte-code level manipulation we used the Java reflection API and the open source software JAVA programming ASSISTant (Javassist) library [22]. The Java reflection API provides classes and interfaces for obtaining reflective information about classes and objects. Reflection allows programmatic access to information about the fields, methods and constructors of loaded classes, and the use of reflected fields, methods, and constructors to operate on their underlying counterparts on objects. Javassist is a class library for editing Java byte-codes; it enables Java programs to define
761
multi NotificationService monitoring. Each series, we fixed the number of deployed services and we changed the frequency of events occurrence. After storing these measurements, we calculate the average latency time for each series. The stored values are shown in the Fig. 8.
OpenNebula [23] and OpenStack [24]. In our case, we used OpenNebula which is a virtual infrastructure engine that provides the needed functionality to deploy and manage virtual machines (VMs) on a pool of distributed physical resources. To create a VM, we can use one of the three predefined templates offered by OpenNebula i.e. SMALL, MEDIUM and LARGE, or we can specify a new template. During our experiments, we used our specific template with the following characteristics: 4 cores (2.66 GHZ each core) and 4 Gigabytes of RAM. To perform our tests, we defined two scenarios that reflect the objectives that we want to highlight in our experiments. First, we compared micro-container memory consumption before and after adding monitoring facilities to estimate the overhead of the monitoring module on the micro-container consumption. Second, we compared notification latency time in the micro-container using monitoring system with one NotificationService or monitoring system with multi NotificationService (i.e. one NotificationService per micro-container). In the first series we deployed different numbers of services on micro-containers without monitoring capabilities and we took memory consumption measurements for each number. Then, we deployed the same number of services on top of the micro-container enhanced with the monitoring module using multi NotificationService scenario (we did not take measurements for one NotificationService monitoring because the NotificationService is outside the services’ micro-containers, so the memory consumption is the same as micro-containers without monitoring). The purpose of this experiment was to estimate the overhead of the monitoring module on the memory consumption of the micro-container. Fig. 7 shows the different values stored during these series including the JVM size.
Fig. 7.
Fig. 8. Notification latency time with one client using one NotificationService monitoring and multi NotificationService monitoring.
The Fig. 8 shows the evolution of notification latency time during the experimentation. When the number of events becomes important, the NotificationService component is exposed to a big number of notifications, since all notifications are targeting the same one. This latter should forward each notification to the list of the interested subscribers. When using a multi NotificationService monitoring, every micro-container contains its own NotificationService component. Consequently, it is asked to manage just its own subscribers. It will deal with a less number of notifications and subscribers. That explains the results shown in the Fig. 8 where the notifications’ latency time is almost the same using the multi NotificationService monitoring and it is increasing proportionally with the number of services when we use micro-containers with one NotificationService monitoring. The third series of experiments aimed at comparing notification latency time using one NotificationService monitoring and multi NotificationService monitoring with a changing number of clients. For all the tests we used one service as a publisher and one NotificationService component. Each time, we considered a clients’ number and we changed the frequency of events occurrence. The Fig. 9 shows that the values obtained using one NotificationService monitoring are a little higher then those obtained using multi NotificationService monitoring. This difference is explained by the needed time for a notification to reach the NotificationService component when we use one NotificationService monitoring, this value is relatively small when we use multi NotificationService monitoring because the publisher and the NotificationService are located in the same machine.
Memory consumption using micro-containers (MC).
These experiments show that the overhead of the monitoring module on the memory consumption of the micro-container is fair. In fact, the memory consumption is linear, increasing with the number of deployed services. In the second series of tests, we aimed to compare the notification latency time using the micro-container enhanced with monitoring in the two cases: using one NotificationService and
VIII. C ONCLUSIONS AND F UTURE W ORK In this paper, we addressed the issue of monitoring servicebased applications in cloud environments. We proposed a framework that provides the needed mechanisms to apply
762
[10] [11] [12]
[13]
[14] [15]
Fig. 9. Notification latency time with multi clients using one NotificationService monitoring and multi NotificationService monitoring.
[16]
transformations on components to render them monitorable and reconfigurable even if they were not designed with monitoring and reconfiguration capabilities. This framework encapsulates the transformed components in top of scalable micro-containers and deploys them in the cloud. To add flexibility to our monitoring solution, we propose to use one NotificationService monitoring (one NotificationService for all micro-containers) or multi NotificationService monitoring (one NotificationService per micro-container). Finally, to show the efficiency of our platform, we described its implementation and we performed different experimentations. In our future work, we aim at using monitoring information to apply adaptations or reconfigurations on components or on microcontainers during the runtime. We aim also at using the proposed mechanism of reconfiguration to reconfigure stateful components to allow their replication or replacement.
[17] [18]
[19]
[20] [21] [22] [23] [24]
R EFERENCES [1] NIST, “Final Version of NIST Cloud Computing Definition Published.” http://www.nist.gov/itl/csd/cloud-102511.cfm, 2011. [2] D. V. Thanh and I. Jorstad, “A service-oriented architecture framework for mobile services.” in Proceedings of the advanced industrial conference on telecommunications/service assurance with partial and intermittent resources conference/e-learning on telecommunications workshop. aict/sapir/elete, Telecommunication 2005, july 2005, pp. 65–70. [3] S. Yangui, M. Mohamed, S. Tata, and S. Moalla, “Scalable Service Containers.” in Proceedings of the third IEEE International Conference on Cloud Computing Technology and Science, CloudCom, 2011, pp. 348–356. [4] M. Mohamed, D. Bela¨ıd, and S. Tata, “How to Provide Monitoring Facilities to Services When They Are Deployed in the Cloud?” in Proceedings of the International Conference on Cloud Computing and Services Science, CLOSER, 2012, pp. 258–263. [5] “JASMINe Monitoring.” http://wiki.jasmine.ow2.org/xwiki/ bin/view/Main/Monitoring, 2012. [6] “Nagios Documentation.” http://www.nagios.org/documentation, 2010. [7] M. L. Massie, B. N. Chun, and D. E. Culler, “The ganglia distributed monitoring system: design, implementation, and experience.” Parallel Computing, vol. 30, no. 7, pp. 817–840, 2004. [8] M. Rak, S. Venticinque, T. Mahr, G. Echevarria, and G. Esnal, “Cloud Application Monitoring: The mOSAIC Approach.” in Proceedings of the IEEE International Conference onCloud Computing Technology and Science, CloudCom, december 2011, pp. 758–763. [9] G. Katsaros, G. Gallizo, R. K¨ubert, T. Wang, J. O. Fit´o, and D. Henriksson, “A Multi-level Architecture for Collecting and Managing Monitoring Information in Cloud Environments.” in Proceedings of the third
763
International Conference on Cloud Computing and Services Science, CLOSER, 2011, pp. 232–239. S. Clayman, A. Galis, and L. Mamatas, “Monitoring virtual networks with Lattice.” in Network Operations and Management Symposium Workshops, april 2010, pp. 239–246. C. Szyperski, Component Software: Beyond Object-Oriented Programming., 2nd ed., Boston, MA, USA, 2002. C. Becker, M. Handte, G. Schiele, and K. Rothermel, “PCOM - A Component System for Pervasive Computing.” in Proceedings of the Second IEEE International Conference on Pervasive Computing and Communications, PERCOM ’04, Florida, USA, 2004, pp. 67–76. E. Bruneton, T. Coupaye, M. Leclercq, V. Qu´ema, and J.-B. Stefani, “The FRACTAL component model and its support in Java: Experiences with Auto-adaptive and Reconfigurable Systems.” Software Practice and Experience (SP&E), vol. 36, pp. 1257–1284, 2006. OSGI, “Open Services Gateway Initiative.” http://www.osgi.org, 1999. O. S. Collaboration, “SCA Assembly Model Specification V1.00.” http://www.osoa.org, 2007. D. Bela¨ıd, I. Ben Lahmar, and H. Mukhtar, “A Framework for Monitoring and Reconfiguration of Components Using Dynamic Transformation.” International Journal On Advances in Software, vol. 3, pp. 371–384, Dec 2010. R. Rouvoy, D. Conan, and L. Seinturier, “Software Architecture Patterns for a Context-Processing Middleware Framework,” IEEE Distributed Systems Online, vol. 9, p. 1, june 2008. R. Baldoni, R. Beraldi, S. Piergiovanni, and A. Virgillito, “Measuring notification loss in publish/subscribe communication systems.” in Proceedings of the 10th IEEE Pacific Rim International Symposium, Dependable Computing, march 2004, pp. 84–93. S. Perera, C. Herath, J. Ekanayake, E. Chinthaka, A. Ranabahu, D. Jayasinghe, S. Weerawarana, and G. Daniels, “Axis2, Middleware for Next Generation Web Services.” in Proceedings of the IEEE International Conference on Web Services, ICWS ’06, sept. 2006, pp. 833–840. “Apache Tomcat Architecture.” http://tomcat.apache.org/tomcat-6.0doc/architecture/overview.html, November 2011. A. Dhesiaseelan and A. Ragunathan, “Web services container reference architecture (WSCRA).” in Proceedings of the IEEE International Conference on Web Services, ICWS ’04, july 2004, pp. 806–807. “JAVA programming Assistant.” http://www.csg.is.titech.ac.jp/ chiba/javassist, 2010. “OpenNebula.” http://opennebula.org, 2011. “Openstack.” http://www.openstack.org, 2011.
