From the IBM WebSphere Developer Technical Journal.

Introduction

In the first two articles in this series, we described an approach to perform repeatable testing of Service Component Architecture (SCA) components, including components implementing business processes using Business Process Execution Language (BPEL). Our approach leveraged the JUnit open source framework and Cactus, its server-side extension. In this installment, we will describe an approach to testing business processes that use human tasks. We will begin by describing a simple business process that contains an inline human task, then outline the applicability of the techniques described in the first two articles in the testing of this process. All of this will set the scene for how we deal with the human task itself, our approach being an extension of the earlier techniques.

Back to top

Testing the components

One key point from the previous articles that applies here is that test creation is simplified by externalising payloads and expected results to XML files. We will illustrate this by considering the simple process shown in Figure 1.

This process represents a simplified archive retrieval process, which begins when a retrieval request is received and validated, and completes with a notification service call. The actual retrieval work requires human intervention and this is expressed as the Retrieve human task; we can imagine that this human task might perhaps require physical retrieval of paper files from long-term storage, or maybe the mounting of a tape from a tape library. The treatment of this human task is the major focus of this article -- but before we look at these human tasks, let's look first at how we would test this process overall.

Our testing would require initiation of the process with a variety of different input values, followed by verification that the notification was made with appropriate values, depending upon the outcomes of validation and of the human task. Our test plan might include items shown in Table 1.

The previous articles showed techniques for defining the input request data and verifying the expected notification requests. Let's briefly summarise these techniques.

Specifying service invocation

Figure 2 shows a test specification that will initiate the Archive Retrieval process; the initiateRetrieval method is invoked with a payload defined in the InitiationRequest.xml payload file.

We can create a variation of this request to drive each test defined in our test plan.

Mock objects

The BPEL process completes by invoking an external service, notifyCustomer. One major criterion for the success of the process is that expected values are delivered to this service; for some tests we expect to see payloads indicating a successful retrieval, while for other tests we expected to see payloads indicating specific failure conditions. Mock objects are used to verify that the expected values are being generated. We create an implementation of the Customer Communication component that provides the notifyCustomer method. An extra capability of the mock object is a Controller Interface that enables the test framework to query whether it was invoked with the expected data values. In the assembly diagram for the test modules shown in Figure 3, you can see that the Mock Controller and Archive Retrieval interfaces are available as standalone references for use from our tests. We can then create a test specification as shown in Figure 4.

The test has a payload of the expected notification data that the mock object should have received from the business process; the overall test only succeeds if this expected data was generated by the business process.

Test specification summary

Figure 5 shows the relationship between the test specifications, the process, and the mock objects we have described. It also highlights our remaining issue: the human task.

If the test were to run, then the business process would be initiated, a human task would be generated at the Retrieve step, and no further progress would be made. We need to claim and complete the human task so that the process will move on to notifyCustomer, hence preparing the MockCustomerCommunication object for the CheckNotification step. We will describe our technique for claiming and completing the human task in the next section of this article.

A set of projects in a Project Interchange file are included in the download file provided with this article. This file includes these projects:

Import these projects into WebSphere® Integration Developer and examine them as you continue through this article, which assumes you will be running the tests and exploring their effect using Business Process Explorer.

Working with human tasks requires that you enable WebSphere security so that different human users can be indentified by WebSphere Process Server, hence enabling human tasks to be correctly allocated. If you do not already have WebSphere security enabled and you wish to work through these examples, then enable security as described in the Enabling security in your test environment section below. If you already have security enabled, then you will need to provide suitable users for test execution; the appropriate set of users is described in that section as well, and example Custom Registry files, archiveUsers.props and archiveGroups.props are included in the download material provided with this article.

Start your WebSphere Integration Developer test server and add these three SCA Modules to your server:

• MP_ArchiveRetrieval
• MT_TestArchiveRetrieval
• MT_MockCustomerCommunication.

As you work through this article, you will see that the test framework we provide makes test creation comparatively simple. If you want to create similar tests for yourself, then you will need to create JUnit test projects similar to MT_TestArchiveRetrievalJUnitWeb and MT_TestArchiveRetrieval. An earlier article in this series explains how to do this.

Back to top

Claiming and completing a human task

