[IEEE 2006 Second IEEE International Symposium on Service-Oriented System Engineering (SOSE'06) - Shanghai, China (2006.10.25-2006.10.25)] 2006 Second IEEE International Symposium

A Tuple-Space-Based Coordination Architecture for Test Agents in the MAST Framework

Dezheng Xu, Xiaoying Bai, Guilan Dai Department of Computer Science and Technology, Tsinghua University, China [email protected], [email protected], [email protected]

Abstract

Service-Oriented Architecture (SOA) is becoming the mainstream of distributed system integration. Trustworthiness is critical for cross-domain service interaction, and testing is necessary to build the trust among the different parties involved in SOA. MAST, a Multi-Agent-based Service Testing framework, was proposed for testing service-based applications in our previous work. This paper further explores the agent coordination issues in the MAST framework to address the challenge of effective agent communication and interaction. A hybrid coordination architecture is presented which combines data-driven and control-driven models based on the reactive tuple space technique. Different tuple spaces are introduced to facilitate data sharing and asynchronous coordination among test agents. A subscription mechanism is introduced to associate programmable reactions to the events occurred and state changes on the tuple space. The mobile agent technique is also introduced to implement the test agents, which are created on line carrying the tasks, and migrate to the host computers to execute various tasks. A prototype system is designed and implemented to illustrate the proposed approach. Keywords: Service-Oriented Architecture, Testing, Agent, Coordination 1. Introduction

To achieve business agility and IT flexibility, Service-Oriented Architecture (SOA) is becoming the mainstream of distributed system integration, where software components called services are designed to support interoperable machine-to-machine interaction over a network. Trustworthiness is critical for cross-domain service interaction. Testing is necessary to build the trust among the different parties involved in

SOA including service provider, service consumer and service broker [24].

To counter the challenges of dynamic and coordinative service-oriented testing, a MAST (Multi-Agent-based Service Testing) framework was proposed using the intelligent agent techniques [1]. In MAST, different types of agents are designed to support dynamic generation, scheduling, execution and monitoring of test tasks. Test agents, including Coordinator and Runner, are created on-line and organized in different groups. MAST defines the basic process and mechanism to generate, organize, coordinate, and monitor test agents. However, Agent coordination is a key issue in a Multi-Agent System. MAST requires an effective mechanism to manage agent communication and interaction, supporting a task-solving process with the goal of satisfying system objectives.

Some researchers tried to apply agent technique to testing distributed systems [2][3][4][5][12][13][14]. They share a similar architecture composed of management components and test execution components. They take a control-driven coordination model which requires synchronization and mutual knowledge among test components. With the growing of service-oriented computing, due to the observation of the similarities between agents and services, some research has been devoted to apply agents to SOA such as such as service discovery, selection, choreography and orchestration [15][16][17][18][19][20][21][22] [23]. Particularly, Tsai discusses testing services with distributed agents [10].

This paper proposes a coordination architecture based on the reactive tuple space technique to facilitate dynamic task assignment, agent creation and destruction, agent communication, agent distribution and mobility, and the synchronization and distribution of collaborative test actions. Tuple space defines a shared memory mechanism among agents by which data are structured organized, described by tuples and retrieved by pattern matching. Adding reactivity to the

Proceedings of the Second IEEE InternationalSymposium on Service-Oriented System Engineering (SOSE'06)0-7695-2726-4/06 $20.00 © 2006

tuple space means the space can have its own state and react to specific agent actions. In this way, MAST takes a hybrid approach which combines model-driven and data-driven coordination models.

In this research, two tupe spaces are defined in MAST to manage the coordination channels. Through the task tuple space, the test Coordinator dynamically allocates test tasks to different types of test agents according to the process defined in the scheduler. Through the result tuple space, the test Runners communicate the execution results with test Coordinator and Analyzers. A subscription mechanism is introduced to associate programmable reactions to the events occurred and state changes on the tuple space.

Compared with related works, the proposed approach has following characteristics: (1) asynchronous coordination without mutual knowledge among test agents; (2) dynamic agent creation and task allocation; (3) dynamic distribute agent deployment supported by agent mobility; and (4) system extensibility supported by the subscription mechanism and tuple space reactivity.

The paper is organized as follows. Section 2 briefly introduces the MAST coordination architecture. Section 3 presents MAST coordination model based on reactive tuple space. Section 4 describes the dynamic test task allocation. Section 5 discusses the dynamic test runner deployment and distributed test execution. Section 6 details the system implementation. Section 7 summarizes the paper. 2. MAST Coordination Architecture

Based on Tsai’s previous work， we propose a Multi-Agent-based framework MAST to facilitate testing WS in a coordinated and distributed environment. In MAST, the major testing process is decomposed into three parallel and iterative phases: (1) test script generation to define the test cases and test scenarios; (2) test scheduling to create and allocate the test plan to agent groups; and (3) test run to exercise the test scripts, monitor execution status, and collect results.

Figure 1. MAST Coordination Architecture Overview

Figure 1 gives an overview of the coordination architecture. Test agents are classified into different types including Master, Coordinator, Runner and Analyzer. At the local main host, the test Master organizes the test tasks hierarchically into test plans, dynamically creates test group and allocates test plans to each test group. Each group is composed of a set of Runners coordinated by Coordinator. The Coordinator extracts the tasks from the test plan, dispatches the tasks to the Runners and coordinates the execution sequence of the tasks according to the Scheduler associated with each test plan. Test Runners are a set of mobile agents. They take the tasks and migrate to the

destination host according to the configuration defined with each task. After executing the tasks, Runners will return to the main host carrying the execution result and send the results to the Analyzer and Coordinator. 3. MAST Coordination Model Based on Reactive Tuple Space 3.1. Reactive Tuple Space

Basically, there are two types of coordination models for mobile agents [7]. In control-driven coordination model, the coordination media basically


handle the dependencies between the agents, with concern for state changes and events occurring instead of the data exchanged. While data-driven coordination model, mostly based on a shared data space, is better suit when some possibly unknown and autonomous agents have to cooperate. Reactive tuple space presents a hybrid coordination model that combines the cleanness and elegance of data-driven models with the flexibility and power of control-driven ones [6].

In a tuple space approach, the "space" is a shared persistent memory in which clients may read, write, and take objects. The "tuple" is a set of attributes, such as (Name = “Hello World”, Type = “Example”). The clients selectively choose objects from the space by template matching through tuples.

Reactivity means specific reactions within space. The space can monitor the access events and state of the agents, and trigger the execution of a reaction. Reactions can access and change the content of space, and affect other agents within the coordination group. Therefore, the space is not only a repository but also a channel with its own states and reactions that handle more complex coordination activities. Programmable reactivity can also dynamically interacts with agents [9]. Adding reactivity to tuple space enables the implementation of specific coordination policies for interactions between agents.

In MAST, we define two kinds of reactive tuple space, as shown in Figure 1. The task tuple space facilitates the Coordinator to dynamically assign tasks to the Runners. The result tuple space communicates test results among Runners, Coordinator and Analyzers. Once the Coordinator accepts a test plan from the Master, it puts test tasks into the test task tuple space. Runners in the agent group wait in a queue of the space using a simple round-robin approach. The space detects the event of new task deposition and reactively notifies the Runner available in the queue. The Runner chooses its tasks out of the space template matching, such as (RunnerType = “WSTestRunner”, TaskType = “WSOperationTest”, Priority = “Urgent”). It then carries the task to the destination host and executes the test scripts contained in the task on the service under test (SUT). After the test execution, it moves back to the main host, sets the state of test task to “finished” and writes results to the result tuple space. The result tuple space reactively informs the Coordinator and the Analyzer waiting in the queue the availability of newly arrived results. Test Analyzer takes the result out and evaluates service quality and reliability. 3.2. MAST Subscription Mechanism

This research defines a subscription mechanism to implement tuple space reactivity, which associates programmable reactions to the events occurred and state changed on the tuple space.

As shown in Figure 2, each tuple space maintains its own state and a list of the subscriptions requests. The space can provide different services such as notification to the agents, either by itself or by requesting from other agents. Agents can subscribe for specific services from the space. The space monitors the events triggered by agents’ access, changes its state and provides services to subscribers based on its state changes.

Figure 2 MAST Subscription Mechanism

MAST supports two types of subscription: (1) an agent subscribes itself for specific services to certain event or space state change, which means the tuple space provides services by itself; (2) an agent subscribes its services to the space, which means the tuple space acts as a service registry eventually.

MAST also defines different triggering events, such as (1) an agent deposits a specific tuple into the space; (2) an agent deposits a specific type of tuple into the space; (3) an agent takes a specific tuple out of the space; (4) an agent takes a specific type of tuple out of the space; (5) timeout; and so on.

An example scenario is as follows. The Coordinator subscribes its service “cerate Runner” to the task tuple space, which will be trigger by the event “task timeout”. Each task maintains a timer in order to avoid that it stays in the space for a long time and no suitable agent takes it. Once the Coordinator drops task into the space, the timer begins to work. The space monitors the status of the task. It will request the Coordinator to create a new Runner if a timeout event occurs.

Services will keep agents up-to-date on everything new on service providers, both the tuple space itself and the provider agents. Agents will get all the latest


“news” for the service testing process, the state of the coordination group and service providers.

The subscription mechanism improves flexibility and extensibility of system architecture. It enables flexible incorporation of new services, new agent types, new events and new interactions among the agents. 4. Dynamic Test Task Allocation

The Coordinator dynamically allocates test tasks to the Runners through the task tuple space. As shown in Figure 1, test elements are organized hierarchically into a test plan tree. A test plan describes a series testing steps that a test agent group needs to accomplish. Each test plan contains a set of test suites and each test suites contains a set of test tasks.

The key of the Coordinator is to manage the execution sequence of test tasks. Scheduler is defined and associated with test plan and test suite to describe the logic between the test elements in its sub-tree.

Figure 3. An Example Test Plan

Figure 3 gives an example of test plan denoted in XML, in which

The test plan, Plan1, is associated to a concurrency scheduler so that suite1 and task2 should be executed concurrently by different test Runners;

Suite1 has a sequential scheduler. Hence the execution sequence of its sub tasks is task1 suite2 suite4.

Suite2 has a conditioned scheduler. Hence, it will selectively execute task3 or suite3, depending on

the execution result of task1. If the return value equals parameter1, task3 should be executed. Otherwise, suite3 should be exercised.

Suite3 has a sequential scheduler. Hence the execution sequence of its sub tasks is task4 task5; and

Suite4 has a concurrency scheduler, which means task6 and task7 should be executed concurrently by different test Runners.

The Coordinator parses the test plan description into test elements and deposits them to the task tuple space in sequence according to the logic defined by the associated scheduler. Each task is defined with a status such as “created”, “allocated”, “under execution”, “finished”, “pending”, and “timeout”. The agents change the state of the task when an operation is performed on it, such as the Coordinator creates the task and deposits it to the space or the Runner picks up the task to execute remotely. The space monitors the task state changes and triggers the corresponding reactions. For example, when a task if marked “finished’ by a Runner, the space will notify the Coordinator to deposit a new task. The Coordinator asks for the Scheduler.next() to get the next task, put it to the space with the state “created”.

Taking the example in Figure 3, the agents will behave as follows: Step 1. Coordinator checks plan1’s immediate

children suite1 and task2. Task2 is put into task space directly.

Step 2. Suite1 is decomposed further due to the concurrency execution request of suite4. According to the sequential scheduler, task1 is put into task space.

Step 3. Runner selects task1 by template matching, takes it out and runs the test case in its task item.

Step 4. After execution, Runner sets state of task1 as “finished” and returns the test result into the test result tuple space.

Step 5. Test Analyzer takes the result from the result space and Coordinator is informed.

Step 6. Conditioned scheduler of suite2 checks the test result of task1, compares its return value to parameter2 and chooses suite3 as the next element.

Step 7. Task4 and task5 share configuration1. The whole suite3 is put into task space.

Step 8. Runner takes suite3 out and executes task4 and task5 sequentially.

Step 9. After execution, Runner sets states of task4 and task5 as “finished” and returns their test results into the test result tuple space.

Step 10. Test Analyzer takes the results from the result space and Coordinator is informed.


Step 11. Since suite4 is associated with a concurrency scheduler, Coordinator puts task6 and task7 into task space. Decomposition finishes. This employs the task pattern for mobile agent that

is concerned with the breakdown of tasks and how these tasks are delegated to one or more agents. In general, tasks may be dynamically allocated to general-purpose agents. Furthermore, a given task can be accomplished either by a single agent or by multiple agents working in parallel and cooperating to accomplish it. This promotes reusability of test tasks, dynamic allocation of test tasks to agents, and even composition of test tasks. 5. Dynamic Runner Deployment and Distributed Test Execution

To simulate the usage scenario and test more effectively, a Coordinator may interact multiple Runners dispersed in a LAN or WAN area. To reduce the network traffic, the mobile agent technique is used to implement Runners so that a lot of agent interactions can be carried locally. Mobile agents are autonomous computer programs that can act in the interest of an entity, migrate between different network locations, execute tasks locally, and continue migration.

As shown in Figure 4, mobile test Runners in MAST can (1) get tasks from the task tuple space; (2) mobile to the destination host; (3) retrieve test case from the task, (4) run the test asynchronous and distributed on the service under test; (5) carry the test result and migrate back; and (6) deposit result to the result tuple space. The Runner will then waits for the next task again in the queue of task tuple space.

Each task is associated with a configuration which defines (1) the number of Runners that should be deployed; (2) the type of Runners; (3) the URI of destination host where the Runner is supposed to perform the distributed test tasks; and (4) the name of destination agent container. Follow the configuration, the Coordinator may organize multiple tasks to be performed in sequence or in parallel by multiple Runners, and the Runners migrate between the local control host and destination execution host.

The more complex test plan adopts a workflow to organize multiple test tasks to be performed in sequence or in parallel by multiple agents. The test plan encapsulates the task flow, which is then hidden from the runner. The runner merely provides the mobility capabilities needed to perform test tasks at specific destinations.

Figure 4. Basic Flow of Dynamic Runner Deployment and Distributed Test Execution

6. System Implementation

MAST is implemented on the open source platform JADE (Java Agent Development Framework) [11], which is a FIPA (Foundation for Intelligent Physical Agents) compliant, Java-based agent development toolkit. Distributed running agents in JADE active containers cooperate in the service testing process. The

main container is located in the local host, where test Master and Coordinators handle centralized dynamic test task assignment by test task tuple space, and Analyzers deal with result collection and evaluation by test result tuple space. Other containers in the same JADE platform are located in different destination hosts. Test Runner mobile agents execute distributed


service test tasks, migrating among JADE containers. A simplified class diagram is shown in Figure 5.

The actual job a JADE agent has to do is typically carried out within behaviors. A behavior represents a task that an agent can carry out and is implemented as an object of a behavior class.

Figure 5. MAST Class Diagram

Master, Coordinator, Runner and Analyzer inherit standard MASTAgent class. MASTAgent should provide the following functions:

Handling the basic operation to tuple space for writing (AddToSpaceBehaviour) and retrieving (ReadFromSpaceBehaviour).

Generating subscriptions for certain events or services to tuple space (Subscription Behaviour).

Receiving certain notifications or messages from tuple space (ReceiveNotification Behaviour).

Master has the following functions: Managing the GUI and interaction between

MAST and users by onGuiEvent(). Managing the interfaces for other agent

systems. Handling creation of Coordinator and

assigning test plan to Coordinator. Collecting test result reports from Analyzer and

messages from different monitors. Coordinator performs dynamic test task assignment

and coordination: Mapping the test plan description to basic test

element objects (LoadTestPlanBehaviour). Getting next element in test tree by invoking

Scheduler.next() and ignoring the detail control logic (TaskAssignmentBehaviour).

Creating new Runners and Analyzers using the factory pattern (AgentCreationBehaviour).

Managing the coordination group (CoordinationGroupManagementBehaviour).

Runner provides the following functions to execute a distributed service testing:

Handling agent mobility by beforeMove() and afterMove().

Retrieving the test case from Task object and running it (TestExecutionBehaviour). The pre-processing, execution and post-processing detail, such as binding service and sending SOAP messages, is handled by the test case itself in a JUnit-like way.

Analyzer provides the following functions: Collecting the test results from result tuple

space. Verifying the test results and informs

Coordinator and Master. The tuple space we employ in MAST is a

lightweight one and implemented in a Linda-like [8] way. It provides basic operations like out(),in() and rd(). We add reactivity into it using a subscription mechanism implemented by Subscription class and Notification class. A triggering Event list is maintained in space. 7. Summary

This paper presents the coordination architecture in MAST for enabling active coordination without mutual knowledge among agents and temporal restriction, based on reactive tuple space. A prototype system is currently under construction to illustrate the proposed approach showing how Coordinator manages test agents interaction in dynamic test task assignment, Runner deployment and distributed services testing execution based on the reactive tuple spaces Reference [1]. X Bai, G Dai, D Xu, WT Tsai, “A Multi-Agent

Based Framework for Collaborative Testing on Web Services”, Proceedings of the 2nd International Workshop on Collaborative Computing, Integration, and Assurance, WCCIA 2006, Page(s): 205-210.

[2]. Q Huo, H Zhu, S Greenwood, UK London, “A multi-agent software engineering environment for testing Web-based applications”, Proceedings of Computer Software and Applications Conference, COMPSAC 2003, Page(s): 210-215.

[3]. D. Kung, “An agent-based framework for testing Web applications”, Proceedings of the 28th Annual International Computer Software and Applications Conference, COMPSAC 2004, vol.2, Page(s): 174-177.

[4]. Y Qi, D Kung, E Wong, “An Agent-Based Testing Approach for Web Applications”, Proceedings of Computer Software and Applications Conference, COMPSAC 2005, Volume 2, Page(s): 45-50.


[5]. AW Ulrich, P Zimmerer, G Chrobok-Diening, “Test Architectures for Testing Distributed Systems”, Proceeding of Quality Week 1999.

[6]. G Cabri, L Leonardi, F Zambonelli, “Reactive Tuple Spaces for Mobile Agent Coordination”, Proceedings of the 2nd International Workshop on Mobile Agents, Volume 1477/1998, Page(s): 237.

[7]. P Ciancarini, A Omicini, F Zambonelli, “Multiagent System Engineering: the Coordination Viewpoint”, In Intelligent Agents VI (ATAL99), volume 1767 of LNAI, Page(s): 250-259.

[8]. D Gelernter, “Generative communication in Linda”, ACM Transactions on Programming Languages and Systems, 7(1):80–112, January 1985.

[9]. G Cabri, L Leonardi, F Zambonelli., “MARS: A programmable coordination architecture for mobile agents”, Internet Computing, 4(4): 26-35, 2000.

[10]. WT Tsai, R Paul, L Yu, A Saimi, Z Cao, “Scenario-Based Web Service Testing with Distributed Agents,” IEICE Transaction on Information and System, 2003, Vol. E86-D, No. 10, Page(s): 2130-2144.

[11]. JADE (Java Agent Development Framework), http://jade.tilab.com.

[12]. M Benattou, JM Bruel, “Active Objects for Coordination in Distributed Testing”, Proceedings of Object-Oriented Information Systems : 8th International Conference, OOIS 2002, Page(s): 348.

[13]. J Choi, B Choi, “Test Agent System”, International Journal of Software Engineering and Knowledge Engineering, Vol. 12, No. 3 (2002) 269-290.

[14]. H Zhu, “Cooperative agent approach to quality assurance and testing Web software”, Proceedings of the 28th Annual International, 2004 vol.2, Page(s): 110-113.

[15]. P Buhler, JM Vidal, "Semantic Web Services as Agent Behaviors", Agentcities: Challenges in Open Agent Environments, B. Burg et al., eds., Springer-Verlag, 2003, Page(s): 25-31.

[16]. I Dickinson, M Wooldridge, “Agents are not (just) Web Services: Considering BDI Agents and Web Services”, SOCABE 2005, http://www.hpl.hp.com/techreports/2005/HPL-2005-123.pdf.

[17]. N Gibbins, S Harris, N Shadbolt, “Agent-based Semantic Web Services”, Proceedings 12-th International World Wide Web Conference, Page(s): 710-717.

[18]. CL Huang, CC Lo, Y Li, KM Chao, JY Chung, Y Huang, “Service Discovery through Multi-Agent Consensus”,Proceedings of the Workshop on Service Oriented System Engineering (SOSE 2005), Page(s): 37-44.

[19]. M Lyell, L Rosen, M Casagni-Simkins, D Norris, “On Software Agents and Web Services: Usage and Design Concepts and Issues”, the 1st International Workshop on Web Services and Agent-based Engineering, 2003, http://www.agentus.com/WSABE2003/program/lyell.pdf

[20]. Z Maamar, SK Mostefaoui, H Yahyaoui, “Towards an Agent-based and Context-oriented Approach for Web Services Composition”, IEEE Transactions on Knowledge and Data Engineering, Vol. 17, No. 5, MAY 2005, Page(s): 686-697.

[21]. N Milanovic, M Malek, “Verifying Correctness of Web Services Composition”, Proceedings of the 11th Infofest, Budva, Montenegro, 2004.

[22]. D Richards, S van Splunter, FMT Brazier, M Sabou, “Composing web services using an agent factory”, Proceedings of the 1st International Workshop on Web Services and Agent Based Engineering, 2003.

[23]. K Sycara, M Paolucci, J Soudry, “Dynamic discovery and coordination of agent-based semantic web services”, IEEE Internet Computing, 8(3): 66-73, May 2001.

[24]. X Bai, Z Cao and Y Chen. “Design of a Trustworthy Service Broker and Dependence-Based Progressive Group Testing”, International Journal of High Performance Computing and Networking.


Documents

[IEEE 2006 Second IEEE International Symposium on Service-Oriented System Engineering (SOSE'06) - Shanghai, China (2006.10.25-2006.10.25)] 2006 Second IEEE International Symposium