Interleaving Web Services Composition and Execution Using Software Agents and Delegation Zakaria Maamar
Quan Z. Sheng and Boualem Benatallah
[email protected]
{qsheng,boualem}@cse.unsw.edu.au
College of Information Systems Zayed University Po Box 19282, Dubai, U.A.E
ABSTRACT The paper presents a software agent-based approach that supports the interleaving of Web services composition and execution. A Web service is an accessible application that other applications and humans as well can automatically discover and invoke. Interleaving stands for carrying out the composition and execution of Web services in parallel. This allows handling the execution context of the Web services. Dynamic information that change overtime can feature such a context and require thus, a certain form of adjustment of the Web services. In this paper, the deployment operations of Web services composition and execution are entrusted to software agents that can delegate their work to each other if needed.
Keywords Web services, software agents, interleaving, delegation, reliability.
1.
INTRODUCTION
Web services are emerging as a major technology for achieving automated interactions between distributed and heterogeneous applications [11]. Various technologies constitute the backbone of this achievement: WSDL, UDDI, and SOAP [4]. These technologies aim at supporting the definition of services1 , their advertisement, and their binding for triggering purposes. The advantages of Web services have already been demonstrated and highlight their capacity to be composed into high-level business processes [1]. Composite services denote these business processes and consist of several component services whether composite services or primitive Web services. It is argued that composition via service interconnection allows more sophisticated services and applications to be hierarchically constructed from primitive ones. Several projects exist in the field of Web services [1]. In all these projects, the development, provisioning, and execution of composite services is a sequential multi-stage process. First, the appropriate component services are identified, then connected, and finally executed. This way of preparing composite services has several shortcomings. In 1
Service and Web service are used interchangeably.
School of Computer Science & Engineering The University of New South Wales Sydney NSW 2052, Australia
a dynamic environment where changes are frequent, a composite service cannot handle a change that occurs while it is under execution. In fact, it happens that a change has not been considered during the development stage of the composite service. The composite service becomes obsolete calling therefore for a new development. Computing resources (CPUs, memory stores, and bandwidth) are good examples of dynamic information. These resources cannot be granted during the whole computation process of the component services. A disk with an initial capacity of X MBytes when empty, cannot be considered having the same capacity when it is half full. This change of capacity affects the execution of a service, assuming that this disk has been selected because its full capacity meets the execution requirements of the service. In order to handle the challenges of dynamic environments, one of the solutions consists of interleaving Web services composition and execution. The idea is to ensure that the composition and execution are performed step-by-step which allows to consider the context in which the services evolve. In this paper, we present our software agent-based approach that implements such a solution. Our approach takes advantage of the research done in Distributed Artificial Intelligence (DAI) [3] in general and the planning field in particular [9]. In a dynamic environment, it is recommended to decompose the planning process into several steps, each step to take care of a portion of the plan that is under development. When a portion of the plan is finished, it is immediately submitted for execution. When the execution of that portion is completed, the planning of the remaining portions resumes again and so on, until all the portions are completely handled. From this description, it is shown that the planning process is interrupted so the execution process can be given a room to start. In our proposed agent-based approach, the composition of services is not interrupted at all, but continues in parallel with the execution of services. This is achieved through delegation as it will be discussed throughout this paper. Another scenario that shows the relevancy of interleaving planning and execution concerns the lack of information. It happens that the planning process is suspended because a certain information is missing. A solution suggests the execution of the portion of the plan that is ready while waiting for the missing information [10]. Section 2 briefly defines software agents and Web services. Section 3 explains the approach that is adopted for the agentification of an environment of Web services. Section 4 explains the approach of Web services composition
Host 1 Agent 1
(a) Remote invocation
Web service Invocation Host 2 Host 1 Agent 2 Web service
Agent 1
(b) Migration
Host 2 Agent 1
Local invocation
Agent 2 Web service
Figure 1: Web service invocation strategy: remote vs. local and execution. Interleaving composition and execution as well as the reliability of execution are also presented in Section 4. Section 5 concludes the paper and overviews our future work. It is made clear at that level that the mechanisms for discovering the component services of a composite service, while important, do not fall within the scope of this paper. UDDI repositories for instance can be used for implementing these mechanisms.
2.
BACKGROUND
2.1 Software Agent An SA is a piece of software that acts autonomously to undertake tasks on behalf of users [6]. The design of many SAs is based on the approach that the user only needs to specify a high-level goal instead of issuing explicit instructions, leaving the how and when decisions to the agent. An SA exhibits a number of features that make it different from other traditional components [6] including autonomy, goalorientation, collaboration, flexibility, self-starting, temporal continuity, character, communication, adaptation, and mobility.
2.2 Web Services A Web service is an accessible application that other applications and humans as well, can automatically discover and invoke. An application is a Web service if it is [2]: (i) independent as much as possible from specific platforms and computing paradigms; (ii) developed mainly for interorganizational situations rather than for intra-organizational situations; and (iii) easily composable (i.e., its composition with other Web services does not require the development of complex adapters). In our research, a Web service can be invoked for execution either remotely or locally. Fig. 1 illustrates both types of invocation strategy. Besides SOAP on which both strategies can be built on, a local invocation strategy relies on agents that migrate and thus, are enhanced with mobility mechanisms. More details on both strategies are found in [7].
3.
AGENTIFICATION OF WEB SERVICES
For the agentification needs of an environment of Web services, we suggested an agent-based multi-domain architecture (Fig. 2). Domains are spread across the network and administrators manage them. Two types of domain exist: user-domain and provider-domain. We consider the existence of one user-domain (despite the issues of bottleneck or single point of failure that both could be fixed with replication) and several provider-domains. A domain is a cluster of computing hosts on top of which portal of services and software agents are deployed. Two types of agents are considered in the agentification process of an environment of Web services: user-agent and provider-agent. User-agents
act on behalf of users. And, provider-agents act on behalf of providers who manage the Web services constituting the basic components of composite services. Users connect to the portal of composite services from different devices: fixed devices such as desktops and mobile devices such as personal digital assistants. The deployment of a composite service for execution is not affected by the type of device from which it has been launched. The only difference occurs at the communication protocol that connects users to the portal of composite services. For users of fixed devices, HTTP is the protocol. And, for users of mobile devices, WAP is the protocol. In Fig. 2, the user-domain has a service-zone and a workingzone. The service-zone has a dedicated portal from which composite services are developed and deployed. In addition, the service-zone has a pool from which user-agents are created. For their installation, user-agents are initially located in the working-zone of the user-domain. User-agents are mobile and thus, have the capacity to migrate from one domain to another. When a user selects a composite service, a user-agent handles the performance of that composite service and decides which component services will be included (Sec. 4.1) and how these component services will be invoked whether locally or remotely. A provider-domain consists of a working-zone and several portals of Web services. Each portal is reserved to a category of Web services (e.g., travel, education). The working-zones are devised in a way to receive user-agents arriving from the user-domain or from other provider-domains. Within these working zones, installation procedures of user-agents and control procedures of their credentials are performed. Portals of provider-domains are associated with provideragents; they handle the invocation requests that user-agents submit to the services. A user-agent submits a local request to a provider-agent in case both agents reside in the same provider-domain (Fig. 1 (b)). This means that the user-agent has migrated to that provider-domain. The useragent arrives either from the user-domain or from a different provider-domain. In case the user-agent and provider-agent are in separate domains, the user-agent submits a remote request to the provider-agent so, a service can be executed (Fig. 1 (a)).
4. INTERLEAVING WEB SERVICES COMPOSITION & EXECUTION In the rest of this paper, C-service denotes a composite service and P-service denotes a primitive service which is a Web service. Before we present the way interleaving Web services composition and execution using software agents and delegation takes place, we first introduce the approach that supports the composition and execution of Web services.
Fixed devices
User-domain
HT TP
Users
WA
Administrator Service-zone Portal of composite services
Pool of user-agents
P Working-zone
Mobile devices
User-agents Migration
Remote interaction Provider-domain 1
Provider-domain 2 Migration
Working-zone Local interaction
Remote interaction
Portal 11 of Web services
Working-zone
Portal 21 of Web services
Portal 12 of Web services
Administrator
Administrator
Provider-domain 3 Provider-agent
Provider-domain 4 User-agent
Network P: Primitive C: Composite
Figure 2: Agent-based multi-domain architecture
4.1 Composition of Web Services A composite service is expressed as a composition of other services (either composite or Web) using service chart diagrams [8] that leverage statecharts [5]. Encoding the flow of operation invocations as statecharts is especially attractive for several reasons. First, statecharts possess a formal semantic, which is essential for reasoning about composite service specifications. Next, statecharts are becoming a standard process-modeling language as they have been integrated into UML. Finally, statecharts offer a good number of control-flow constructs (e.g., branching, concurrent threads, structured loops). It is made clear at that level that the specification of composite services with service chart diagrams, while important, are not discussed in this paper. Details on this specification are available in [8]. We mainly focus on the three dimensions along which a composition process can be seen: what set of services to use for composition, which service providers’ resources to use, and which instances of each service to use for a particular client session. For a composite service, the selection of its component services is based on two criteria: execution cost and location of computing hosts. A computing host is a resource on top of which Web services can be executed. A computing host is also a member of a cluster of computing hosts. Location of computing hosts criterion aims at gathering in the same cluster (i.e., provider-domain) the maximum number of Pservices for execution, favoring local interactions and reducing consequently (i) the number of remote interactions between domains, (ii) the number of migrations of user-agents to domains, and (iii) the number of data exchanges between domains. The identification of the relevant domains and hence, their respective computing hosts is based on what follows. First, the domain of where a service is currently being executed is considered (set A of Fig. 3). By selecting this domain, remote data exchanges between services are avoided. Next, the domain of where the user-agent currently resides is considered (set B of Fig. 3). By selecting this domain, local invocations of services as well as local data exchanges
between services are enabled. If none of the aforementioned cases happens, any domain is considered (set C of Fig. 3).
Definitions A C-service is an ordered set of component P-servicesi = 1, ··· , n . Each P-servicei is offered by several provider-agentsj = 1, ··· , m . For a user-agent, the outcomes of composition are (i) associate a P-service p.si with a provider-agent pro.agtj and (ii) define the strategy of invoking the P-service p.si whether remotely or locally. Let us assume a C-service CS of p P-services, CS = {p.s1 , p.s2 , · · · , p.sp }. The definition of the C-service CS establishes the set {< p.s1 , pro.agt1 , type >, < Spp.s2 , pro.agt2 , type >, · · · , < p.sp , pro.agtp , type >} where i=1 p.si = CS and for each < p.si , pro.agti , type >(i∈[1,p]) the P-service p.si is provided by the provider-agent pro.agti and invoked according to remote or local type. The number of provider-agents that contribute to a C-service CS provisioning is not necessarily equal to the number of Pservices that are involved. Certain provider-agents may contribute to a C-service with more that one P-service (e.g., < p.s1 , pro.agt1 , type > and < p.s2 , pro.agt1 , type >). Given a P-service p.si , its execution cost is decomposed into two parts: • Remote.Cost(p.si ) includes (i) the cost of establishing a communication link between the domain of the useragent and the domain of the provider-agent of the Pservice p.si , plus (ii) the cost of performing the Pservice p.si , plus (iii) the cost of returning the results from the domain of the provider-agent to the domain of the user-agent. • Local.Cost(p.si ) includes (i) the cost of transferring the user-agent from the domain in which it is currently located to the domain of the provider-agent of the Pservice p.si , plus (ii) the cost of performing the Pservice p.si .
The execution cost Cost(CS) of a C-service CS is the sum of Ppthe costs of all the P-services: Cost(CS) = i=1 (Remote.Cost(p.si ) ⊕ Local.Cost(p.si )). The execution cost that is considered for a P-service p.si is either a remote cost or a local cost.
Based on Equ. (2), < p.s1 , pro.agt2 , remote > is set. The user-agent has decided first to select pro.agt2 to provide p.s1 and second to invoke p.s1 remotely. This means that the user-agent and pro.agt2 will be in two different domains during the invocation process.
Preparation
Phase 2.2
The preparation of Web services for composition is decomposed into two phases. Phase 1 consists of searching for the provider-agents that have the P-services. Because provideragents can have P-services in common, Phase 2 consists of selecting a particular provider-agent based on the criteria of execution cost and location of computing hosts.
After Phase 2.1 is finished, the user-agent starts working on the remaining P-servicesi = 2, ··· , p also one at a time. Now, the two selection criteria are simultaneously considered. However, the location criterion is privileged to the execution cost criterion because of the advantages that were previously cited. Due to the location criterion, the provideragent that will be associated with a P-service p.si (i∈[2,p]) depends on the provider-agent that has been selected to offer the predecessor P-service p.si−1 . The user-agent proceeds according to the algorithm of Fig. 3 (in the algorithm, it is presumed that < p.si−1 , pro.agti−1 , local|remote > is known). When the user-agent finishes a P-service p.si , the provider-agent and invocation strategy of that P-service are identified. The purpose of the algorithm is to produce a short list of provider-agents with whom the user-agent will be interacting about their services. This short list ranks the domains in which the provider-agents and user-agent respectively reside (A, B, and C sets).
Phase 1: Search for provider-agents As stated in the introduction, the mechanisms that support the search for provider-agents are not discussed. It is assumed that the provider-agents that offer the component P-service p.si are known to the user-agent that is responsible of the execution of the C-service CS. For each P-service p.si , a set of potential provider-agents is identified. This is similar to < p.si , P RO.AGTi , type > where P RO.AGTi = {pro.agt1 , · · · , pro.agtn } is the list of provideragents that have the P-service p.si in common. In the previous example of CS = {p.s1 , p.s2 , · · · , p.sp }, the following cases can be listed < p.s1 , P RO.AGT1 , type >: P RO.AGT1 = {pro.agt1 , pro.agt2 , pro.agt3 }. < p.s2 , P RO.AGT2 , type >: P RO.AGT2 = {pro.agt2 , pro.agt4 }.
Phase 2: Definition of < p.si , pro.agti, type > Because provider-agents can have P-services in common (e.g., P RO.AGT1 = {pro.agt1 , pro.agt2 , pro.agt3 }), the association of a P-service with a specific provider-agent has to be completed. In addition, because of the location criterion the P-services are treated in a serial way (i.e., one at a time). The definition of < p.si , pro.agti, type > is conducted as follows.
Phase 2.1 Initially, the work starts with the P-service p.si (i=1) of the C-service CS. At this level, only execution cost criterion is considered (location criterion does not hold). From each provider-agent that offers the P-service p.si (i=1) , the useragent receives information on the execution cost for both types of invocation strategy: local and remote cost (Equ. 1). pro.agt1 : Remote.Cost(p.s1i ), Local.Cost(p.s1i ) .. U ser − agent : p.si (i=1) . pro.agtn : Remote.Cost(p.sn i ), Local.Cost(p.sn i ) (1) For each offer, the user-agent selects the minimum cost between the invocation types min(Remote.Cost(p.sn i ), Local.Cost(p.sn i )). Then, the user-agent selects for the Pservice p.si (i=1) the minimum among all the offers of the provider-agents. For example, U ser − agent : p.si (i=1) 7→ pro.agt2 : Remote.Cost(p.s2i ) (2)
4.2 Execution of Composite Services When all the component P-services of a C-service are identified, the user-agent starts invoking them through their provider-agents. For illustration purposes, the following example of C-service CS = {< p.s1 , pro.agt1 , local >, < p.s2 , pro.agt2 , local >, < p.s3 , pro.agt3 , remote >} is considered. Initially, the user-agent resides in the user-domain, pro.agt1 and pro.agt2 reside in provider − domain1 , and pro.agt3 resides in provider − domain3 . Since p.s1 will be locally executed, the user-agent migrates from the userdomain to provider − domain1 . After it finishes the execution of p.s1 , the user-agent locally starts executing p.s2 . Since pro.agt2 is within the same domain as pro.agt1 , this shows an implementation of the location criterion. This also shows that the transfer of data from p.s1 to p.s2 in case they are interdependent, is locally done which avoids dealing with network connection failures. Finally, from provider − domain1 the user-agent submits a remote request to pro.agt3 so p.s3 can be executed. The transfer of data from p.s2 to p.s3 in case they are interdependent, is done remotely which means the importance of being aware of network connection failures. It should be noted that the concurrent execution of P-services is possible and calls for specific mechanisms to implement user-agents (e.g., multithreading).
4.3 Interleaving Composition & Execution From Sec. 4.1 and 4.2, it is shown that the deployment of a composite service is sequential and demands from the user-agent (i) to process all the offers of the provider-agents about the Web services, (ii) to constitute the composite service, and (iii) at the end to execute the composite service. It would be more appropriate if the composition and execution of services could be carried out concurrently, (i.e., interleaving composition and execution). To this purpose, the user-agent has to delegate a part of its work (either composition or execution) to a third party. To this purpose,
for each < p.si , P RO.AGTi , type >, i = 2, · · · , p begin | A ← φ //set of provider-agents that are in the same domain as pro.agt i−1 | B ← φ //set of provider-agents that are in the same domain as user-agent | C ← φ //set of provider-agents that are in other domains | for (j = 1; j , < p.s2 , ?pro.agt, ?type >}. First of all, the delegate-agent starts the preparation of p.s1 for execution. Based on the offers it receives from provideragents, the delegate-agent establishes for p.s1 what follows (Sec. 4.1): local execution in provider −domain1 of pro.agt1 (< p.s1 , pro.agt1 , local >). Therefore, the delegate-agent asks the user-agent to migrate to provider − domain1 . Before it moves, the user-agent resides in the user-domain. While the user-agent is getting ready for migration, the delegate-agent starts the preparation of p.s2 . After performing all the necessary operations, the delegate-agent establishes for p.s2 what follows: local execution in provider − domain2 of pro.agt2 (< p.s2 , pro.agt2 , remote >). The details on p.s2 are transferred to the user-agent that is now running in provider − domain1 . After the user-agent finishes the execution of p.s1 , it moves to provider − domain2 to locally interact with pro.agt2 . Delegation is important in interleaving the composition
and execution of services. Alone, the user-agent cannot handle the interleaving. This is due to several reasons. While the user-agent is receiving offers from provider-agents and working on the composition of services, it is at the same time executing other services. This execution may require from the user-agent to migrate to domains. This is challenging for provider-agents to keep track of the user-agent so they continue submitting their offers to the user-agent. Furthermore, even if the offers of provider-agents are sent to a common repository for storing purposes, the user-agent has to browse the repository remotely which is inconvenient due to potential networking problems. These two reasons illustrate the importance of having a delegate-agent working on behalf of the user-agent.
4.4 Reliability of Execution The reliability of a Web service is defined as the probability that a request submitted to a Web service is correctly responded within the maximum expended time frame [12]. This time frame is mostly published as part of the Web service description. Reliability is a technical measure that depends on hardware and/or software configuration of Web services and on network connections between requestors and service providers. The reliability value can be computed from historical data about past invocations using for example the number of times that a Web service has been successfully delivered within the maximum expected time frame, with regard to the total number of invocations. Because reliability deals with service execution failures, backup approaches are deemed appropriate. A Web service cannot be executed for multiple reasons: network connection problems, service disconnected for maintenance, service overloaded, just to cite a few. In the following, we present the way reliability is integrated into the operating of the multi-domain architecture of Fig. 2. Interleaving Web services composition and execution has called for two types of agents: user-agent and delegateagent. Initially, the delegate-agent associates a Web service with a provider-agent and submits that information to the user-agent that must be running either in the userdomain or in one of the multiple provider-domains. The se-
User-domain Delegate-agent
User-agent
(1) Interaction (3') details submission
Provider-domain 2 Working-zone User-agent
(2) Migration
Provider-domain 1 (4) Migration
(5) Interaction
Provider-agent 2(p.s 2)
Working-zone User-agent (3) Interaction
Provider-agent 1(p.s 1)
Figure 4: Interleaving service composition and execution lected provider-agent is part of a pool of potential provideragents (P RO.AGTi ) that have a Web service in common (Equ. 2). Before the delegate-agent starts working on the next component services, it stores the information about the pool of provider-agents (for example the ”x” best ranked provider-agents from sets A, B, and C of P RO.AGTi , x