Here, we will look at an example test scenario that fills in the missing step highlighted in Figure 5: emulating human intervention by claiming and completing the Retrieve human task. We will follow a top-down approach to this scenario, first executing the test, then analysing the processing that occurred, and then, finally, looking in detail at the specification of the test step.

Run the test

Having imported the projects listed into a suitable workspace, switch to a Web perspective. Expand the Dynamic Web Projects and then the MT_TestArchiveRetrievalJUnitWeb project to see the JUnit test classes and their associated test data (Figure 6).

Let's examine the test class HumanTaskExampleTest and the data files in the HumanTaskExample-Data directory. When you open HumanTaskExampleTest.java, you will see this familiar test code:

public class HumanTaskExampleTest extends ServletTestCase {
	public void testHumanTask() {
		ScaTestExecutor executor = new ScaTestExecutor(getClass(), getName());
		executor.executeServiceTest();
	}

We will consider just one test method, named testHumanTask, and the test steps for this method will be in the subdirectory of the same name, as shown in Figure 6. You will notice there are five data files in this directory with the extension .tspec. These files define the five test steps:

1. 010-HouseKeepArchiveProcesses.tspec -- Tidy up any failed processes from previous tests. (Will be discussed later.)
2. 020-InitialiseNotification.tspec -- Initialise the Mock Customer Notification object. (See previous article for more details.)
3. 040-InitiateRetrieval.tspec -- Initiate our Archive process with valid data. (This is the first step shown in Figure 5.)
4. 050-CompleteRetrieval.tspec -- This step emulates a human claiming and completing the retrieval task. This is the step we are analysing in detail.
5. 060-CheckNotification.tspec -- Verify that the Mock Customer Notification object received the expected data from the process.

Execute these steps by launching the JUnit test, instructions for which can be found in Part 1. In summary:

1. In the Project Explorer view of the Web perspective, select HumanTaskTest.java.
2. Run Menu => Run... to display the Run dialog.
3. Click New to populate the Test tab with the HumanTaskTest class and its package.
4. Select the Arguments tab and enter the Cactus URL as a VM argument (adjust the port to reflect your server's settings, if necessary):

   -Dcactus.contextURL=http://localhost:9080/MT_TestArchiveRetrievalJunitWeb

   
   
5. Click Run to launch the test. Progress will be shown in the JUnit view (Figure 7).

Now, let's verify what actually happened in the business process during the execution of this test.

What happened: In the console

Useful information about the progress of the test is reported to the console. (The next section shows how the BPC Explorer provides some of this information in a friendlier way.) You can use the console view to inspect the server's SystemOut log (Figure 8).

You might find this output to be rather verbose; you can modify the test framework to be more terse for day-to-day use. More information is emitted in this example than usual, but this information might be helpful in understanding the test activities.

In the console, we can see the five steps of our test:

1. 010-HouseKeepArchiveProcesses.tspec

   This step deletes any instances of our Archive process that might be remaining from previous executions. (How this is done is discussed later.)

   HumanTaskExam I Test: HumanTaskExampleTest/testHumanTask/tidy up archive processes - zap everything ProcessTestEx I Complete task ProcessTestEx I Terminate process instance MP_ArchiveRetrievalProcess state 3 ProcessTestEx I deleted :_PI:9003010f.5331a825.3d725bf6.47190000

   
   

2. 020-InitialiseNotification.tspec

   This step initialises the Mock Communication object.

   HumanTaskExam I Test: HumanTaskExampleTest/testHumanTask/Reset Mock Communication

   
   

3. 040-InitiateRetrieval.tspec

   The next step initiates the retrieval process. The data used to initiate the process is displayed.

   HumanTaskExam I Test: HumanTaskExampleTest/testHumanTask/Initiate retrieval process initateRetrie I Initiating with <?xml version="1.0" encoding="UTF-8"?> <_:datadump xsi:type="l:RetrievalRequest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:l="http://L_Archive" xmlns:_="http://scatest/issw/ibm/com"> <customerId>1</customerId> <requestId>11</requestId> <dateOfRecord>2006-05-12T10:04:17.714Z</dateOfRecord> <region>111</region> <duration>1111</duration> </_:datadump>

   
   

4. 050-CompleteRetrieval.tspec

   This step is our primary focus: the claiming and completion of the retrieval task.

   HumanTaskExam I Test: HumanTaskExampleTest/testHumanTask/Archive retrieval completes HumanTaskTest I Complete task HumanTaskTest I task query TASK.STATE = TASK.STATE.STATE_READY AND (TASK.KIND = TASK.KIND.KIND_PARTICIPATING OR TASK.KIND = TASK.KIND.KIND_HUMAN) AND WORK_ITEM.REASON = WORK_ITEM.REASON.REASON_POTENTIAL_OWNER AND TASK.NAME = 'MP_ArchiveRetrievalProcess$MP_ArchiveRetrievalProcessTask1' HumanTaskTest I claimed com.ibm.task.api.ClientObjectWrapper@3b198581 HumanTaskTest I completion data <?xml version="1.0" encoding="UTF-8"?> <_:datadump xsi:type="l:RetrievalResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:l="http://L_Archive" xmlns:_="http://scatest/issw/ibm/com"> <status>7</status> <explanation>Retrieved</explanation> </_:datadump>

   
   

   Query string

   The first bold section above shows the task query used to claim the task. When you create this test step, you need to specify the query that will identify the tasks that will be claimed and completed. The query used here selects human tasks of a particular type that are ready for claiming. In this simple process, with only a single instance of a single task, you don't need any finer control over the query. More complex situations might require more complex queries; a good starting point to understand the query syntax is the Interface HumanTaskManagerService article in the Information Center.

   Completion data

   You complete the task by supplying appropriate completion data according to the task's interface, as shown in the second bold section above. In this case, a successful retrieval is indicated by a status code of "7". This is sufficient for the first item in the example test plan (Table 1). The second test would supply a status code indicating a failed retrieval.

5. 060-CheckNotification.tspec

   In the last step, the Mock Object reports the Retrieval Notification it received.

   MockCustomerC I sendRetrievalResult<?xml version="1.0" encoding="UTF-8"?> <_:datadump xsi:type="l:RetrievalNotification" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:l="http://L_Archive" xmlns:_="http://scatest/issw/ibm/com"> <specification> <dateOfRecord>2006-05-12T10:04:17.714Z</dateOfRecord> <region>111</region> <accessDuration>1111</accessDuration> <requestId>11</requestId> </specification> <result>7</result> <resultNotes>Retrieved</resultNotes> </_:datadump>

   
   

   The bold data shows that the business process successfully took the results of the human task and created the notification. Finally, you can see the test step checking that the mock object did receive the correct data.

What happened: In the BPC Explorer

Select the Properties view in the Business Integration perspective (Figure 9).

During development and testing, it is preferable to uncheck the option to Automatically delete the process after completion, since this simplifies problem diagnosis in the event of failure. However, this does mean that we need to perform some housekeeping of old process instances, as in the test step 010-HouseKeepArchiveProcesses.

1. Since the process instance from the test you recently executed has not yet been deleted, you can use Business Process Choreographer (BPC) Explorer to verify the test execution: Select the Servers view, then your test server, then right click and select Launch => BPC Explorer (Figure 10).

   
   
   Figure 10. Launch BPC Explorer
   
   
   

2. Select Process Instances Administered By Me (Figure 11). You will see the completed process instance; its state will be "Finished".

   
   
   Figure 11. Process instance
   
   
   

3. Click on the process instance (Figure 11) to show the details of the instance, and then select the Activities... tab.

   
   
   Figure 12. Process activities
   
   
   

4. The three activities undertaken by our process instance are displayed (Figure 12), displayed in reverse sequence. In chronological order they are, as expected, initiateRetrieval, Retrieve, and notifyCustomer. The BPC Explorer lets you to inspect the payloads for activities. For example, if you click on notifyCustomer, you can see the data created by the process (Figure 13).

   
   
   Figure 13. Notification message
   
   
   

5. We are primarily concerned here with the Retrieve human task. Click on the Retrieve task in the activity list (Figure 12) and select the Activity Input Message and Activity Output Message tabs, as shown in Figures 14 and 15 respectively.

   
   
   Figure 14. Retrieve task input
   
   
   
   
   Figure 15. Retrieve task result
   
   
   

6. If you select the Staff link, you will also notice that at present the human task has a potential Owner of "Everybody." More realistic business processes will require authentication, and human tasks will be allocated to specific users or groups of users. We will return to the question of staff queries later.

Next, we will examine the details of the human task test step. You need to understand the specification of the claiming of the task, and the specification of the retrieval response; in our example above the response being the status value of "7" and the explanation value of "Retrieved."

Specify the human task

Each test step that claims and completes a human task is defined by three xml files in the test data directory. In the Project Explorer view of the Web perspective, expand the MT_TestArchiveRetrievalJUnitWeb project and locate the three files:

1. 050-CompleteRetrieval.tspec

   The tspec file is a test specification file similar to those described in the previous articles. It has one new feature here, which is the service references a fully qualified Java™ class rather than an SCA component.

   <service>com.ibm.swservices.sca.test.junit.HumanTaskTestExecutor</service> <method>completeHumanTask</method> <payloadFile>CompleteRetrievalHtSpec.xml</payloadFile> <description>Archive retrieval completes</description> <pause>10</pause>

   
   

   The ability to specify a Java class enables you to extend your test to add required functionality -- in this case, to call the human task APIs. The specified class must be on the classpath of the Web module. The HumanTaskTestExecutor class is delivered in the L_ScaJUnitTest test framework library and so will be deployed along with the Web module as part of the MT_TestArchiveRetrievalJUnit application.

   Locate the HumanTaskTestExecutor.java code under Other Projects in the Project Explorer view of the Web perspective, as shown in Figure 16. Open the file and examine the methods offered. You will see that there are two methods intended for use in tests: deleteHumanTasks and completeHumanTask. We envisage that large scale projects might require additional methods; if so, they could reasonably be added to this class.

   
   
   Figure 16. Human task test executor class
   
   
   

   In our example, we use the method completeHumanTask. The test specification uses the payloadFile element to refer to our second data file: CompleteRetrievalHtSpec.xml.

2. CompleteRetrievalHtSpec.xml

   This file contains the specification of the HumanTask to be claimed. In our example the specification is:

   <taskName>MP_ArchiveRetrievalProcess$MP_ArchiveRetrievalProcessTask1</taskName> <taskCompletionFile>CompleteRetrieval.xml</taskCompletionFile> <minTaskCount>1</minTaskCount> <maxTaskCount>1</maxTaskCount>

   
   

   The three important components of this file are:

   • A specification of the task that is to be claimed.
   • A reference to the third data file, which contains the data used to complete the task.
   • The specification of how many tasks are expected to be claimed.

   The specification can be given in two forms, either as a complete query string, or just the name of the task. In our case, the task name is generated by WebSphere Integration Developer. You can see the task name on the Task tab of a process instance in BPC Explorer, as shown in Figure 17.

   
   
   Figure 17. Task name in BPC Explorer
   
   
   

   More complex test scenarios, where there might be several outstanding tasks, each needing completion with different data, will require the use of a query string. You could have specified your test using a query string instead of just the task name.

   <queryString> TASK.STATE = TASK.STATE.STATE_READY AND (TASK.KIND = TASK.KIND.KIND_PARTICIPATING OR TASK.KIND = TASK.KIND.KIND_HUMAN) AND WORK_ITEM.REASON = WORK_ITEM.REASON.REASON_POTENTIAL_OWNER AND TASK.NAME = ' MP_ArchiveRetrievalProcess$MP_ArchiveRetrievalProcessTask1 ' </queryString>

   
   

3. CompleteRetrieval.xml

   The third file contains the payload used to complete the task. In our example, this is:

   <status>7</status> <explanation>Retrieved</explanation>

   
   

Housekeeping and extensions

The technique we used to specify the human task test is extensible. We have provided a second class, ProcessTestExecutor, that contains housekeeping functionality. Examine the 010-HouseKeepArchiveProcesses.tspec and its associated payload file, as shown in Figure 18.

You see that we specify the use of method deleteProcesses, and apply that to all processes corresponding to the MP_ArchiveRetrievalProcess template. You can add your own functionality in this manner to support your own testing requirements.

These simple examples of test steps performing process housekeeping and human tasks are intended for use by an individual developer on a dedicated workstation in development mode. They make no attempt to coexist as good citizens with other, simultaneous testing. Such coexistence is possible, in principle, but the queries must be written to be selective. We do not intend that tests such as these be used in live production environments; should you do so, it is very possible to do serious damage such as deleting valuable process instances or inadvertently completing human tasks.

Back to top

Authentication and staff queries

There is one further test feature to mention: the ability to execute a test with specified authentication credentials. This test enables you to verify some important aspects of the human task specification.

Open the details of the Retrieve human task (Figure 19). In the Business Integration view, select the task in the BPEL editor, and then in the Details tab of the Properties view, click on the task name.

When the Human Task editor displays (Figure 20), click on Potential Owner in the Receiver settings to show that Everybody can claim this task.

In realistic business processes, the query verbs can be considerably more complex, and indeed have been custom-developed for this task. Queries can be used to implement business requirements such as "4-eyes" sign-off; that is the requirement to have two levels of approval with the requirement that the approvers be two different staff members. Such queries have the same status as any other code you develop, and your tests should exercise them.

Thorough testing then requires that you can specify the user identity that executes each test step. The test framework permits you to specify user ID and password for each test step.

This facility assumes you have enabled security in your test environment. We assume that you will be using a test registry with users whose authentication details are not sensitive, and hence the use of plain-text passwords is acceptable. More secure authentication schemes could be implemented with additional coding effort. If you do use plain-text passwords in your tests, consider that your tests will likely be shared with many other developers, probably via a source code management system. You should set up dedicated users (with no WebSphere administrative rights) to use for your tests and reference only these users in your test scripts. Our next example illustrates how you can do this.

Enabling security in your test environment

The procedure for enabling security on you test server will vary depending upon the particular user registry you choose to use. Our preference for unit testing is to work with a file-based custom registry. Using such a registry removes any dependencies on external services such as LDAP. The custom registry configuration described here is sufficient for desktop unit testing on our desktop, but is not intended for use in a production system.

1. Create two text files, one for users and one for groups. The included download files contain suitable examples, archiveUsers.props and archiveGroups.props. The formats of these files are explained in the Information Center. Place the files in a convenient directory. You need to know their location when configuring the registry later.

2. We have defined five groups:

   • administrators -- staff with WebSphere administrative privileges
   • operators -- staff with WebSphere operation privileges
   • workers -- staff who may implement the retrieval process
   • approvers -- senior staff
   • users -- staff who use the retrieval process.

   In these tests, you will only be specifying members of the users, workers, and approvers groups.

3. We have defined the following users (in these particular groups):

   • wps-server (administrators)
   • administrator (administrators)
   • operator (operators)
   • archivist (users, workers)
   • seniorArchivist (users, workers, approvers)
   • retriever (users, workers)
   • librarian (users, workers, approvers)
   • joe (users)

   Note that WebSphere Application Server itself will run as wps-server, and we will be using this identity for all internal server authentication.

4. To configure the custom registry, start the test server and bring up the admin console. Navigate to Security => Global Security and click on Custom under User registries (Figure 22). The Custom user registry pane will display (Figure 23).

   
   
   Figure 22. Custom registry
   
   
   
   
   Figure 23. Server ID
   
   
   

5. Enter the user name and password that your server will use; our example uses wps-server. Click Apply and then Custom Properties (Figure 23). Specify the location of the users and groups files as Custom properties (Figure 24).

   
   
   Figure 24. Custom registry file locations
   
   
   

6. Create two new properties groupsFile and usersFile, and specify the absolute paths to your property files.

7. Save your changes.

8. You will be using LTPA authentication, which requires a pre-configuration step. Return to the Global security pane (Figure 22) and perform the second configuration step by selecting LTPA under Authentication. Specify an arbitrary password and confirm it, then click OK.

9. The final pre-configuration step is to specify JCA authentication values for access to JMS resources. Again, return to the Global security pane (Figure 22), and under Authentication expand JAAS configuration and select J2C Authentication data.

   
   
   Figure 25. JAAS Aliases
   
   
   

10. In turn, select the SCA alias and the two JMS aliases, and then specify the wps-server and password for each. Save your changes.

11. You can now enable global security. Return to the Global security pane (Figure 26).

    
    
    Figure 26. Enable security
    
    
    

12. Make the following changes:

    • For Active authentication mechanism, select LTPA.
    • For Active user registry, select Custom user registry.
    • Check Enable global security.
    • Uncheck Enforce Java 2 security.

    Click OK and save your changes.

13. At this point, it is preferable to test that your server configuration is correct without using WebSphere Integration Developer. Stop the server in WebSphere Integration Developer and then start it from the command line. You will need open a command window and change the directory to your profile's bin directory; in our case: C:\IBM\WID-6.0.1\pf\wps\bin.

    C:\IBM\WID-6.0.1\pf\wps\bin>startserver server1 ADMU0116I: Tool information is being logged in file C:\IBM\WID-6.0.1\pf\wps\logs\server1\startServer.log ADMU0128I: Starting tool with the wps profile ADMU3100I: Reading configuration for server: server1 ADMU3200I: Server launched. Waiting for initialization status. ADMU3000I: Server server1 open for e-business; process id is 4448

    
    

14. Now check the server logs for error messages. It is quite common for errors to be reported because JAAS alias data was mis-typed earlier. These errors don't prevent the server from starting but do prevent proper functioning.

15. You can fix any errors by bringing up an admin console manually. Search for the admin port in the server logs:

    [11/12/06 13:52:05:375 GMT] 0000000a TCPChannel A TCPC0001I: TCP Channel TCP_3 is listening on host * (IPv4) port 9043. [11/12/06 13:52:05:391 GMT] 0000000a WSChannelFram A CHFW0019I: The Transport Channel Service has started chain WCInboundAdminSecure.

    
    

    and use the corresponding URL in a browser: https://localhost:9043/admin. Authenticate using the server's identity: wps-server.

16. Once the server is started correctly, you can then adjust your WebSphere Integration Developer configuration to communicate with it. In the Server view, double click on the server to bring up the Server Overview window (Figure 27). Ensure that a SOAP connection is used.

    
    
    Figure 27. WebSphere Integration Developer authentication to server
    
    
    

17. Expand Security, specify that Security is enabled on this server, and specify a user ID and password for WebSphere Integration Developer to use to authenticate to the server. Initially, use wps-server as the indentity; you will change this shortly.

18. Save your changes. You should see WebSphere Integration Developer successfully detect that the server is already running; however, you may see some authentication failures appear in the server logs. Restart WebSphere Integration Developer and these failures should cease.

19. As a final piece of configuration, enable WebSphere Integration Developer to authenticate as a separate user from the server itself. Launch the admin console and select System administration => Console users => Console Groups (Figure 28).

    
    
    Figure 28. Admins group
    
    
    

20. Add the group admins as administrators. Save your changes and restart the server. You can now adjust your WebSphere Integration Developer authentication to use your administrator user, leaving the wps-server ID for use only by your server process.

Back to top

Run authenticated tests

You can now specify appropriate users for each of your test steps by adding userId and userPassword elements to each tspec file:

You can then devise additional tests to verify that staff queries have been correctly specified. For example, you could specify a test where a member of only the users group attempts to complete a retrieval; this attempt will fail due to lack of privileges and the test would check that the retrieval is not completed.

Having specified authentication data for your tests, you can then re-run them and use BPC Explorer to verify that the processes and tasks have the expected owners.

You can see in Figure 29 that the process was started by user joe. Administration can only be performed by administrators, which are the users seniorArchivist and librarian. Selecting the Retrieval task, you can see the user who became the task owner.

Figure 30 shows that the user librarian, one of the members of the workers group, performed the retrieval task.

Back to top

Conclusion

You have seen here how the test framework can be used to work with human tasks, thereby enabling complete testing of BPEL processes and staff queries. The techniques used to enable human task manipulation are open to extension for other testing techniques. Process housekeeping was shown here as another example.

Back to top

More in this series

• Part 1: Create automated unit tests for SCA modules
• Part 2: Create repeatable tests for SCA modules that implement business processes

Back to top

Download

Information about download methods

Resources

• Service Component Architecture
  
  
• SCA application development
  
  
• Building SOA solutions with the Service Component Architecture
  
  

About the author

David Artus is member of the IBM Software Services for WebSphere team working out of the IBM Hursley Lab in the UK. He has provided WebSphere consultancy and mentoring since he joined IBM in 1999. Prior to joining IBM David worked in a variety of industries including Investment Banking, Travel and IT Consultancy. His interests include design of distributed systems, object technologies, and service-oriented architectures.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Testing the components
• Claiming and completing a human task
• Authentication and staff queries
• Run authenticated tests
• Conclusion
• More in this series
• Download
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers