Enhancing Decentralized MAS-based Framework for Composite Web Services Orchestration and Exception Handling by means of Mobile Agents Technology
Mounira ILAHI LI3 Member
[email protected] [email protected]
Abstract Decentralized orchestration offers performance improvements in terms of increased throughput and scalability and lower response time. However, decentralized orchestration also brings additional complexity to the system, mainly, in terms of exception handling. The research presented in this paper is carried out on the basis of some previous work of the authors, including: decentralizing orchestration of composite Web services and exception handling. We focus also on current works expanding the previous one, exhibiting thus a higher performance degree which the integration of mobile agents performs by moving the application’s functionality through the network.
1. Introduction Web services enable the new generation of Internet based applications and adjust the way business applications are developed. Although there can be some value in accessing a single web service, the greater value is derived from assembling web services into more powerful applications. Business processes are typically complex operations, comprising of numerous individual stages, and in the context of SOA each such stage is realized as a web service. Web Services Business Process Execution Language (WSBPEL) is the current industry standard frequently used to specify the composition of these steps (control flow, data flow, etc), and executed by a Web Services Orchestration (WSO) platform. Nevertheless, a main inadequacy is that BPEL relies on the centralized coordinator on which the whole specification of a business process is executed. Thus, all the messages
Zaki BRAHMI URSIIVA Member
[email protected] [email protected]
amongst the business partners are transferred and processed by the coordinator. Accordingly, the communication overload is relatively high and in some cases, the centralized coordinator becomes a bottleneck limiting so the scalability of the system. There are also arguments that this model is not flexible enough for scenarios where data flow has to be transported in a given path due to certain business constraints [6]. Starting from the intention to overcome these drawbacks, some decentralized solutions [7, 8, 9, 10, 12, 13] have been proposed. A second key problem that we can identify in process-oriented composition languages like BPEL concerns support for dynamic adaptation of the composition logic. Such languages assume that the composition logic is predefined and static, an assumption that does not hold in the highly dynamic context of web services. In fact, new web services are offered and others disappear quite often. In addition, the organizations involved in a web service composition may change their business rules, partners, and collaboration conditions. Furthermore, software, machine or communication link failures may render certain sub-process of composite services unavailable, precluding thus the successful execution of the business process. Therefore, services-based systems are inherently vulnerable to exceptions. In these cases, a replacement component should be identified and substituted for the failed one. The replacement component should have the same skills to the later i.e. to have same functionality and QoS [2]. Note that due to the static nature of BPEL, which dictates that service bindings should be hard-coded in the scenario, it is not feasible to include calls to all replacement services within a fault handler (typically 2 or 3 alternates will be specified [3]) and not possible at all to dynamically introduce new bindings or remove
outdated ones, to align with the changes in service availability. Each such change should generate a maintenance activity that will lead to modifications in the BPEL scenario code. This motivates the need for more flexible web orchestration engine of BPEL process, which supports a dynamic orchestration. To deal with these limitations, we have proposed in [14] a decentralized framework for WSO and exception handling1 based on Multi-Agent System technology. This framework allows to a BPEL process to be partitioned in a set of sub-processes. These subprocesses will be executed in a distributed fashion by a set of agents. Our approach provided a mechanism for dealing with system exceptions which is based on agent technology. Nevertheless, similarly to all other discussed proposals, our last framework is based on the assumption that each site is skilled and has the required infrastructure to do its work. An assumption that is not forever affordable. Here, we are focusing on a direction pro enhancing our previous framework. We swap, in the exception handling mechanism, the agent technology by the mobile agent technology for a purpose of resolving the above limitation, exhibiting thus a higher performance degree. The rest of this paper is organized as follows: Major related work is discussed in Section 2. Then, the authors’ previous work which builds the foundation of this research is introduced in Section 3, as well as a brief introduction to mobile agent technology. Section 4 is dedicated to outline our current work expanding the previous one by means of incorporating the mobile agent technology. Finally, Section 5 concludes this paper and sketches out our future work.
2. Related Work There are two primary areas of research that are related to this work: decentralized composite web services orchestration and exception handling. This section stands some approaches dealing with these two issues. We present each proposal with respect to our two concerns (decentralizing composite web services orchestration of exception handling). In [8], the authors present a technique to partition a composite web service written as a single BPEL program into an equivalent set of decentralized processes based on the PDG (Program Dependence 1
Exception handling defines how exceptional situations that can arise during execution of the composite model should be handled.
Graph). This technique creates one partition per component web service in the flow specification. Each partition is deployed in network proximity with the component web service that it invokes, and acts like a proxy that processes and manages incoming and outgoing data at that component related to this flow. Nevertheless, a major boundary of this work is that errors do not propagate correctly in the decentralized setup. Thus, handling errors at build time remains centralized and all errors are propagated back to the client. Further, this approach assumes that each site should have the infrastructure supporting this execution model. To handle exceptions, the authors in [7] extend their work in [8] to overcome the shortcoming listed above. The exception handling mechanism relies on correct partitioning of the input service specification. As well, the partitions are increased with extra code that aids in the overall exception handling mechanism. However, the proposed scheme is still centralized since fault handlers and compensation handlers for a scope reside in the root partition. The author in [10] develops A Web Service Composition Tool (WSCT) for specifying a composite service. The WSCT has only to activate the first task in the composite service. The rest of the tasks will be activated by the service providers of the tasks’ predecessors when these ones are executed. However, we discern that factual decentralizing mechanism is unclear and details on how to partition the different tasks among service providers are not provided. To deal with exceptions, the author uses a Nonblocking mechanism. Candidate providers need to monitor the failure of the primary provider. In that case, they run an election protocol to opt for the next highest ranked candidate provider as the new primary provider. Accordingly, the failure of a service provider will not block the progress of a composite service. Though, this approach suffers from (1) a static aspect like BPEL when arranging the candidate providers, (2) a high communication overhead when ensuring the exception handling mechanism, and (3) uncertainty of failure detection: During its execution, a primary provider might be wrongly suspected of having failed. As a result, a new primary provider is elected and carries out the task. Thus, the task is executed twice. In [12], the author proposes a peer-to-peer approach which is of continuation2-passing style. Knowing the continuation of the current execution, the control can 2
A continuation is the rest of an execution at a certain point of the execution
be passed to the appropriate subsequent processing entities without any involvement of a central engine. The approach is based on the assumption that a site can figure out the execution plan that follows up if a message also contains a continuation. Thus, conducting the execution of a process is the sequences of sending and interpreting messages that contain continuations. Nevertheless, the proposed approach is also based on the assumption that each site is apt to figure out the execution plan that follows up, which might be not always affordable. Once more, certain scenarios businesses might want to impose restrictions on access to the data they provide. Hence, this approach can lead to violation of these data flow constraints since each site has access to all the input data. If some fault event occurs, a partially executed process must be rolled back. To make possible process rollbacks, two continuations are allied with any particular execution point. The success continuation represents the path of execution towards the successful completion of the process. The failure continuation represents the path of execution towards the proper compensation of committed effects after certain failure events. Further details on how the approach supports process recovery by automatically generating recovery plans into failure continuations are lacking. As well, software agents have been recognized as a promising technology for managing workflows. For example, in [9], SwinDeW-A (Swinburne Decentralized Workflow with Agents), a service workflow management framework which is based on Peer-to-Peer and agent technologies have been introduced. The multi-agent system consists of a collection of distributed software agents that work conjunctly with each other to afford core workflow services. Each agent is connected with and acts on behalf of a consumer or provider service. The service requestor agent has only to subscribe monitoring data to keep itself up to date about the state of workflow enactment. However, intermediate application data and control are transmitted among relevant service providers agents openly to bring together the execution of the workflow. Therefore, a main drawback is that Monitoring data remains centralized since the agent of the service requestor must keep itself informed about the state of workflow enactment. Upon a service failure or an unavailable provider exception, the service requestor agent must negotiate with the other available service providers agents which can afford the required service. The involved agents collaborate and negotiate with each other to handle the exceptions and recover automatically. Then, the service requestor agent dynamically contracts a new supplier
for the failed service. Accordingly, exception handing mechanism is yet again centralized as monitoring of service enactment refers to nonstop scanning of the state of service by the service requestor agent. As well, we can worry from a scalability issue. Going over, a key limitation of most of these technologies is that they treat exception handling mechanism in a centralized way. In fact, the disadvantages of this trend are: - Centralized exception handling clearly represents a performance bottle neck and a single point of failure. - High communication overhead. And for the most part, the assumption on which all these proposals are based; to run composite services in a decentralized manner, they assume of course that each site is skilled with the required infrastructure to support this execution model, which might been not for all time affordable. To deal with these limitations, and based on [8], we propose a decentralized framework for both Web services orchestration and exception handling. Our framework relies on MAS technology. Indeed, software agents are a powerful high-level abstraction for modeling complex software systems through the interactions among the autonomous agents to achieve specific tasks. They had been used in Grid management, mobile computing environment, network monitoring and fault-tolerance in process automation systems, etc. In this work, we use mobile agents to invoke services, detect occurrence of exceptions and achieve intelligent mechanism to discovery and substitute the failed service by another which has same skills.
3. Background Work 3.1. Decentralized MAS-based Framework for Composite Web Services Orchestration and Exception Handling Based on the philosophy that Web services technology and software agent technology have complementary strengths, and that the arrangement of these two skills might build an interoperability environment provided with advanced capabilities, we have conducted careful research on a decentralized Multi-Agent System-based architecture of orchestration Web services and exception handling [14]. The system is composed of four types of agent: User agent (UsrAg), BPEL Orchestration Engine Agent (BPELOEAg), Web Service Agent (AgWS) and User
Profile Agent (UsrPAg). The following figure (Figure 1.) illustrates the different modules of the system.
it to the UsrPAg in order to bring up to date its base. Further details have been reported in [14].
3.2. Mobile agents technology
Figure 1. Architecture of the MAS-based Framework for Decentralized Orchestration [14] The functional architecture of the system is based on interactions between the agents to execute the BPEL process. The initiator of the conversation is the UsrAg. Upon receipt of a BPEL specification from the user, it proceeds to the organization of BPELOEAg. For this purpose, we use the algorithm proposed in [8] to partition the BPEL code into a set of BPEL subscenarios. The agents’ organization means to assign to each code partition a BPELOEAg. Each BPELOEAg sends to UsrPAg a query for information on user's profile and history of contracts. This information is, then, communicated to each WSAg. Each WSAg performs the service invocation. If the execution succeeds, the result is communicated to the BPELOEAg. Otherwise, WSAg will analyze its eventual causes. If it is a BLE (Business Logic Exception), it is communicated to the BPELOEAg. Else (System Exception), WSAg proceeds to seek out for a set of similar services for the failed WSi. Then, the best service is selected to replace the failed WSi. In contrast to other works, we do not replace the WSi in the BPEL specification. Our idea is based on separating the business logic from invoking services and therefore, the system exception management. Thus, the selected service will be invoked by the same agent transparently to the BPELOEAg. Each BPELOEAg communicates the result of its BPEL sub-scenario execution to the agents that build its network of accointances in the organization. The BPELOEAg which is the root of the organization communicates the final result to the UsrAg which communicates it, in turn, to the user. The user evaluates the result provided by each service, and sends its evaluation to the UsrAg which communicates
A mobile agent is a program that represents a user in a computer network and can migrate autonomously from node to node, to perform some computation on behalf of the user. Applications can inject mobile agents into a network, allowing them to roam the network, either on a predetermined path or one that the agents themselves determine based on dynamically gathered information. Having accomplished their goals, the agents can return to their home site to report their results to the user [11]. The goal is to improve application performance which mobile agents do by letting the application move its functionality dynamically between machines. Mobile agents offer a uniform approach to handling code and data in a distributed system [5]. There are at least seven main benefits, or good reasons, to start using mobile agents [4]: • They reduce the network load. • They overcome network latency. • They encapsulate protocols. • They execute asynchronously and autonomously. • They adapt dynamically. • They are naturally heterogeneous. • They are robust and fault-tolerant. Thus, the mobile agent technology has drawn further attention as a new distributed paradigm.
4. Overall Framework
Mobile
Agents-based
Starting from our claim that, without being based on the assumption that each site is skilled to accomplish its sub-process, high level environments providing the support to execute decentralized BPEL processes are needed and detecting, for the best of our knowledge, that there is no unifying approach today allowing to do this in a proper manner, we think that mobile agents are as much as skilled to do this. For that purpose, we extend our previous framework presented in Section 3 by the use of mobile agents WSMAg as alternatives for agents used to invoke Web services (WSAg). Figure 2. depicts the framework architecture extending the one proposed in [14] by supporting mobile agents to execute the invoking activities.
Figure 2. Architecture of the Enhanced MAS-based Framework for Decentralized Orchestration and Exception handling by means of the Mobile Agents Technology
For better readability, the architecture is organized on three layers: (i) the User layer, (ii) the Intermediate layer and (iii) the Web services layer. This architecture gives also a zoom on what a partition could envelop (being based on [8] with our BPELAg support), such that each partition has exactly one fixed node (receive, reply and invoke nodes are designated as fixed nodes) and zero or more portable nodes (all other activities are considered as portable nodes). We walk now layer by layer through the architecture of Figure 2 to illustrate how the whole process execution is applied. Similarly to our previous system, the current proposal is composed of four agent types: User agent (UsrAg), BPEL Orchestration Engine Agent (BPELOEAg), Web Service Mobile Agent (WSMAg)
and User Profile Agent (UsrPAg). Below, we describe separately each entity: User Layer: With it a process or service is started. It is the interface between the user and the system. It encloses the UsrAg which offers to the user all the necessary functionalities so that he specifies his BPEL process P, and turns to him the result of the execution of P. Indeed, it organizes the BPELOEAg agents while being based on the business logic described in P. This organization relies on a process of partitioning of the BPEL scenario into a set of BPEL sub-scenarios. Each sub-process is associated with a BPELOEAg agent. Intermediate Layer: It surrounds the BPELOEAg Organization, the UsrPAg and the WSMAg. The BPELOEAg checks the role of an execution engine of a
BPEL sub-process. In fact, it distributes and monitors the implementation of its BPEL sub-scenario. It associates to each service invocation an agent WSMAg. For each invoke activity, a plug-in is carried out in order to create a mobile agent of service WSMAg. The plug-in allows launching a WSMAg with all the necessary skills and knowledge using a predefined skeleton code. The skills include the discovery of web services (Discovry ()), invoking a service (Invoke ()), exception (system and business logic) handling (CheckException ()) and the substitution of a failed service by another (Selection ()). Knowledge is represented by the user profile, the constraints of QoS and history of contracts with Web services providers. The UsrPAg’s role consists on the user profile base management. It gets the information related to the user as its geographical location and his interests. It also maintains the history of services whose execution fails and those whose execution succeeds. These informations will be used by WSMAg for more secure and reliable discovery and selection of Web services. The WSMAg, the crucial agent in our system, has to invoke the service. Figure 3. introduces modules that make up the internal architecture of a WSMAg (Note that its architecture preserves the same modules as the WSAg in [14]):
measured by WSLA, ii) informations related to providers of the global BPEL process and iii) Constraints of QoS integrated into the BPEL specification. These informations may be associated to services providers, as the number of contracts with the user and a rate of success for each one, the confidence degree associated by the user to the provider, the provider’s geographical location, etc. This information is usually drawn from the history of interactions between the user and the providers. The selected service will be transmitted to the WS invocation module for running. While migrating or execution on a site, if the WSMAg is lost, a clone of it is automatically relaunched by the BPELOEAg.
- WS invocation module: This module is responsible of the service. The result could be: 1. An answer of the successful execution of the invoked service. Then, it will be communicated to the BPELOEAg so that it achieves the whole execution of its BPEL sub- scenario. 2. A System Exception (SE) or a Business Logic Exception (BLE). If this is a system exception, the invoked service parameters will be communicated to the discovery module. Otherwise (BLE), it will be communicated to the BPELOEAg. - Discovery module: If a SE is raised, this module is triggered with the service parameters communicated since the invocation module. It proceeds to generate a list L of the equivalent services to the invoked WSi,, as well as their eventual QoS.
- Selection module: This module is activated on the coming of a message from the discovery module. This message holds the list L. The selection module picks out the best service by ordering L according to the following informations : i) QoS of equivalent services,
Figure 3. WSMAg architecture Web Services Layer: It provides Web Services to be accessed by our framework on the internet.
5. Conclusion In this paper, we introduced our research efforts to address exception handling issues in decentralized orchestration of composite Web services. These issues are critical for generating straight decentralized Web service business processes. We elucidated why the use of mobile agents could be a powerful technique to address the problems of executing BPEL sub-scenarios among a decentralized environment. As a future work, a first prototype implementation is projected to sustain. As well, further research is needed to consolidate the conceptual foundations of this approach.
References [1] A. SUNA, CLAIM et SyMPA : ‘‘Un environnement pour la programmation d'agents intelligents et mobiles’’. Thesis, Université Paris 6 - Pierre et Marie Curie Laboratoire d'Informatique de Paris 6, décembre 2005. [2] C. Dellarocas, and M. Klein.,"A knowledge-based approach for handling exceptions in business processes", Information Technology and Management, vol. 1, no. 2, 2000, pp. 155–169. [3] C. Kareliotis, C. Vassilakis, E. Rouvas, P. Georgiadis, Exception Resolution for BPEL Processes: a Middlewarebased Framework and Performance Evaluation, Proceedings of the tenth International Conference on Information Integration and Web-based Applications & Services (iiWAS2008). [4] D.B. Lange and M. Oshima. “Seven Good Reasons for Mobile Agents”, Communications of the ACM, Vol. 42, No. 3, pp. 88-89, 1999. [5] D. Milojicic. “Trend Wars: Mobile Agent Applications”, IEEE Concurrency, Vol. 7, No. 3, pp. 80-90, 1999. [6] G. B. Chafle, S. Chandra, N. Karnik, V. Mann and M. G. Nanda, Improving Performance of Composite Web Services Over a Wide Area Network. 2007 IEEE Congress on Services (SERVICES 2007).
[7] G. Chafle, S. Chandra, P. Kankar and V. Mann “Handling Faults in Decentralized Orchestration of Composite Web Services”. In Proceedings of the 3rd International Conference on Service Oriented Computing (ICSOC 2005), Amsterdam, Netherlands, December 2005. [8] G. B. Chafle, S. Chandra, V. Mann, and M.G. Nanda, Decentralized orchestration of composite web services. In Proceedings of the 13th international World Wide Web Conference on Alternate Track Papers &Amp; Posters (New York, NY, USA, May 19 - 21, 2004). WWW Alt. '04. ACM, New York, NY, 134-143. [9] J. Yan, Y. Yang, R. Kowalczyk and X. T. Nguyen. “A Service Workflow Management Framework Based on Peerto-Peer and Agent Technologies”. Proceedings of the Fifth International Conference on Quality Software (QSIC’05). [10] X. Ye, Towards a Reliable Distributed Web Service Execution Engine, IEEE International Conference on Web Services (ICWS'06). [11] W. Qu, H. Shen, and X. Defago. “A Survey of Mobile Agent-Based Fault-Tolerant Technology”. Proceedings of the Sixth International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT’05).
[12] W. Yu, Peer-to-Peer Execution of BPEL Processes, The 19th International Conference on Advanced Information Systems Engineering (CAiSE'07). [13] W. Yu, and J. Yang, “Continuation-Passing Enactment of Distributed Recoverable Workflows”, 22nd Annual ACM Symposium on Applied Computing (SAC 2007), Seoul, Korea, March 11 - 15, 2007. [14] Z. Brahmi, M. Ilahi and M. M. Gammoudi, “Decentralized MAS-based Framework for Orchestration of Composite Web Services and Exception Handling”, 2nd International Conference on Information Systems and Economic Intelligence (SIIE'2009).
