Dynamic Reconfigurable Testing of Service-Oriented Architecture

Dynamic Reconfigurable Testing of Service-Oriented Architecture Xiaoying Bai+, Dezheng Xu+, Guilan Dai* Department of Computer Science and Technology, Tsinghua University, China [email protected], [email protected] *Research Institute of Information Technology, Tsinghua University, China [email protected] Wei-Tek Tsai, Yinong Chen Computer Science & Engineering Department, Arizona State University, USA {wtsai, yinong}@asu.edu

Abstract SOA (Service-Oriented Architecture) presents unique requirements and challenges for testing. Dynamic reconfiguration in SOA software means that testing need to be adaptive to the changes of the service-oriented applications at runtime. This paper presents a ConfigTest approach to enable the online change of test organization, test scheduling, test deployment, test case binding, and service binding. ConfigTest is based on our previous research on the MAST (Multi-Agents-based Service Testing) framework. It extends MAST with a new test broker architecture, configuration management and event-based subscription/notification mechanism. The test broker decouples test case definition from its implementation and usage. It also decouples the testing system from the services under test. With the configuration management, ConfigTest allows the test agents to bind dynamically to each other and build up their collaborations at runtime. The event mechanism enables that a change in one test artifact can be notified to all the others which subscribe their interests to the change event. This paper presents and analyzes the collaboration diagrams of various testing reconfiguration scenarios and illustrates the ConfigTest approach with an example of service-based book ordering system.

1. Introduction SOA (Service-Oriented Architecture) defines a collaboration framework for service provision, registration, publication, discovery, composition, and governance. The development of services and service-oriented applications is in an open environment based on standard protocols and can be done by independent parties/vendors. Each party can be involved in the whole service lifecycle, and hence, trust is critical to the acceptance and application of SOA.

Testing is an important method to ensure service trustworthiness. SOA presents unique testing requirements that cannot be addressed by traditional testing techniques. First, services are collaboratively created, deployed, discovered, used, composed, and maintained by different vendors that may not know each other. Trustworthiness is built upon public accumulated credit, rather than mutual acknowledgement in traditional software development controlled within an organization. Second, services dynamically and automatically establish their collaboration and cooperation. Hence, testing must also be achieved dynamically and automatically, rather than in the traditional human-intensive approach. Thirdly, services can be reconfigured and recomposed at runtime. Reconfiguration means that a service specification can be rebound to different service implementations. Recomposition means that services may re-orchestrated following a new process model. Dynamic reconfiguration occurs when the system cannot be stopped and has to be changed at runtime. Service reconfiguration brings a challenge to SOA testing. Testing should also be adaptive to the dynamic changes at runtime and to continuously verify the correctness, performance, and reliability of the integrated system to ensure a reliable and smooth transition. This paper proposes a ConfigTest mechanism to support testing dynamic reconfiguration. This research is based on our previous research on the MAST (Multi-Agents-based Service Testing) framework which supports runtime testing with collaborative agents in a coordinated and distributed environment [2] [20]. In MAST, different types of agents are designed to support dynamic generation, scheduling, execution, and monitoring of test tasks. Test agents, including TestCoordinator and TestRunner, are created on-line and organized in different groups. MAST defines the basic process and mechanism to generate, organize, coordinate, and monitor test agents. A hybrid

31st Annual International Computer Software and Applications Conference(COMPSAC 2007) 0-7695-2870-8/07 $25.00 © 2007

coordination architecture has also been proposed which combines data-driven and control-driven models based on the reactive tuple-space technique. ConfigTest extends MAST framework and supports dynamic test reconfiguration from three aspects: the test broker architecture, configuration management, and the event-based change subscription / notification mechanism. In the generic SOA framework, the service broker, such as UDDI in Web Services, provides an index of available services and the mapping from a service specification to its implementation so that the service implementation is transparent to the service users who can bind to the services discovered from the broker at runtime. Similarly, the test broker separates test case specification from test case implementation. It also maintains the links between a test case and the target service specification. In this way, the testing system can be flexible adaptive to the changes from both of the test case and SUT (Service Under Test) by dynamic binding. ConfigTest separates testing into different abstraction levels such as specification, coordination and execution. Test components at each level are loosely coupled. Each test component maintains its local configuration that can be updated at runtime so that the components can build up collaboration dynamically. As a result, ConfigTest allows agile test reconfiguration to deal with various change scenarios such as reorganization of test artifacts, reassignment of test tasks, and redeployment of test agents. This paper illustrates the ConfigTest approach with various testing reconfiguration scenarios and an example servicebased book ordering system The paper is structured as follows. Section 2 reviews the related research. Section 3 introduces the MAST framework and analyzes the requirements for MAST test reconfiguration. Section 4 presents the new ConfigTest mechanism in detail. Finally, section 5 summarizes and concludes the paper.

2. Related Research 2.1 Web Services Testing In a 2002 article, Bloomberg and others pointed out that the success of Web Services (WS) is depended on its capability to resolve the testing issues [3]. Since then, some research has been conducted to WS testing. However, most of the current studies have been focused on the formal verification of WS specifications. For examples, Shin proposed to use the automation-based model checker SPIN [13]; Howard et al. applied FSP (Finite State Process) notation [8]; X. Yi and K. J. Kochut introduced a CP-nets model, an extended Petri-net model and argued that Petri-net was

more expressive than FSM (Finite State Machine) , especially for specifying conversational protocols [21]; and Srini and Sheila adopted DAML-S ontology to describe web service semantics and translated it into a Petri-net specification [14]. Some other researchers also tried to verify WS communication at the network level. For example, Looker and Xu applied fault injection technique to test SOAP and discussed a measurement-based assessment technique [9]. Tsai et al. proposed CV&V (collaborative verification and validation) and the WebStrar framework for testing services and service-based applications [17][18]. They analyzed the challenges of dynamic and just-in-time testing of SOA and proposed the CV&V model which is characterized by the collaboration and cooperation of all the parties involved in SOA to perform WS testing to ensure trustworthy computing. In our previous work, we also investigated the extension of UDDI with testing support [1][19]. Compared with the existing works on WS testing, the proposed approach has following characteristics: 1. It is not limited to particular WS specifications. In stead, it provides a generic testing framework that can be bound to different protocols. 2. In most of the research, testing components are instrumented inside the application architecture. This paper proposes an independent testing framework that is loosely coupled with SUT, yet it can be synchronized with SUT and interoperate with SUT based on the standards used. 3. ConfigTest proposes an independent test broker architecture which extends current generic Web Services architecture and can support CV&V. 4. ConfigTest provides a flexible configurationbased CV&V mechanism that can be adaptive to changes dynamically at runtime.

2.2 Software Reconfiguration Dynamic reconfiguration is a vital issue in distributed systems and has been widely addressed in the area of software architecture. For examples, Oreizy and Taylor discussed the beneficial role of software architecture styles and connectors in facilitating runtime reconfiguration [16]; Gomaa and Hussein introduced four patterns in reconfigurable product line including master-salve pattern, centralized pattern, client/server pattern, and decentralized control pattern [9]. Some research also observed the issues in specific application domain. For examples, Kogekar et al. discussed software reconfiguration in sensor networks. In [11], they proposed a formal model of software components, their alternative implementation and their interactions. In [10], they discussed the formal constraints on QoS parameters that are measured at runtime.


This paper discusses the dynamic reconfiguration issue in the testing system which has never been addressed before. The key issue is that testing reconfiguration is driven by the changes from the system under test. Therefore, the reconfiguration of test system must be in synchronization with the system under test.

3. MAST Reconfiguration Requirements 3.1 MAST Framework Briefing

Figure 1 The MAST framework As shown in Figure 1, MAST decomposes the major testing process into three parallel and iterative phases: test generation, test planning and test execution. Multiple agent types are defined to accomplish various tasks. TestGenerator generates test cases based on the service specification such as WSDL, and OWL-S. TestMaster organizes test plans, creates test groups and allocates tests to agent groups. A test group is dedicated to a test suite, which is composed of a TestCorrdinator for coordinating agent execution and communication, and a set of TestRunners for running the test in a distributed environment. TestMaster organizes tests in test planes. A test plan is composed of a set of test suites, and a test suite corresponds to a SUT test. The SUT may be an atomic service or a composite service. For composite service, a test suite defines a process of test tasks, each of which is associated to a test case and tests an operation of the service process. TestCorrdinator assigns test cases to TestRunners and deploys the TestRunners to the host computers. Based on the test strategy, TestCorrdinator identifies the hosts and decides the number of TestRunners allocated to each host. MAST also defines 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 activities.

