Cooperative agents-based Decentralized Framework for Cloud ...

Cooperative agents-based Decentralized Framework for Cloud Services Orchestration Zaki Brahmi

Jihen Ben Ali

Higher Institute of Computer Sciences and Communication Techniques Sousse University, Tunisia Email: [email protected]

Higher Institute of Computer Sciences and Communication Techniques Sousse University, Tunisia Email: [email protected]

Abstract—The Software as a Service provides complete software systems. SaaS is known as «on-demand software». In the Cloud Computing, Business Process Execution Language (BPEL) is widely used in SaaS application development. BPEL is the de facto standard for business process modeling in today’s enterprises and is a promising candidate for the integration of business. It allows describing the control flow needed to orchestrate a set of services into a meaningful business process. However, current BPEL implementations do not provide an orchestration framework that take into account the quality of service (QoS) of Clouds and services in addition to the deployment of a centralized framework. In this paper, we propose a decentralized approach to the orchestration of Cloud services using multiagent system (MAS). The proposed framework orchestrates dynamically concrete services by delegating an agent to each activity of a BPEL process. Index Terms—Cloud Computing, Multi-Agent System, Orchestration, BPEL.

I. I NTRODUCTION In service-oriented architecture (SOA) [8], service orchestration is the coordination and arrangement of multiple services exposed as a single aggregate service. In other terms, it means that only one service is going to play the role of «conductor» as it knows the logic of composition. One of the languages used in describing service composition is Business Process Execution Language (BPEL)[7]. BPEL is de facto standard for business process modeling in today’s enterprises. Cloud Computing is a new technology that has changed the entire computer industry, too, Cloud orchestration is different from the orchestration in service-oriented architecture (SOA) ; It is a typically complex operation in terms of services’ virtualization and localization. Orchestration in web services is a process of collaboration of services as predefined patterns based upon the decision about their interaction one another. However, Cloud Computing orchestration is the composing of architecture, tools and processes to deliver a defined service. Indeed, in Cloud computing environment , services are defined in an abstract way. In addition, when specifying the BPEL process, the location of these services is unknown. During the execution of this process, the discovery of a specific service is a necessary step. Listings 1 and 2 illustrates more the specificity of the orchestration difference. In Cloud Computing (as shown in

listing 2), the target service to be invoked is described via a so-called partnerLink that - besides others - contains two important elements: (1) partnerLinkType and (2) EndpointReference (EPR). (1) is static information which must be known at design time. It refers to the WSDL description of a partner service’s portType, while (2) refers to the concrete service to be invoked. An EPR contains a service’s name, its port (and binding mechanism) and its address given by a URI. At runtime, the EPR is evaluated and may even be set. Listing 1. Simple BPEL process

http://FQDN:PORT/SERVICE-ADDRESS ns:SERVICE-NAME ... ...

Listing 2. BPEL process in Cloud Computing environment

In reality, Cloud Computing is an embracing multi-layered resource stack (IaaS, PaaS, and SaaS) orchestrated in an intricate manner to ensure that application -delivered reach an acceptable QoS level for the users. Moreover, the principle of orchestration is divided into two main areas: orchestration of resources (IaaS) [1] [2] and orchestration of services (SaaS) [3] [4] [5]. In our case, we are interested in the orchestration of services (SaaS). To ensure the orchestration, we need a composition language (BPEL) and an orchestration engine which is the goal of our work. Although some work has been developed in the literature ([3] [4] [5]). Showing their effectiveness for a limited number of Cloud services, they seem ineffective at the dynamicity and the transition to scale of Clouds and services. Moreover, these approaches do not take into account the quality of service (QoS) of Clouds and services. Indeed, in a highly dynamic environment (services crashing, server-overloaded, service changing its behavior and its address, etc.), new approaches taking into account various aspects such as QoS, time response and architecture implementation work are required. To provide a solution to this problem, we propose in this paper a decentralized approach to Cloud services orchestration, based on the multi-agent system (MAS) [9]. Our idea is to delegate an agent to each activity of a BPEL process. Indeed, the use of intelligent and autonomous agents can handle the dynamicity of services in Cloud Computing. These agents cooperate to find the best orchestration, seeking, therefore, the best Cloud that offers the desired service during the execution of BPEL processes. The paper in hand is organized as follows: Major related work will be discussed in Section 2. Then, Section 3 is dedicated to outline our current work expanding the previous one by means of incorporating the multi-agent system technology. Moreover, Section 4 is dedicated to interaction protocol. Finally, Section 5 concludes the paper. II. R ELATED W ORK The primary area of research related to this work: Cloud orchestration based on the BPEL language. This section stands for presenting some prominent approaches dealing with these issues. To orchestrate Software as a Service (SaaS), the authors in [3] propose an approach that describes an abstract process of SaaS as a BPEL program. By this approach, we can orchestrate distributed services by describing the virtual information of the services without identifying the actual information of the service. In addition, to improve the performance of service orchestration and success rate, the authors select a service with minimal ping time among the candidate services. However, the

presented approach does not improve the quality of services (QoS). In this paper, we will introduce an approach that aims at avoiding similar disadvantages. In [4], there will be a presentation of the approach that exploits the implementation of BPEL to ensure the dynamicity of service being based on the principle of choosing the target machine with a low load at runtime. In case of a problem with high-level support, this approach solves it by automatically launching a virtual machine from the Cloud Computing infrastructure. This approach may solve the problem since BPEL implementation does not provide features for scheduling service calls based on the load of possible target hosts when using Cloud Computing infrastructures in peak-load situations. However, this approach fails as the authors did not take into consideration the fact that the use of cloud computing resources can be costly because data is transferred frequently from inside to outside the Cloud. In previous paper [4], the presented approach did not take into consideration data flow while scheduling. The developers of the approach [5] present a solution that takes into account data dependencies between workflow steps and the utilization of resources at runtime in order to avoid the earlier-mentioned problems caused by the previous work [4]: (1) Due to frequent data transfers between hosts, the workflow system’s throughput might be suboptimal and (2) uses cloud resources. Workflow execution might be expensive since data is frequently transferred into and out of the Cloud. Assign operations (that copy data from a source variable to a destination variable) are used to model the data flow between activities. Once the data flow graph has been generated, a Heuristic Algorithm is required. Therefore, it is necessary that this algorithm takes into account the current load of all possible target machines, network bandwidth between the machines and the amount of data to be transferred between them. After scheduling a critical path computation, the requested resources are allocated by means of a reservation mechanism. The problem with this approach is that the authors did not put into consideration the cost of using Cloud resources and the consequences of the deployment of a centralized architecture. In [6], the authors have proposed a decentralized and dynamic platform for the orchestration of web services, taking into account any exception handling. The proposed solution makes use of the account framework MAS (Multi-Agent System) in order to facilitate migration between nodes across the network. III. C LOUD S ERVICE O RCHESTRATION S OLUTION A. Background Work Based on the work studied in [6] we present our framework. Our approach is based on autonomous agents. The autonomy and sociability of agents facilitate the implementation of an orchestration engine while putting into consideration the quality of service (QoS: response time, consumption cost, scalability, etc.) of each visited Cloud. Our approach is based on the following ideas:

• • •

For each service requested, we must find the best Cloud offering this service, Organization of directory services by classifying services according to their inputs / outputs, Delegate to each activity an agent and this in order to distribute the work among a cooperative agents.

B. The Framework orchestration The architecture as illustrated in figure1 is organized according to three layers:

shown in figure 2, the class diagram AUML [13] [14] describes the types of agents and their relationships in the static system. The classes shown below represent the static architecure of our platform as a class diagram. The class «Agent» inherits the classes «UsrAg», «BPELOEAg», «InvAg» and «ProvAg». And the package «Directory»includes the services offering the same functions in a class service. This organization can accelerate the search time of Clouds providing the desired service.

Fig. 2. Class diagram illustrating the used agents

User Agent (UsrAg): The initiator of the conversation. The UsrAg presents a graphical interface through which the user can select the BPEL and WSDL files. BPEL Orchestration Engine Agent (BPELOEAg): It is the orchestration engine of our system, it interacts with other agents. Its role is to parse the BPEL process. For each activity, the BPELOEAg launches the InvAg. Figure 3 shows the architecture of the BPELOEAg. Fig. 1. Architecture of the framework of Cloud Services Orchestration

User layer: This layer announces that a process or service has just started. It is the interface between the user and the system. It encloses the User Agent (UsrAg), which offers to the user all the necessary functionalities so that he specifies his BPEL process P, and returns to him the result of the execution of P. Intermediate layer: This is the main layer of our system that represents the orchestration engine of Cloud services. It surrounds the BPEL Orchestration Engine Agent (BPELOEAg), the Invoke Agent (InvAg) and the Provisioner Agent (ProvAg). Service layer: This layer aims to provide Cloud services to be accessible by our framework on the internet. C. Architecture and role of agents Our framework consists of four types of agents: User Agent (UsrAg), BPEL Orchestration Engine Agent (BPELOEAg), Invoke Agent (InvAg) and Provisioner Agent (ProvAg). As

