WSCLim

Our testing architecture is spread over four machines. The first machine is reserved for the system under test. In the second machine, our WSCLim tool is installed. The two other machines ensure the load distribution: each acts as a load generator.

• BPEL instances of composed service under test (SUT) :
for each call of the composition under test, a new BPEL instance is created. A BPEL instance is defined by a unique identifier. Each created BPEL instance invokes its own partner services instances by communicating together while exchanging messages.
• The tester (Tester) :
it represents the system under test environment and consists of:
• Web services (WS1, ..., WSm):
these services correspond to simulated partner services of the composition under test. For each call of the composition during load testing, new instances of partner services are created.
• Queues (Queue WS1, ..., Queue WSm):
these entities are simple text files through which partner services and the Tester Core exchange messages.
• The Loader:
it loads the SUT specification described in Timed Automata, WSDL files of the composition under test and WSDL files of each partner service. Moreover, it defines the types of input/output variables of the composition under test besides its partner services.
• The tester Core:
it generates random input messages of the BPEL process under test. It communicates with the different partner services of the composition by sending them the types of input and output messages. In case of partner services which are involved in synchronous communications, the Tester core sends information about their response time to composed service. Finally, it distributes the load between the two BPEL Client. It orders everyone to perform half of concurrent calls to the composition under test, passing the time between each two successive invocations and variable input system.
• The testing log (QueueTester):
it stores the general information of the test (number of calls of the composition under test, the delay between the invocation of BPEL instances, etc.). Also it saves the identifiers of created instances, the invoked services, the received messages from the SUT, the time of their invocations and the verdict corresponding to checking of partner input messages types. This log will be consulted by the Analyzer to verify the functioning of different BPEL instances.
• The test analyzer (Analyzer):
this component is responsible for offline analysis of the test log QueueTester. It generates a final test report.
• Load generators (BPEL Client):
these entities meet the order of the Tester Core by performing concurrent invocations of the service within the parameters received (input variable of the composition under test, number of calls of the composition under test and the delay between the invocation of BPEL instances).

1. The Tester core calls the “Loader” to load Timed Automata, WSDL file of the composed service under test and WSDL files of the different partner services.
2. From these files, the “Loader” determines the types of input/output variables of the composite service as well as those of partner services. It also defines synchronous communications. In addition, it sends this information to the Tester core.
3. After receiving these data by the “Loader”, the Tester core sets information of the test in “QueueTester”.
4. The tester sends for each partner service the corresponding information about the types of input/output messages. In case of synchronous communications, it sends the maximum tolerated time for answering the composition under test to partner service which is involved in this communication.
5. The Tester core divides the simulated load between both “BPEL Client” and calls each by communicating the number of BPEL process concurrent calls (threadsNumber) and the delay between each two successive invocations (delay).
6. Then, each “BPEL Client” invokes the composite service (threadsNumber) times each (delay) seconds.
7. The composite service BPEL instances (BPEL1, BPEL2,..., BPELn) are executed simultaneously. Each instance of the composite service invokes its own instances of partner services. At each call of one of these services, it records a trace in logs indicating the identifier of the BPEL instance that has invoked, the time of its invocation and its input parameters.
8. Each instance of the partner service determines from its own queue, the types of its input and output variables and checks the types of messages that it received from the BPEL composition.
9. Each instance of the invoked partner service sets in “QueueTester”, the ID of the BPEL process instance which is responsible of its invocation, the information that it received and the result of input message types checking.
10. Referring to the type of the output variable in its queue, the partner service instance generates randomly a response and sends it to the SUT.
11. After running the test, the analyzer consults the “Loader” in order to obtain a list of path(s) that the BPEL process may cross (according to the specification).
12. At the end of test, the test analyzer examines the stored information in “QueueTester” in order to generate a final report containing test verdicts of each invoked BPEL instance.

• Application (implantation)
Functional errors are coding errors in the BPEL composition and result in non-compliance with the specification. In our context, we consider three possible errors in the application:
• Incorrect message type:
the composite Web service communicate whith its partner services by exchanging messages. In such a case, we verify the types of the variables appearing in the messages exchanged between the BPEL process and its partner services. Information about the required variable types is described in the WSDL files of each partner service. Also, we verify the type of the variable appearing in the final message exchanged between the BPEL process and its invoker. Information about the required variable type is described in the WSDL files of the BPEL process.
• Non specified behavior:
this error means that an unspecified behavior is added (resp. is omitted) in a branch of the composite service resulting in the production of non-treatment required (resp. by the absence of expected features). This type of problem may occur in a conditional branch (time constraints set by the “pick” activity or logical condition defined by the “switch” activity). In fact, the load can influence the variation of time response of a service partner and the choice of the followed branch.
• Erroneous delay:
this error may appear at a “pick” activity of the composition under test. It consists of an implementation of a synchronous communication conditioned by a timeout response of a partner service different from that specified in the timed automata.
• Test environment
A Web service composition is a flow of interactions between a central service (composed service) and its partner services. During this interacraction, problems with partner services and / or application servers can be observed. We consider that these problems are due to the test environment. We distinguish two types of errors:
• Problem of connection to a partner service:
the BPEL process can not invoke a service partner which usually stops its execution. In fact, the availability of a Web service is influenced by the load, by the state of the server on which it is deployed, etc.
• Problem of getting response from a partner service:
the BPEL process does not receive a response from an invoked partner service.
• SUT node
• Delay in treatment of a partner service response:
a partner service sends its response to the composition under test, in a synchronous communication, before the maximum delay specified but the composition concerned follows the onAlarm branch. This situation can be explained by the fact that concurrent BPEL instances share machine resources such as CPU, which causes sometimes a delay in treatment of some instances.