- Considered constraints to test
- Considered functional constraints
- Testing the interaction with partner services
- Testing the types of variables in the messages exchanged between the BPEL process and its partner services
- Testing the type of the final response sent by the BPEL to its customer
- Examples of case studies
- Considered temporal constraints
- WSCCT Architecture
- Online conformance testing procedure
- Specification exploration
- Considered constraints to test In our context, conformance testing concerns the functional behaviour of BPEL compositions, and addresses also non-functional properties particularly the necessary time to perform a certain action.
- Considered functional constraints A Web service composition is a flow of interactions between a central service (composed service) and its partner services. During these interactions, messages are exchanged between the composed service and its partners.
- Testing the interaction with partner services In order to test the correctness of these interactions with respect to specification in hand, we verify the control flow (i.e. the sequence of activities execution in the BPEL process). Besides, we check if the right partner service is invoked (in case of invoke activity).
- Testing the types of variables in the messages exchanged between the BPEL process and its partner services 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.
- Testing the type of the final response sent by the BPEL to its customer In such a case, 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 and XSD files of the BPEL process.
- Examples of case studies
- Considered temporal constraints In the following, we present the two types of temporal constraints considered in our proposed tool.
- Conformance testing with respect to the network timeout In fact, in order to avoid the network congestion and the BPEL process long waiting for a message coming from an invoked Web service, we suppose that this waiting time is limited by the maximum latency (or delay) of the network noted tmax. Consequently, the first type of temporal constraint consists in comparing the response time of each partner service with tmax.
- Conformance testing with respect to temporal constraint of synchronous communications The second type concerns the verification of temporal requirements conditioning some synchronous communications between the BPEL process and its partners according to a given specification. In the following, we explain more what does it mean a synchronous communication. First, let us suppose a BPEL process which invokes a partner service. The BPEL process then waits for the partner service operation to be completed, and responded without exceeding a certain delay. After receiving this completion response from the partner service, the BPEL process will continue to carry on its execution flow. We define so a synchronous communication subjected to a temporal constraint between a BPEL process and its partner service.
- WSCCT Architecture Initially, it should be noted that we are interested in this project to perform unit testing of Web service compositions. Thus, the composition is isolated from its partners to be tested as a separate unit. It is required to simulate its partner processes (or services). This is due essentially to the fact that some of these partners are still under development during unit testing phase. In addition, some partner processes are developed and governed by other enterprises. Finally, it is convenient to precise that simulated partner processes are still preferred as they could generate more interaction scenarios with less effort.
WSCCT is a tool for online conformance testing of Web service compositions. It allows checking the compliance between an implementation described in BPEL (Business Process Execution Language) and its specification described in Timed Automata.
- N: test execution number,
- tmax: network timeout,
- SUT (System Under Test): a Web service composition implemented in BPEL. This BPEL process is designed with JDeveloper and deployed on Oracle BPEL Application Server.
- Specification (TA): the Timed Automata specifying the SUT. It is designed using UPPAAL.
As output, WSCCT generates a:
- Test report: containing timed test cases and its corresponding detailed verdicts.
Verdict = PASS: Both specification and implementation invoke WS1 then WS2.
Verdict = FAIL: incorrect invoked partner server. In fact, the SUT has invoked WS1 then WS3, while the specification indicates the invocation of WS2 instead of WS3.
Verdict = FAIL: Type incompatibility. In fact, according to the specification, the input variable of WS1 is of type “integer”, while in the BPEL implementation, WS1 is invoked with an input variable of type “string” (“aaaaa”).
In our work, this kind of synchronous communication is modeled in Timed Automata using timed transitions and in BPEL using pick activity as depicted in the following.
• The composite service (SUT): it corresponds to the current instance of the composition to test. It communicates with its partners (including the client) by exchanging input/output messages.
• The tester: it plays the role of the SUT environment (i.e. its partner services + WSCCT core) and includes:
- The WSCCT core component: generates test cases (sequences of input/output messages and timing delays) and sends/receives input/output messages to/from each partner service. This WSCCT core component implements our online test generation and execution. At the end of test, a final test report is generated for offline verification of the implementation with respect to its specification.
- The test executors (PS1, PSn, BPEL Invoker): these entities correspond to the simulated service partners (including the BPEL Invoker). The role of each PS component is simple. Each one receives a message from SUT and forwards it to the WSCCT core component or it receives a message from the WSCCT core component and sends it to the SUT. All of test executors have the same role, but one corresponding component is created for each partner service because it has a different address (port) and different input/output types.
- The Queues: these entities are web services through which WSCCT core and partner services exchange information. We distinguish two types of queues:
- * Tester’s Queue: stocks the information sent by the SUT to the invoked partner service. Then, the tester consults this queue to check the type of information sent by the SUT compared to what is described in the wsdl file of the invoked partner service.
- * Partner services’ Queues (Queue PS1...Queue PSn): In our architecture, we consider that a web service, after being invoked by the SUT, must return an answer. This response is generated automatically by the tester according to the type described in the wsdl file. Then, it is stored in the queue of the invoked Web service.
- Steps of online conformance testing Now, we describe the different steps to perform online conformance testing as shown in the above figure.
- Communication between the components of the architecture As we have said before, simulated partner services and the WSCCT core component exchange information via queues which are implemented as Web services.
1- The WSCCT core generates an input according to the wsdl and xsd of the SUT and invokes the BPEL invoker.
2- The BPEL invoker uses this generated input to invoke the SUT.
3- The SUT invokes his first partner service (PS1) with “inputPS1”.
4- PS1 sends “inputPS1” and its endpoint “endpointPS1” to queue Tester.
5- The WSCCT detects that there is new information in its queue. It gets “inputPS1”and the endpoint from the queue and checks its correctness with reference to the specification and the wsdl file of the invoked partner service.
6- Once these “inputPS1” and “endpointPS1” are correct, WSCCT core component generates an output “outputPS1” by referring to the WSDL of invoked partner service (PS1) then sends it to queue of PS1.
7- PS1 detects that there is new information in its corresponding queue. It takes the “outputPS1” from its queue.
8- PS1 sends “outputPS1” to the SUT. Then, the SUT continues its operation and the same reasoning is applied to the other partners.
9- At the end, the SUT sends the final response to the client.
10- The WSCCT core component gets this final output from the client and checks its correctness with reference to the wsdl and xsd files of the SUT.
1- The SUT sends “input” to PS1.
2- PS1 calls the “Tester Queue Proxy” and asks him to set “input” in “TesterQueue”.
3- “TesterQueueProxy” invokes the “TesterQueue” and sets “input”.
4- The WSCCT core component calls “TesterQueueProxy” in order to get “input”.
5- “TesterQueueProxy” invokes the “TesterQueue” in order to get “input”.
6- “TesterQueueProxy” sends the information the WSCCT core.
The same process happens when WSCCT generates output and sends it to PS1 using “PS1Queue” and “PS1QueueProxy” (see previous steps 7, 8, 9, 10. 11 and 12).
- For the first situation, a state is followed by a single transition. In this case, we have no choice. Only the transition t is fired.
- For the second case, we have several possible transitions to fire. These transitions are of type "outputAssignmentClockTransition" or "outputTransition". In this case also, the choice of the transition is imposed. Indeed, arriving at the source state of possible transitions, the tester waits information from the invoked partner web service at this point. In particular this service identifies itself to the tester by sending a unique name (or URL). Then the tester seeks, in the list of transitions following the current state, which one corresponds to the invoked partner service. It is the transition to fire.
- The third case illustrates the synchronous communication between BPEL and its partners. The service response to the BPEL partner may be subject to time constraints under which new paths will rise. This case illustrates an example of Timed Automata where the path to choose depends on the response time of the partner service to the message 'm' sent by the BPEL. If this response time is inferior than the duration d, the system continues on its way to a treatment 1, otherwise it follows the path of treatment 2. To simplify finding the possible paths of a specification, we restrict ourselves to the comparison of the response time to a single value. Therefore, transitions from a synchronous transmission of message are binary (i.e. from such state, only two transitions will be born as shown in the above figure case 3: The first transition treats the case of the reception of the invoked service response at the right time (t inferior than d) while the second treats the case of transition timeout).
- The fourth case illustrates "switch with one condition." This case illustrates an example of Timed Automaton where the path you choose depends on the service response partner "output" to the message "m" sent by the BPEL. If output = "val", the system continues on its way to a treatment 1, otherwise it goes the way of treatment 2. A this early stage of development WSCCT, we restrict ourselves to the comparison of the response time to a single value (i.e. from such state, only two transitions will be born as shown in the above figure case 4: The first transition treats the case that the response of the invoked partner service is equal to “val” while the second treats the case of response if the invoked partner service is different to “val”).