3.2 Test Reconfiguration Requirements Testing is reconfigured to accommodate changes from two aspects: changes of the SUT and testing strategy changes. We identified following typical changes of the service-based applications: Case 1: change the service interface operations, for example, a new WSDL specification is published. Case 2: change the service binding, for example, a new service is provided with the same interface but different address, therefore, the tModel in the UDDI is bound to another BindingTemplate. Case 3: change the service process, for example, new steps are added, or delete a step, or reorganize the service execution sequence. To test the changes, following reconfigurable capabilities are necessary in MAST. Reconfigure test cases. When the service interface changes or a better test case is generated or provided, MAST should be able to replace the old test case with a new one. Reconfigure test suite. Test suites are used for organizing and scheduling test tasks. The schedule of test tasks follows the process flow of the SUT. Therefore, the change of the service process will result in the rescheduling of the test suites. Reconfigure test agents. When the service binding is changes, MAST should be able to re-target the test runner to the new service address. In addition, when the test strategy changes, MAST should be able to change the number of agents and the host computer, and re-allocate TestRunners.

4. ConfigTest: Dynamic Reconfigurable Service Testing To address the reconfiguration requirements of testing service-based applications, the paper proposes the ConfigTest approach which defines the test broker architecture, configuration management and the event-based runtime reconfiguration mechanism. ConfigTest enables flexible test configuration and dynamic binding among loosely coupled test components.

4.1 The Test Broker Architecture Test broker extends current generic SOA framework with an independent test registry. As shown in Figure 2, the test broker defines a loosely coupled architecture among different parties involved in service testing including test providers, testers, evaluators, etc.. It provides a set of interfaces so that 1) the test providers can submit the test specification; 2) the testers can lookup test cases, checkout the executable test scripts, bind to SUT, and submit test results; 3) the evaluator can check test results, evaluate and rank services; and 4)


service users can find test cases for its own testing, check service test results and evaluation results for selecting services.

Figure 3 shows the data structure of the test broker architecture. TestEntity represents the provider of the test cases. TestCase represents the published test cases which could be a specification or an executable script. The TestModel represents the technical interface of a test case. The TestBinding represents the binding from TestModel specification to the implementation of the test case. ServiceLinking specifies the corresponding service tModel of the test case.

Figure 2. The Test Broker Architecture

Figure 3 The test broker data structure Figure 4 shows the MAST ConfigTest dynamic reconfiguration process based on the test broker architecture. 1) Any test provider can submit test cases through a standard interface. A test provider could be either a service broker, a service user or an independent tester. 2) MAST TestGenerator can also automatically generate test cases and submit them to the test broker for publishing and retrieving. 3) MAST TestMaster creates test plans, organizes and schedules test suites and test tasks. It refers to the TestModel of the test case and associates it with the test tasks. 4) MAST TestCoordinator looks up the test cases based on the TestModel and gets the test case implementation through BindingTemplate. 5) MAST TestRunner looks up the SUT through the ServiceLinking, links to the service tModel, finds and binds to the SUT. With the test broker, ConfigTest can support various types of testing reconfiguration, such as z A test case specification can be rebound to different executable test scripts; z A test case can be re-linked to different service specifications; z A testing task can be re-associated to different test cases; and z Test runners can be rebound to different services.

Figure 4 Dynamic configuration based on the test broker architecture

4.2 Configuration Management Configuration is specified and associated to test specifications. For each test suite, a TestSchedule is defined to specify the process of its test tasks. Each task is associated with a TestCaseBind to specify its binding to the test case, and a TestRunConfig to specify the deployment plan of TestRunners. Following gives the definition of the test artifacts with configurations. Definition 1. A test plan is defined as a set of test suites, that is, TPlan := , where 1˅ id is the unique identifier of a test plan;


