Description of WSCCT

  1. Overview
    2.
  2. Considered constraints to test
    3.
    1. Considered functional constraints
      2.
      1. Testing the interaction with partner services
        2.
      2. Testing the types of variables in the messages exchanged between the BPEL process and its partner services
      3. Testing the type of the final response sent by the BPEL to its customer
        4.
      4. Examples of case studies
        5.
    2. Considered temporal constraints
      3.
      1. Conformance testing with respect to the network timeout
        2.
      2. Conformance testing with respect to temporal constraint of synchronous communications
        3.
  3. WSCCT Architecture
    4.
  4. Online conformance testing procedure
    5.
    1. Steps of online conformance testing
      2.
    2. Communication between the components of the architecture
      3.
  5. Specification exploration
    6.
  1. Overview
    2.

    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.

    Overview of WSCCT
    The required inputs for online conformance testing are:
    - 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.
  2. Considered constraints to test
    3.  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.
    1. Considered functional constraints
      2.  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.
      1. Testing the interaction with partner services
        2.  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).
      2. Testing the types of variables in the messages exchanged between the BPEL process and its partner services
        3.  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.
      3. Testing the type of the final response sent by the BPEL to its customer
        4.  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.
      4. Examples of case studies
        5.
      Specification (TA)
      SUT (BPEL)
      Test result
      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.
      An extract of the wsdl file of the partner service WS1
      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”).
       Top of Page
    2. Considered temporal constraints
      3.  In the following, we present the two types of temporal constraints considered in our proposed tool.
      1. Conformance testing with respect to the network timeout
        2.  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.
        Example of the first considered temporal constraint
        As shown in the above figure, “delay” represents the waiting time of the response of the partner service SW1. This time must be less than “tmax”, else the implementation of the BPEL process is not considered in accordance with the characteristics of the network.
      2. Conformance testing with respect to temporal constraint of synchronous communications
        3.  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.
        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.
        Specification
        Implementation
        Synchronous communication between BPEL and its partner service WS1
  3. WSCCT Architecture
    4.  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.
    Online conformance testing architecture
    As shown in the above figure, we present an architecture that describes the test environment. This architecture consists of two essential parts:
    • 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.
     Top of Page
  4. Online conformance testing procedure
    5.
    1. Steps of online conformance testing
      2.  Now, we describe the different steps to perform online conformance testing as shown in the above figure.
      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.
    2. Communication between the components of the architecture
      3.  As we have said before, simulated partner services and the WSCCT core component exchange information via queues which are implemented as Web services.
      Communication between WSCCT components
      In order to facilitate getting and setting information from theses queues, we use proxies. We suppose here that the SUT sends ‘”input” to the partner service PS1, PS1 will send the information to WSCCT core component in order to check it. After checking the correctness of “input”, WSCCT will generate “output” and send it to the PS1. In reality this process is not as easy as one thinks. So we explain in the following how does it work.
      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).
  5. Specification exploration
    6.  In our project, we used Timed Automata to model BPEL processes. In this model, a state may be followed by one or more transitions. The next figure illustrates various possible cases that we consider in our test tool, knowing that there are other cases not yet covered.
    Case 1
    Case 2
    Case 3
    Case 4
    Considered specifications in WSCCT tool

    - 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”).

 Top of Page

© Afef Jmal Maâlej - ReDCAD
Last Updated: April 2012.