Fig. 3. BPELOEAg architecture

Invoke Agent (InvAg): This agent is responsible of the invocation of services and the handling of exception. It communicates with the ProvAg to get the list of Clouds offering the invoked service. After receiving this list, it is sorted in

the ascending order of QoS to get the best Cloud offering the desired service. Figure 4 shows the architecture of InvAg.

Fig. 4. InvAg architecture

The operating process of this agent is: 1) The InvAg sends to the ProvAg the characteristic of the requested service, 2) The ProvAg sends to the InvAg the list of Clouds offering the desired service, 3) The InvAg sorts this list according to the QoS of Clouds, 4) Invoke the desired service, 5) The Cloud returns the result of the requested service. 6) Verification of the result which could be: • A response from the proper execution of the called service. Then, it will be communicated to BPELOEAg. • A system exception (SE), in that case the parameters of the invoked service will be communicated to the ProvAg. Otherwise business logic exception (BLE), service will be communicated to the BPELOEAg. Provisioner Agent (ProAg): This agent acts as a directory containing a list of available Clouds. It contains two modules (the registry and the provisioner) to accomplish its task. a) Registry module: It contains information about the machines and services offered by each machine. Services offering the same functions are grouped in a class service.This classes are then connected according to a dependency graph [12]. In this graph, nodes represent class service1 and the arc represents the connection between these classes2 . This grouping allows to speed up the search time on one hand and to look in terms of QoS on the other hand. Figure 5 shows an example illustrating the classes services deployed in our approach. In this example, the services offering the same functionality (input / output) are grouped together. For example, the providers of the service S11 are C1 and C3, which assumed that the optimum QoS is 20ms and 10ms respectively. The InvAg would choose the C3 Cloud as the Cloud offering the service S11 with optQoS is equal to 10ms.

1 A Class managing a set of Cloud services that provide similar functionalities (Input and Output) with different providers. 2 Two classes are connected according to the following rule: class1 is matched to the class2 if and only if there exist, some outputs of class1 that can match some inputs of class2

Fig. 5. The classes service

b) Provisioner module: It plays the role of providing general abstractions (enable / disable the virtual machine) as it collects information about the overload of virtual machines (VM). When a machine is turned off, it must inform the registry to update data (for this host not selected when looking for a service).

Fig. 6. ProvAg architecture

Figure 6 shows the architecture and the operation process of the ProvAg: 1) The provisioner module collects information about overloading virtual machines (VMs) by sending a ping. 2) When a machine is off, the provisioner module update the directory. In this case, the registry module removes all the services installed on this machine. IV. T HE INTERACTION PROTOCOL First, we have to take into consideration that the agents interact together to achieve the whole process. To communicate, they use the FIPA language [10]. Indeed, in addition to the primitives of communication [11] of the language FIPA-ACL, the conversations between agents can be described through the following primitives: • Request_Execute(BPEL): This message sent by the user to BPELOEAg in order to start the execution of the BPEL file.

Start_InvAg (): This message sent by the BPELOEAg to the InvAg as a launch order. • Return (Ci , Ai ): The ProvAg sends this message in order to indicate to the InvAg Ai , the list Ci , • Select(Ci ): Select the best Cloud from the list Ci based on the QoS value. • Invoke (Sj ): The InvAg invoke the service Sj . • Check(R): The InvAg check the result returned by the Cloud. The result R could be a succes or a BLE. The operation process of our system is as follows (Figure 7): •

have used a benchmark containing a set of Cloud. Each Cloud is characterized by its id, QoS, address, machine and the services available on each machine. Our experiments show the evaluation of the execution time compared to the number of activities invoke or to the number of Clouds available in the system. To simplify the understanding of the functioning of our system, the value of QoS is represented as a single variable representing the sum of the response time and latency. In the first test, we set the number of available Cloud to 20 Clouds and we varied the number of activities invoke. Figure 8 shows two curves representing the evaluation of the execution time based on the number of invoke service. The first curve represent the evaluation of the execution time of our approach (Cloud Service Orchestration) and the other represent the evaluation of the execution time of the approche presented by K.Jong and al. [3] The result shows that our solution is much faster also the scalability of our system allows it to generate an optimal exact orchestration in terms of QoS in a time that does not exceed 4000 (ms).

Fig. 8. Execution time compared to the number of the invoked service Fig. 7. Sequence diagram of the framework

1) Initially, the user agent (UsrAg) receives user queries that represent the BPEL processes and sends it to the BPELOEAg. 2) The BPELOEAg parses the BPEL file and delegates for each activity an InvAg. 3) The InvAg communicates with the ProvAg to give it the list of Clouds offering the desired service. 4) The ProvAg chooses from the available Clouds the one which provides the desired service and sends to the InvAg the resulting list. 5) The InvAg orders the returned list according to the QoS. 6) The InvAg invokes the requested service. 7) Finally, the InvAg checks the returned result by the selected Cloud and informs the BPELOEAg.

We varied in the follows, the number of Clouds setting to 4 the number of the invoked activity.Figure 9 shows the evaluation of the execution time of our approach. The variation of the number of Clouds is made by increasing to 20 Clouds in order to have a clear comparison between the two approaches. The result shows that our system is more efficient than the approach developed by K.Jong and al.[3]

V. IMPLEMENTATION AND EVALUATION The experimentation are performed on an Intel (R) Core (TM)2 Duo CPU T6570 @2.10 GHz with 3 GB of RAM. To implement the various agents of our system, we use the Multi-Agents platform JADE installed on ECLIPSE. Firstly,we

Fig. 9. Execution time compared to the number of Clouds

VI. C ONCLUSION In this paper, we introduce our research efforts to address Cloud service orchestration issues. The characteristics of our approach are the dynamicity that can support a highly dynamic environment, a decentralized architecture as well as taking into account the different QoS metrics. As a future work, we intend the implementation of our real Cloud orchestration engine environment by using the Open source platforms (such as OpenStack, CloudStack, etc.) and improving the scheduling method. R EFERENCES [1] L.Changbin, M.Yun, F.Mary, V.Jacobus, «Cloud Resource Orchestration: A DataCentric Approach», 5th Biennial Conference on Innovative Data Systems Research, California, USA, January-2011 [2] L.Changbin, M.Yun, L.Boon Thau, «Declarative Automated Cloud Resource Orchestration», SOCC-11, Cascais, Portugal, October-2011 [3] K.Jong-Phil, H.Jang-Eui, C.Jae-Young,C.Young-Hwa, «Dynamic Service Orchestration for SaaS Application in Web Environment», ICUIMC-12, Kuala Lumpur, Malaysia, February-2012 [4] D.Tim, J.Ernst, F.Bernd, «On-Demand Resource Provisioning for BPEL Workflows Using Amazon’s Elastic Compute Cloud», 9th IEEE/ ACM International Symposium on Cluster Computing and the Grid, Shanghai, China, 2009 [5] D.Tim, J.Ernst, N.Thomas, S.Dominik, F.Bernd, «Data Flow Driven Scheduling of BPEL Workflows Using Cloud Resources», IEEE Computer Socety, Marburg, Germany,2010 [6] Zaki BRAHMI, Mounira ILAHI, «Enhancing Decentralized MAS-based Framework for Composite Web Services Orchestration and Exception Handling by means of Mobile Agents Technology», Active Media Technology, 5th International Conference, AMT 2009, Beijing, China, October 22-24, 2009 [7] B.Mathew, J.Matjaz, Poornachandra, «Business Process Execution Language for WS», ISBN : 1904811817, January-2006 [8] B.Douglas, D.David, «Web Services, Service-Oriented Architectures and Cloud Computings», The Savvy Manager’s Guide Second Edition, 2013 [9] J.Nick, «Intelligent Agents: Agent Theories, Architectures, and Languages», Springer-Verlag USA-1999 [10] FIPA English Auction Interaction Protocol Specification, «http://www.fipa.org/specs/fipa00031/index.html», 2001 [11] T. Finin, R. Fritzson, and D. McKay, «An overview of KQML : A Knowledge Query and Manipulation Language», Technical report, University of Maryland Baltimore Country, 1992 [12] Zaki Brahmi, M.M. Gammoudi, «QoS-aware Automatic Web Service Composition based on Cooperative Agents», IEEE 22nd International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, (WETICE), 2013, pp.27, 32, 17-20 June 2013. [13] O.James, P.Dyke, B.Bernhard, «Representing Agent Interaction Protocols in UML», AAAI conference, Barcelona, 2000 [14] O.James, P.Dyke, B.Bernhard, «Extending UML for Agents», AgentOriented Information Systems Workshop at the 17th National conference on Artificial Intelligence, 2000