2˅ tsi is a test suite. Definition 2. A test suite is defined as a scheduled set of test tasks. It can also recursively include other defined test suites. That is, TSuite := , where 1˅ id is the unique identifier of a test suite. 2˅ tschi is a test schedule which defines the execution process such as concurrency, sequence, branch, etc. It can be the process of a set of tasks, of other test suites. It can also be defined recursively with other schedules. TSchedule := , where op is the process logic, tschi is another schedule, tsi denotes a test suite, and tti denotes a test tasks. Definition 2. A test task is defined by the associated test case and the configuration of the test runners for executing the task, that is, TTask := , where 1˅ tc is the binding to a test case. 2˅ config is the binding to an execution configuration. Definition 4. An agent configuration defines the deployment of the agents, that is, AConfig :=, where 1˅ atype defines the type an agent such as TestRunner; 2˅ host specifies the host computer to remotely deploy the test agent; and 3˅ num specifies the number of agents deployed. Each configuration is encoded in a XML-based document. Following gives an example test suite. The test suite tSuite1 consists of a sequence execution of a test task tTask1 and another test suit tSuite2. tTask1 is bound to a test case tCase1 and a configuration tConfig1.

Following shows tConfig1, the example agent configuration specification. With the configuration, five test runners are deployed for the execution of tTask1 carrying the test case tCase1. Two of the runners are deployed to host computer Host1 and three of them to Host2.

The configuration specifications are loaded during MAST initiation and maintained throughout the testing process. Whenever collaboration is needed, MAST will check the configuration, obtain the linkage, and bind to the collaborator dynamically. In this way, it improves the system’s adaptability to the following changes: z A test plans can be reorganized with different suites and tasks; z A test suite can be rescheduled with different test process; z A test task can be reassigned to different test agents; and z Test agents can be redeployed to different host computers with different distribution profile.

4.3 Event-Based Change Subscription and Notification Dynamic reconfiguration requires that a change is notified to all the affected artifacts, the test components react to the changes and adjust their behavior accordingly at runtime. ConfigTest supports an event-based approach for the test components to subscribe their interests to the target configured items, and for the change to be propagated to its listeners. For example, the TestCoordinator registers interests to TestScheculer and TestCaseBinding of the test suite. Once the test suite changes its process, the TestScheculer will trigger the update event with the suite id and notifies the TestCoordinator that exercises the suite. Similarly, when the test case is replaced with a new one, TestCaseBinding will trigger an update event with the task id and notifies the TestCoordinator to reallocate test cases to the TestRunners executing the test case.

4.4 Runtime Reconfiguration Scenarios The section illustrates the approach with four typical scenarios: update test case, change the SUT, change the agent deployment plan, and change the test process. Scenarios #1: Update a test case


5˅ The runner binds to the service provider and tests the service with the test case. Scenarios #3: Change the agent deployment plan

Figure 5 Example scenario: update a test case Figure 5 shows the collaboration diagram to update a test case: 1˅ The test generator submits a new test case with its testModel to the test broker. 2˅ The test broker notifies the updates to all test suites that bind to the test cases and register their interests to the changes. 3˅ The test suite checks its sub tasks that are bound to the test case, and updates the binding information. 4˅ The test suite notifies all the test coordinators that use the test case. 5˅ The test coordinator asks the test broker to get the new test case. 6˅ The test coordinator updates its test case. 7˅ The test coordinator checks all test runners that use the test case and assign them with the new one. 8˅ The test runner accepts and exercises the new test cases. Scenarios #2: Change the SUT

Figure 6 Example scenario: change the SUT Figure 6 shows the diagram of changing the SUT 1˅ The service provider publishes to the UDDI center to update the BindingTemplate to a new URI and port. 2˅ The test coordinator deploys the test runner carrying the test case to the host computer. 3˅ The test runner checks the test broker to get the ServiceLinking information with the test case testModel and gets the service tModel. 4˅ The test runner looks up the UDDI center to get the service BindingTemplate with tModel.

Figure 7 Example scenario: change the deployment Figure 7 shows the collaboration diagram to change the agent deployment plan: 1˅ The test master sends the new configuration plan to the test suite. 2˅ The test suite updates its configuration binding. 3˅ The test suite notifies the test coordinator the updates of the configuration. 4˅ The test coordinator checks the test suite configuration binding to get the new configuration specification. 5˅ The test coordinator compares and decides the redeployment plan. 6˅ The test coordinator redeploys the agents. The key to the process is the step 5 by which the test coordinator will decide that: 1˅ If a host computer in the old configuration is not in new configuration, then remove all the agents at that host. 2˅ Otherwise, if the number of agents in the host computer is different from the new configuration, than adjust the number of agents according to the new plan. Suppose Cold and Cnew denotes the old and new configuration respectively. Hold={hi} and Hnew={hi} denotes the old and new set of host computers respectively. Num (h, c) denotes the number of agents at a host h in the configuration c. Following gives the algorithm of the redeployment. For any hi H old , if hi H new , then If Num(hi , H old ) Num(hi , H new ) , then Deploy more agents to hi of the number ( Num(hi , H new ) Num(hi , H old )) ; Else if Num( hi , H old ) ! Num(hi , H new ) , then Destroy the agents on hi of the number ( Num(hi , H old ) Num( hi , H new )) Else // hi H new Destroy all the agents on hi


The test coordinator controls the execution process of the test runners through the task tuple-pace. When the test suite notifies the coordinator of the changes, it will check the suites and schedule to get the updates, then deposits and allocates tasks according to the new schedule.

Scenarios #4: Change the test process

4.5 An Illustrative Example Figure 8 Example scenario: change the test process Figure 8 shows the collaboration diagram to change the test process: 1˅ The test master informs the test suite to update the execution process of its tasks. 2˅ The test suite tracks its updates and also lets the schedules track their internal changes. 3˅ The test suite notifies the test coordinator of the changes of the process. 4˅ The test coordinator checks the test suite updates. 5˅ The test coordinator checks the schedule updates. 6˅ The test coordinator deposits the tasks to the tuple-space according to the new schedule. The key to the mechanism is that each test artifact – test suite and test schedules – maintains its own status and tracks the updates. Suppose SCH(ts)= {schi} is the set of test schedules defined for test suite ts. ts records all the updates of SCH such as adding, removing, or changing the order of the schedules. Each schi SCH also records the updates of its component tasks, suites or schedules, such as changing the operation, and adding/removing/replacing/changing the order of the tasks. 7HVW %RRNVWRUH WHVWB SURFHVV2UGHU WHVWB SODFH&KDUJH

Figure 9 shows an example illustrating the book ordering service in a Bookstore application. The Bookstore offers the service to its client by composing three component services: processOrder, placeCharge, and orderBook. The processOrder is provided by the Bookstore itself while the other two are integrated from other vendors. The placeCharge is provided by the Bank and the orderBook is provided by the Publisher. A test is developed to test the component services and the composite process. As shown in the left grey box, three test steps are defined: test_processOrder, test_placeCharge, and test_orderBook. The test process is just the simulation of the book ordering process. 7HVW %RRNVWRUH

%RRNVWRUH

WHVWB SURFHVV2UGHU

%DQN

SURFHVV2UGHU

WHVWB SODFH&KDUJH

SODFH&KDUJH

WHVWB RUGHU%RRN

RUGHU%RRN

Figure 9 A book ordering example

%RRNVWRUH

6HFXULW\

%DQN

SURFHVV2UGHU SODFH&KDUJH

WHVWB RUGHU%RRN

RUGHU%RRN

WHVWB VHQG%RRN

VHQG%RRN

Figure 10 Example change scenarios Figure 10 shows some typical change scenarios of the services-based applications. To accommodate the service changes, the test process is changed example. In change ķ, a Security vendor is added accordingly as marked in blue in the figure. which serves as a proxy to the original Bank service. For change ķ, the test_placeCharge needs to retarget The Security supports the same placeCharge interface operations. Hence, the Bookstore just rebinds the the testing on Security rather than Bank. This change is placeOrder service from Bank to Security. In change the type of scenario #2 in section 3.4, that is, the service under test is rebound. In response to the change, ĸ, a new step is incorporated to trigger the sendBook the test runner gets the new binding information from service provided by a Parcel. the test broker at runtime, and rebinds to the Security All these changes will result in the rebinding and service. reassembling, that is the reconfiguration, of the


For change ĸ,a new test step test_sendBook is added to test the Parcel sendBook service. This change is the type of scenario #4 in section 3.4, that is, the test process in changed. In response to the change, the test suite changes its schedule with one more step for test_ sendBook; the test coordinator deposits one more task to task tuple-space, and allocates one more runner to execute the task.

[6]

S-W. Cheng et al, “Software Architecture Based Adaptation for Pervasive Systems,” Int. Conference on Architecture of Computing Systems and Trends in Network and Pervasive Computing, 2002.

