How to use WSCCT tool?

  1. Case Study
    2.
  2. Setting the Test Environment
    3.
    1. Preparation of the specification
      1. Design of the Timed Automata
      2. Simulation and verification of the specification
      3. Modification of the specification
      4. Convention
    2. Creation of the test environment
      1. Creation of simple simulated partner services and connecting them to the SUT
      2. Creation of Tester’s Queue
      3. Creation of proxy of tester’s Queue
      4. Creation of partner service’s Queue
      5. Creation of the proxy of partner service’s Queue
      6. Modifying the code of partner service
      7. Creation of BPEL invoker
      8. Creation of classes that call the created proxies
  3. Use of WSCCT Tool
  1. Case Study
    2.

    In this section, we illustrate how to use our proposed WSCCT tool for conformance testing of a HBO-TP (Hospital Blood Ordering for Transfusion Purposes) scenario implemented in BPEL.
    The transfusion of blood or its components (plasma, platelets, etc.) has an important role in modern medicine and surgery. In this context, we show our approach by means of a case study consisting in a hospital ordering blood components for transfusion purposes. We suppose that the required business process (written in BPEL) composes services of: local blood search (LBS), local blood ordering (LBO), hospital maintenance (HM) and unsatisfactory customer (UC). We also assume that the two first partner services (LBS) and (LBO) are connected to a local blood bank which is situated in the involved hospital. In fact, the blood bank is mainly responsible for rapid response to urgent requests for blood components and for selection of suitable blood component for each clinical condition.
    Once a hospital unit (such as emergency, surgery, etc.) sends a request to the HBO-TP process, the (LBS) service is invoked to search for required blood component from the local blood bank. This search is conditioned by a waiting time. Indeed, the process should receive a response from (LBS) within maximum 60 seconds (for example). Otherwise, the process sends a connection problem report to the (HM) service. In case of receiving a blood search response before reaching 60 seconds, obtained search results are analysed. If the conditions related to the needed blood component are satisfied, then the (LBO) service is invoked to order blood from the local blood bank. Otherwise, an unsatisfactory customer report is sent to (UC) service for information about unavailable required blood component. Thus, responsibles are put in charge to answer quickly the hospital unit need for blood. Finally, a detailed reply informing about final results is sent to the concerned hospital unit.

    The HBO-TP process
  2. Setting the Test Environment
    3.  Before starting the test of BPEL composition, you must go through the following steps:
    1. Preparation of the specification
      1. Design of the Timed Automata
        2.  The WSCCT tool user has to design the timed automata using UPPAAL; you can see the tutorial available on UPPAAL website.
        The HBO-TP process modeled in Timed automata using UPPAAL
        Notice 1: In this version of WSCCT, specification types that can be used are those containing simple transition, synchronous communication, switch with one condition and states followed with only output transitions.
        Notice 2: At each invocation of a partner service, you must update the variable “invokedWebService” with the corresponding name of the partner service. This name should be the same than the name used the description of this partner service (we will speak about the description of partner service in the next section).
        Notice3: output is a variable that specifies the output of partner service. We use this output in the case of switch activity.
        Notice 4: In this specification, after the invocation of the partner service LBS, we have a case of synchronous communication between BPEL and its partner LBS. So we have two possible paths : the first consists in treating the case that the invoked partner service answer at the right time (t inferior than 60 in our case), while the second treats the case of transition timeout).
      2. Simulation and verification of the specification
        3.  We use UPPAAL to simulate and verify the correctness of the specification.
      3. Modification of the specification
        4.  1- Let’s take the xml file generated by UPPAAL. You can download it from this link. This description is composed of 3 parts:
        • Declaration: that contains the declaration of the type of each variable and message in the specification.
        • Description templates: which contains the name of the template and the description of locations (or states) and transitions.
        Notice: we call the template of BPEL process as “Template”.
        - Location: is defined by its name and its identifying (id).
        - Transition: is defined by its source, its target and its type.
        • Processes: the active processes.
        For more information, please consult UPPAAL tutorial.
        2- For parsing this xml file using JDOM , you must delete the first comment.
        Comment to delete in the specification
        3- Now, we will create our own declaration. So, in the declaration part we add these information :
        - The clock tag: name of the clock ;
        In our case study we add x;
        - The declaration of “output”: output;
        As has been reported before, output refers to the message sent by the current invoked partner service to the SUT.
        - The BPEL description :
        * The wsdl file description: we indicate the path of wsdl file the BPEL process: the path of the BPEL wsdl file
        * The xsd file description: we indicate the path of the xsd file of the BPEL process: the path of the BPEL xsd file
        - The partner descriptions: for each partner service, we indicate its name, and the path of its wsdl file: the path of the wsdl file of the partner service.
        The next figure shows the declaration of HBO-TP specification after modification.
        Declaration of HBO-TP specification after modification
      4. Convention
        5.  We will make an agreement for all the specifications that you create. - “invokedWebService” contains the name of the current invoked partner service. - “Output” means the message sent by the current invoked partner service to SUT. - “Template” is the name of template describing the composition of partner service.
         Top of Page
    2. Creation of the test environment
        3. The test environment is composed of simulated partner services, the queue of each partner service, the queue of tester and the proxy of each queue.
      1. Creation of simple simulated partner services and connecting them to the SUT
        2. Using JDeveloper, create the necessary partner services. In our case study we have got four partner services (LBS, LBO, UC and HM) and the client. We suppose that all message exchanged between the SUT and its partner services are “String”. In order to test the overall operation of the system, we will, firstly, create simple partner that takes a string as input and returns it. Let’s create these simple web services.
        1- Start the Jdev. Right click on Applications, Select New Application give name as“BloodBankingBanking” Select “No Template” as Application Template. Click OK.
        Creation of the BloodBanking Application
        We will now create the simple web service of Local Blood search (LBS).
        2- Right click on the “BloodBanking” and create a new Project “Java Application Project”, give the name as “LBSProject” click Next , then Finish.
        Creation of a new Java Application Project
        Insertion of the project name
        3- Right click on the “LBSProject” and create a new Java Class.
        Creation of a new java class
        4- Give the name “LBS” and click OK.
        Naming the created Java class
        5- As we have already said, we will create simple services that take a string and return a string. The code of LBS.java is :
        The simple code of LBS.java
        Now we will create the corresponding partner service.
        6- Right Click on “LBSProject”, select “All Technologies”, expand “Business Tier”, select “Web Services”, select “Java Web Service” and click OK,
        Creation of a new Java Web service
        7- Select je J2EE Web service version.
        Selection of J2EE Web Service Version
        Click “Browse”, then expand Hierarchy to select the java class that you want to publish as a web service. In our case LBS.
        The choice of the java class to publish as a Web service
        8- Give the name “LBS” and click next.
        9- Select the methods that you want that the web service expose. In our case, it is LBSOperation(java.lang.String).
        Selection of the methods that web service will expose
        10- Check the web service Endpoint, especially, the port number (in our case, SOA Suite is installed on port 8889). Click Next, then Finish.
        11-
        Checking the web service Endpoint
        As shows the next figure, files (Web service (LBS), wsdl file (ILBS.wsdl) , a java interface (ILBS.java), WebServices.deploy ) and directory (WEB-INF) are created.
        The creation of the Web service LBS
        12- Right Click on the Process and regenerate it.
        Regenerate Web service
        13- Right Click on the Process and deploy it to SOA Server Connection.
        Deployment of invoked partner service
        14- Once deployment is successfully finished, complete the creation of the other partner services (LBO, UC and HM).
        Notice: We will make an agreement for all partners that you create:
        - The name of the partner service must the same as the specification.
        15- Now, add these created partners to your BPEL process, in the correct place.
        BloodBanking BPEL Process
        16- Right Click on the Process and deploy it to SOA Server Connection.
        Deployment of Blood Banking BPEL process
        17- Once deployment is Successfully Completed, login to BPEL Console at this URL http://localhost:8889/BPELConsole/ and test the BPEL composition. (It’s assumed that SOA Suite is installed on port 8889). Now, all partner services are created and connected to the composition. As we have said before, all partner services have the same role. In fact, 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. We will see later the code of partner service used in the test. But now, we will concentrate on the communication between tester and simulated partner services. This communication is provided by queues (look the section of WSCCT architecture).
        Before starting the test, we must prepare the queue of the tester and each partner service. Notice: all queues are web services.
        Let’s start by the queue of the tester.
         Top of Page
      2. Creation of Tester’s Queue
        3.  Tester’s queue is used to save the information sent by the BPEL to the current invoked partner service. The WSCCT core gets this information and checks its correctness with reference to the wsdl file of the invoked partner service.
        1- As we did in the section 2.2.1, create, on the “BloodBanking”, a new Project “Java Application Project”, give the name as “TesterQueue”.
        2- Create a new Java Class, give the name as “TesterQueue”.
        3- In “TesterQueue. Java”, copy and paste the code existing in this file.
        4- Create the corresponding Web service, and give it the name as “TesterQueue”.
        5- Select all the proposed methods as shown in the next figure.
        Creation of TesterQueue Web service
        6- “TesterQueue” web service is finally created
        Tester Queue Web service components
        7- Regenerate and deploy the created web service.
      3. Creation of proxy of tester’s Queue
        4.  In order to facilitate the usage of the Web service “TesterQueue” by partner services and WSCCT core, we use proxies. So, how to create a proxy of “TesterQueue”?
        1- Right click on the “BloodBanking” and create a new Project “Java Application Project”, give the name as “TesterQueueClient” click Next, then Finish.
        Creation of a new Java Application Project of the proxy of TesterQueue
        2- Right Click on the project “TesterQueueClient”, select “All Technologies”, expand “Business Tier”, select “Web Services”, select “Web Service Proxy” and click OK,
        Creation of the proxy of TesterQueue
        3- By clicking on Browse, select the wsdl file of the TesterQueue. Then, click Next. Generally, you will find it in: “BloodBanking/TesterQueue/classes/testerqueue/ITesterQueue.wsdl”
        Selection of wsdl file of web service to create proxy for
        4- Choose the port Endpoint that the proxy will use to access the ports of the service. Click Next.
        Choosing the port Endpoint of the proxy
        5- Let the Package Names be default given. Then, click Finich.
        Defining packages of the proxy
        6- Finally the Proxy Code is Auto Generated Successfully.
        TesterQueue Proxy components
      4. Creation of partner service’s Queue
        5.  Partner’s queue is used to save information sent by WSCCT core to the current invoked partner service. The current invoked partner service takes this information and sent it to the SUT. Let’s create the queue of LBS service.
        1- As we did in the section 2.2.1, create, on the “BloodBanking”, a new Project “Java Application Project”, give the name as “LBSQueue”.
        2- Create a new Java class; give the name as “PartnerQueue”.
        3- In “PartnerQueue. Java”, copy and paste the code existing in this file.
        4- Change the name of the package: instead of “partnerpackage”, set the name of the package which contains “LBSQueue.java”. In our case, it “lbspackage”.
        5- Change the name of the class: instead of “PartnerQueue”, set “LBSQueue”.
        Notice: for each creation of a partner service’s queue, we change the word “partner” by the name of the corresponding partner. Modification must be done carefully. You can download LBSQueue code from here.
        6- Create the corresponding Web service, and give it the name as “LBSQueue”.
        7- Select all the proposed methods as shown in the next figure.
        Creation of LBSQueue Web service
        8- The Web service “LBSQueue” is finally created.
        Components of LBSQueue
        9- Regenerate and deploy the created web service.
        Notice: We will make an agreement for all the Queues of partners that you create.
        - Queues are Web service.
        - The name of Queue is concatenation of two words the Name of the web service and the word “Queue”. We suppose that your Web service is named A. So it’s Queue have the name “AQueue”.
      5. Creation of the proxy of partner service’s Queue
        6.  In order to facilitate the usage of the Web service “TesterQueue” by partner services and WSCCT core, we use proxies. To create a proxy, follow the same steps taken in creating the proxy TesterQueue in this section.
        Notice: We will make an agreement for all the proxy of Queues of partners that you create.
        - The name of the proxy is the concatenation of two words the Name of the Queue and the word “Client”. We suppose that your Web service is named A. So its Queue’s proxy have the name “AQueueClient”.
         Top of Page
      6. Modifying the code of partner service
        7.  As we have said before, all partner services have the same role. In fact, 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. We will here modify the code of the Local Blood Search.
        1- We want our java jar files created in the “LBSQueueClient” and “TesterQueueClient” to be available at “LBSProject”. For this, right click on “LBSProject”, go to project properties, select dependencies and check on “LBSQueueClient.jpr” and “TesterQueueClient.jpr ” as shown in the next figure.
        Modifying the properties of the service LBS
        2- In “LBS. java”, copy and paste the code existing in this file.
        3- By following the steps described as comments in the file, you get the final code of partner service. In fact, you will change in code the word Partner by the name of you partner service.
        Be Careful: the name should be the same of specification.
        4- In the line 26 of “Partner.java”, you are taken to set the appropriate URL of the partner service. SO, How to get it?
        a- Double click on the service LBS.
        b- Expand “Endpoint” and copy the “Web Service Endpoint”. That’s to appropriate URL of the partner service.
        Getting the partner's Endpoint
        c- Copy this URL and paste it in the place of “PartnerURL”.
        5- Regenerate and deploy the service LBS.
        6- Notice: Sometimes, an error “500 Internal” appears when we invoke the partner service. This is due to some missing classes in deployment. To resolve this problem For this, right double click on “WebServices.Deploy” on “LBSProject”, go “WEB-INF/classes”, select “Filters” and check all classes as shown in the next figure.
        Verification of deployment properties of the partner service
      7. Creation of BPEL invoker
        8.  1- Right click on the “BloodBanking” and create a new Project “Java Application Project”, give the name as “BPELInvoker”, click Next, then Finish. In this project, we will create a “Java Web Service Proxy” to invoke the BPEL.
        2- Right click on “BPELInvoker”, select “All Technologies”, expand “Business Tier” select “Web Services” and select “Web Service Proxy” click OK.
        3- Give the WSDL URL points to our Business Process to be executed. Check on Copy WSDL into Project.
        Creation of the Proxy of BPEL Process
        4- At this stage we want to invoke the system, then we choose the process service. In our case; the process service is : “BloodBankingBPELProcess1” . We will not use “BloodBanking"
        Choosing the port endPoint of the proxy
        5- Choose the port Endpoint that the proxy will use to access the ports of the service. Click Next.
        Finishing the creation BPEL Proxy
        6- Let the Package Names be default given. Then, click Finish.
        7- Finally, if one clicks Finish, the Proxy code will be Auto Generated Successfully.
        Finishing the creation BPEL Proxy
        8- If one clicks on the Proxy, he/she can see all the generated files of which major files are:
        - “BloodBankingBPELProcess1_PortClient.java”,
        - “BloodBankingBPELProcess1ProcessRequest.java”,
        Some of generated files
        9- Now, we will add the method “invokeBPEL()” to “BloodBankingBPELProcess1PortClient.java”.
        Code of BPELinvocation
        Notice: For other examples of BPEL processes to test, change “BloodBankingBPELProcess1PortClient.java” by the created java files. You can download “BloodBankingBPELProcess1PortClient.java” code source from here.
      8. Creation of classes that call the created proxies
        9.  In order to test BPEL compositions, WSCCT core uses some classes to call the proxies of the partner Web services. These classes should be created in the tester directory. So, go to the download section to get the tester directory. In our case study, we have created five proxies and its essential classes are:
        - “bpelinvoker.proxy.BloodBankingBPELProcess1PortClient”: it is used to invoke “BloodBankingBPELProcess1”;
        - “lbsqueueclient.proxy.LBSQueuePortClient”: it is used to invoke “LBSQueue”;
        - “lboqueueclient.proxy.LBOQueuePortClient”: it is used to invoke “LBOQueue”;
        - “ucqueueclient.proxy.UCQueuePortClient”: it is used to invoke “UCQueue”;
        - “hmqueueclient.proxy.HMQueuePortClient” : it is used to invoke “HMQueue”.
        So, we will create in the tester directory five classes to call these proxies:
        - “BPELInvoker.java” : it is used to call “bpelinvoker.proxy.BloodBankingBPELProcess1PortClient”. You can download “BPELInvoker.java” from here.
        - “SendToPartnerLBS.java”: it is used to send to the partner service LBS the output generated by WSCCT core (look at step 6 in Steps of online conformance testing). You can download “SendToPartnerLBS.java” from here.
        - “SendToPartnerLBO.java”: it is used to send to the partner service LBO the output generated by WSCCT core. You can download “SendToPartnerLBO.java” from here.
        - “SendToPartnerUC.java”: it is used to send to the partner service UC the output generated by WSCCT core. You can download “SendToPartnerUC.java” from here.
        - “SendToPartnerHM.java”: it is used to send to the partner service HM the output generated by WSCCT core. You can download “SendToPartnerHM.java” from here.
        Notice: We will make an agreement for the names of created classes:
        - The class that invokes the BPEL has always the name : “BPELInvoker”;
        - The class that calls the proxy of partner service’s queue has the name “SendToPartner”+”PartnerServiceName”. Let “A” be the name of a partner service, the name of the class that calls the proxy of the queue of partner service “A” is “SendToPartnerA”.
        Notice: In order to use the essential classes of proxies, these classes should be available at “Tester” project . For this, right click on “Tester”, go to project properties, select dependencies and check on “LBSQueueClient.jpr”, “LBOQueueClient.jpr”, “HMQueueClient.jpr”, “UCQueueClient.jpr”, “BPELInvoker.jpr”, and “TesterQueueClient.jpr” as shown in the next figure.
        Modifying the properties of the “Tester” project
        Notice: For other examples of BPEL processes to test:
        - For the class of BPEL invocation:
        1- Create the class BPELInvoker.java.
        2- Copy and paste the code of “BPELInvoker.java”.
        3- Change the name of BPEL’s proxy by your own created BPEL’s proxy. (Modifications to do are putted as comments in “BPELInvoker.java”).
        For the classes of Partner Proxies:
        1- Create the class “sendToPartner” (choose the name as described in the 1st notice);
        2- Copy and paste the code “SendToPartnerLBS.java”;
        3- Change the proxy by your own created proxy. (Modifications to do are putted as comments in “SendToPartnerLBS.java”).
        Now, everything is ready! So, let’s start the test.
         Top of Page
  3. Use of WSCCT Tool
    4. In this section, we illustrate how to use our proposed WSCCT tool for conformance testing of the HBO-TP scenario implemented in BPEL. In the Tester directory, right click on “Tester.java” which contains the main class of WSCCT core. Select Run in order to execute the test of our Web service composition.
    Tester running
    After running Tester.java, the following interface appears:
    WSCCT graphical user interface
    Before starting conformance testing with WSCCT, the tool user should provide test inputs as depicted in the previous figure.
    Test inputs are:
    1- a xml file that describes Timed Automata specifying BPEL composition under test,
    2- a bpel file that implements the composition under test,
    3- test execution number,
    4- network timeout(in milliseconds).
    Once required inputs are submitted and test is started, WSCCT user can follow at run-time the test execution running as shown in the next figure.
    Test running
    Information about current states and transitions in Timed Automata are provided, in addition to traces of execution advancement from BPEL implementation side (invoked partner services, input/output messages, timing delays, etc.). At the end, verdicts are assigned to every generated test case. After testing, WSCCT user is informed that a final test report is generated and its path on hard drive is also given.
    Example of test report
    In this section, we will present an example of test report generated while testing HBO-TP BPELProcess.
    Example of a test report
    The the above figure, we performed the test runs twice (i.e N=2) and we chose the network time out of 120 s. For the first execution, WSCCT core system takes the first path (in our specification we have two paths). Then, it generates a random data to invoke the BPEL (gs7wk). The BPEL uses this data to invoke the service partner “Local blood search” (LBS) and waits for its answer. At time 3.703, “Local blood Search” informs WSCCT core that it has been invoked. WSCCT core verifies that “LBS” is the right service to invoke and checks the type of the input received from the BPEL. Then, referring to the nature of the output value of “LBS” described in its WSDL file, the tester generates a random (nxt2v) data and sends it to “LBS” which, in turn, sends it to BPEL. When getting this output (nxt2v), the SUT concludes that the conditions related to the needed blood component are not satisfied. Then, for information about unavailable required blood component, the BPEL invokes “unsatisfactory customer “UC” service by sending the input that it has received (gs7wsk) and waits for its response. At time 3.969, “unsatisfactory customer” informs WSCCT core that it has been invoked. WSCCT core verifies that “UC” is the right service to invoke and the type of the input message that received from the SUT. Then, referring to the nature of the output value of “UC” described in its WSDL file, the tester generates a random data (BKT8N) and sends it to “UC” which, in turn, sends it to BPEL. By arriving to the transition “Hospital_reponse”, the WSCCT core takes the final response of SUT and checks its type with respect to the wsdl and xsd files. In our case WSCCT core generated a verdict = PASS indicating that the BPEL implementation conforms to the SUT.
    For the second execution, WSCCT core system takes the second path. Then, it generates a random data to invoke the BPEL (2nSY3). The BPEL uses this data to invoke the partner “Local blood search” (LBS) service and waits for its answer. At time 1.203, “Local blood Search” informs WSCCT core that it has been invoked. WSCCT core verifies that “LBS” is the right service to invoke and checks the type of the input received from the BPEL. Then, respecting the model (TA), the test system waits for a period of 60 s (delay = 60) and does not answer “LBS” which remains waiting the response of the tester to send it to the BPEL process. After the passage of the 60s, the BPEL process signals a "timeout" since he has received nothing from “LBS”. The WSCCT passes to the next state and still waiting and information from an invoked partner service. Finally, a test report with FAIL verdict caused by reaching network timeout. In fact, the tester did not observe the “Hospital maintenance” (HM) service invocation (!invoke_HM) in a delay inferior than 120 seconds. In other words, it did not receive a message from (HM) within this network timeout.
 Top of Page

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