Cloud PASTE (Cloud PASsive TEsting) |
Contact : Sebastien salva (sebastien.salva@u-clermont1.fr http://sebastien.salva.free.fr) Tien-Dung Cao (dung.cao@ttu.edu.vn) Patrice Laurençot(laurenco@isima.fr)
Short Description :
Cloud PASTE is a tool for the passive testing of Web service compositions in PaaS platforms. At the moment, we provide a version of the tool for Google AppEngine (GAE) only. This passive tester takes a specification described with ioSTSs expressing the functional behaviours of the composition and tests its implementation deployed in GAE.
This passive tester is based upon the notion of transparent proxy for testing. Classical tools for monitoring/passive testing cannot be used with Clouds since the Cloud architecture restricts the access and prevent from installing a classical test architecture (sniffer based tool etc.). So, we derive a model called proxy-tester for testing.
A proxy-tester corresponds to a passive intermediary between the partners of one composition which must observe any behavioural action (messages or quiescence). To act as an intermediary between partners, a proxy-tester must exhibit different behaviours: to receive client requests or to forward received messages to the composition, it must behave as in the specification. It must also collect, by means of input actions, the observable messages (output actions) and quiescence produced by the Web services of the composition. This can be expressed with a mirror specification (inputs are replaced with outputs and vice-versa). While receiving and observing messages, we propose that it also recognises the incorrect actions to detect failures.
The tool architecture is given below:
The tool is composed of an entry point which aims to route messages observed from composition instance to the right proxy-tester instance which tests only one composition instance. The entry point is divided into two distinct parts, client and server. The client part aims to receive messages produced by the composition under test. This part is implemented as a Filter Servlet and is deployed in the PaaS environment. It forwards directly any received message to the correct partner and to the entry point server part for testing. At the moment, this separation is mandatory because the proxy-tester instances cannot be executed inside the PaaS environment and must be run in an external server. Indeed, the satisfiability of guards is checked by Hampi ( Hampi site ) and it requires libraries which are not available in Google AppEngine. This is why the entry point server part, which routes each message to the right proxy-tester instance, is also deployed in the same external server. The two entry point parts are interconnected by means of HTTP connections (this is the only available solution).
With this architecture, any kind of message exchanged between partners can be observed. If Web services belonging to the composition are deployed in several different Google AppEngine projects, messages can still be collected by deploying the same entry point client part in each project.
Some screens:
We also provide a Web Service composition example, which is depicted in the following figures. For this composition, we also provide a mocked client which performs 20 requests
The resulting proxy-tester is depicted below:
Download here ! version 0.1
Download here ! Composition example
The next figure shows the latency measurements obtained with Google AppEngine and Windows Azure with the execution of clients performing 10 successive requests. Pragmatically, the measured latency does not bring issue since it is not greatly affected by the use of the passive tester.