[7]

H. Foster, S. Uchitel, J. Magee, and J. Kramer (2003), “Model-based verification of web service compositions”, In Proc. ASE'03.

[8]

H. Foster, S. Uchitel, J. Magee, and J. Kramer, “Model-based verification of web service compositions”, In Proc. ASE, 2003.

[9]

H. Gomaa and M. Hussein, “Software Reconfiguration Patterns for Dynamic Evolution of Software Architectures”, In Proc. IEEE WICSA, 2004.

5. Conclusion and Future Work The collaborative and dynamic features of SOA challenge traditional testing techniques with unique testing requirements. This paper investigates the reconfiguration issues based on our previous research on the MAST framework. Decoupling is a key issue for configurable testing. Runtime change notification and response are key issues to dynamic reconfiguration. ConfigTest proposed in this paper addresses the issues with the loose coupling test broker architecture, flexible configuration specification, and an effective event-based subscription / notification mechanism. ConfigTest can deal with various change scenarios. A prototype system is implemented. Future works include: 1) synchronization with the reconfiguration of the service-based application; 2) improvement to the performance of the configuration management; and 3) scalability to large complex systems for simulation and experiments.

Acknowledgements This research is supported National Science Foundation China (No. 60603035), National High Technology Program 863 (No. 2006AA01Z157), Beijing Natural Science Foundation (No. 4072014), and IBM SUR project under the agreement no. 20063000238.

Reference [1]

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

[2]

X Bai, G Dai, D Xu, WT Tsai, “A Multi-Agent Based Framework for Collaborative Testing on Web Services”, Proc. of WCCIA 2006, Page(s): 205-210.

[3]

J. Bloomberg, “Web Services Testing: Beyond SOAP”, ZapThink LLC, at http://www.zapthink.com, 2002.

[4]

U. Brinkschulte, E. Schneider, and F. Piciogoaga, “Dynamic Real-time Reconfiguraiton in Distributed Systems: Timing Issues and Solutions“, In Proc. Of IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 2005.

[5]

M. Castaldi et al., “A Lightweitht Infrastructure for Reconfiguring Applications,” In Proc. Of 11th software Configuration Management Workshop, 2003.

[10] S. Kogekar et al. “Constraint-Guided Dynamic Reconfiguration in Sensor Networks”, In Proc. IPSN, 2004, pp. 379-387. [11] S. Kogekar et al, “Dynamic Software Reconfiguration in Sensor Neworks”, In Proc. ICW, 2005. [12] N. Looker and J. Xu, “Assessing the Dependability of SOAP RPC-Based Web Services by Fault Injection”, In Proc. IEEE WORDS’03, 2003. [13] S. Nakajima, “Model-checking verification for reliable web service”, In Proc.OOPSLA'02 Workshop on OOWeb Services, 2002. [14] S. Narayanan and S. Mcllraith, “Simulation, verification and automated composition of web services”, In Proc. WWW, 2002. [15] Y. Kim, E. Kim, J. Kim, E. Song, and I. Ko, “Ontology Based Software Reconfiguration in a Ubiquitous Computing Environment”, In Proc. Of IEEE International Conference on Computer and Information Technology, 2006. [16] P. Oreizy and R. N. Taylor, “On the role of software architectures in runtime system reconfiguration”, In IEE Proc. Software, Vol. 145, No. 5, Oct. 1998, pp. 137-145. [17] 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. [18] W. T. Tsai, Y. Chen, R. Paul, N. Liao and H. Huang, “Cooperative and Group Tesitng in Verification of Dynamic Composite Web Services”, In Proc. IEEE COMPSAC, 2001, pp. 1-4. [19] W. T. Tsai, R. Paul, Z. Cao, L. Yu, A. Saimi, and B. Xiao (2003), "Verification of Web Services Using an Enhanced UDDI Server", Proc. of IEEE WORDS, pp. 131-138. [20] D. Xu, X. Bai, and G. Dai, "A Tuple-Space-Based Coordination Architecture for Test Agenst in the MAST Framework", In Proc. IEEE SOSE, 2006, pp.57-63. [21] X. Yi and K.J. Kochut, “A CP-nets-based Design and Verification Framework for Web Services Composition”, Proceedings of the IEEE International Conference on Web Services, March, 2004.
