| Oracle® Fusion Middleware Security and Administrator's Guide for Web Services 11g Release 1 (11.1.1.5) Part Number B32511-05 |
|
|
View PDF |
| Oracle® Fusion Middleware Security and Administrator's Guide for Web Services 11g Release 1 (11.1.1.5) Part Number B32511-05 |
|
|
View PDF |
This chapter includes the following sections:
This section describes how to use the Fusion Middleware Control Test Web Service page to verify that you are receiving the expected results from the Web service.
The Test Web Service page allows you to test any of the operations exposed by a Web service. You can test Web services that are deployed on any accessible host; the Web service does not have to be deployed on this host.
Note:
The Test Web Service page can parse WSDL URLs that contain ASCII characters only. If the URL contains non-ASCII characters, the parse operation fails. To test a Web service that has non-ASCII characters in the URL, allow your browser to convert the WSDL URL and use the resulting encoded WSDL URL in the Test Web Service page.When testing Web services that use policies, the Oracle WSM component must be installed in the same domain from which Fusion Middleware Control is being run. Otherwise, an invalid policy exception will be returned.
You can navigate to the Test Web Service page in many ways. This section describes one typical way to do so.
To test your Web service
In the navigator pane, expand WebLogic Domain to show the domain in which you want to test a Web service.
Select the domain.
From the WebLogic Domain menu, select Web Services, and then Test Web Service. The Test Web Service input page appears.
Enter the WSDL of the Web service you want to test and click Parse WSDL. If you do not know the WSDL, click the search icon and select from the registered Web services, if any.
If the WSDL is secured with HTTP Basic Authentication, click HTTP Basic Auth Option for WSDL Access and enter the username and password before parsing the WSDL.
The Test Web Service page appears as shown in Figure 12-1. Note that the test option sections are collapsed by default.
Figure 12-1 Test Web Service Page in Collapsed View
Select the service and port to be tested. If the WSDL has multiple services and ports, these fields are available as drop-down menus. If the WSDL has only one service and port, these fields are read-only, as shown in Figure 12-1.
Select the operation that you want to test from the Operation menu. The available operations are determined from the WSDL.
To test a RESTful Web service, select the GET or POST service port operations.
If you want to change the endpoint URL of the test, click Edit Endpoint URL and make the change.
Select the Request tab if it is not already selected.
Expand the test option sections by clicking the plus sign (+) next to the section name. The expanded view of the Test Web Service page is shown in Figure 12-2.
Figure 12-2 Bottom Portion of Test Web Service Page in Expanded View
In the Security section, select the security token to verify. The security setting is not determined from a policy in the WSDL; you can specify the type of token you want to test. The default is None. Depending on the option selected, additional fields are displayed. If you do specify a username and password, they must exist and be valid for the WebLogic Server. For more information, see "Enabling Authentication".
When testing RESTful Web services, because the SOAP protocol is not used, the only security options are HTTP Basic Authentication or None.
In the Quality of Service section, specify whether you want to explicitly test a Reliable Messaging (WS-RM), WS-Addressing, or MTOM policy. For details about the options available, see "Enabling Quality of Service Testing".
Note:
This section is not available when testing RESTful Web services.In the HTTP Transport section, the test mechanism uses the WSDL to determine whether a SOAP action is available to test. If available, specify whether you want send the request with the SOAP action HTTP header. For more information, see "Enabling HTTP Transport Options".
Note:
This section is not available when testing RESTful Web services.In the Additional Test Options section, select the Enable Stress Test option if you want to invoke the Web service multiple times simultaneously. If you select this option, you can also provide values for the stress test options, or accept the defaults. For more information, see "Stress Testing the Web Service Operation".
In the Input Arguments section, enter the input arguments for the Web service in the Value fields. The parameters and type, and the required input values, are determined from the WSDL.
Select Tree View or XML View to toggle between a hierarchical list of input parameters and the XML content.
Click Test Web Service to initiate the test.
The test results appear in the Response tab upon completion.
If the test is successful, the Test Status field indicates Request Successfully received and the response time is displayed, as shown in Figure 12-3.
Note:
When running SOA composite tests, the Response tab will indicate whether a new composite was generated. You can also click the Launch Flow Trace button to open the Flow Trace window, where you can view the flow of the message through various composite and component instances.If the test fails, an error message is displayed. For example, Figure 12-4 shows an error resulting from a type error in the var-Int parameter. In this particular instance, string data was entered when an int was expected.
Note:
The results on the Response tab are a simplified version of the standard Web service results.You can view the input arguments in a user-friendly form, or you can edit the XML source code directly. If you edit the XML source directly, you must enter valid XML. Use the drop-down list in the Input Arguments section of the page to toggle between Tree View and XML View.
You can use the Test Web Service Page to test policies that use username tokens to authenticate users.
Note:
Only policies that expect a username and password are supported by the test function, including custom policies. Policies that require certificates or other tokens are not supported. You cannot use this page to test a Web service with a message protection policy.The security setting is not determined from a policy in the WSDL; you can specify the type of token you want to test. The default is None. If you do specify a username and password, they must exist and be valid.
The password must be passed in plain text. Authentication credentials may be supplied in the request by selecting one of the options in the Security section of the page (Figure 12-5). Select one of the following:
WSS Username Token – A WS-Security SOAP header is inserted. Username is required, and password is optional.
HTTP Basic Auth – Username and password credentials are inserted in the HTTP transport header. Both the username and password are required.
Custom Policy – A custom policy can be used to authenticate the user. You must specify the URI for the policy. The username and password are optional.
None – No credentials are included.
Note:
When testing RESTful Web services, because the SOAP protocol is not used, the only security options are HTTP Basic Authentication or None.Figure 12-5 Security Parameters on the Web Services Test Page
Note:
This section is not applicable when testing RESTful Web services.Three characteristics of Quality of Service (QoS) can be tested: reliable messaging (WS-RM), WS-Addressing, and Message Transmission Optimization Mechanism (MTOM) in the Quality of Service section of the Test Web Service Page (Figure 12-6). For each type of Quality of Service, there are three options:
WSDL Default – Execute the default behavior of the WSDL. For example, if WSDL Default is selected for MTOM, and the WSDL contains a reference to an MTOM policy, the policy is enforced. If the WSDL does not contain a reference to an MTOM policy, then no MTOM policy is enforced.
None – No policy for the specific QoS, even if it is included in the WSDL, is executed. For example, if None is selected for WS-RM, no reliable messaging policy is enforced. If the WSDL contains a reference to a reliable messaging policy, it is ignored.
Custom – Enforce a custom policy. For example, if a WS-Addressing policy is referenced in the WSDL, this policy will be ignored, and the policy specified in URI will be used instead.
URI – Specify the location of the policy to be enforced.
Figure 12-6 Quality of Service Parameters on the Test Web Service Page
Note:
This section is not applicable when testing RESTful Web services.The test mechanism uses the WSDL to determine whether a SOAP action is available to test. If the WSDL soap:operation has a soapAction attribute, then this is displayed and Enable SOAP Action is enabled.
When a request is sent with Enable SOAP Action enabled, then the SOAP action HTTP header is sent.
To change this behavior, clear the Enable SOAP Action box, in which case the HTTP header is not sent. Or, you can override the behavior by providing a different value in the SOAP Action field. (You must already know the SOAP action that you want to test, and the syntax.)
Figure 12-7 HTTP Transport Options on the Test Web Service Page
Select the Enable Stress Test check box (Figure 12-8) to invoke a continuous series of invocations of the Web service operation (Figure 12-8). The following options are available:
Concurrent Threads – The number of concurrent threads on which the invocations should be sent. The default is 5 threads.
Loops per Thread – The number of times to invoke the operation. The default is 10 times.
Delay in Milliseconds – The number of milliseconds to wait between operation invocations. The default is 1000 milliseconds (1 second).
Figure 12-8 Stress Testing Parameters on the Test Web Service Page
When you invoke the test, a progress box indicates the test status. When the stress test is complete, a confirmation page displays the results of the test.
The Response tab provides additional information about the stress test, including the number of tests with errors, and the average, minimum, and maximum response times. Details about each test are provided in tabular form. For each test, you can view the thread and loop numbers, the duration of the test, the start and end times for the test, and the invocation status. You can filter the fields displayed in the table using the View menu.
Figure 12-9 Stress Test Results on Test Web Service Page
Note:
This section does not apply to Java EE Web services.Disabling the test page for a Web service allows you to increase security by reducing the externally visible details of an application that exposes Web services.
Note:
Disabling the Endpoint Test Enabled control affects only the Web service's externally-visible test page. It does not affect the Web service test feature described in this chapter.To disable the Test Page using Fusion Middleware Control
Navigate to the Web Services summary page, as described in "Navigating to the Web Services Summary Page for an Application".
In the Web Service Details section of the page, click on the plus (+) for the Web service to display the Web service ports if they are not already displayed.
Click the name of the port to navigate to the Web Service Endpoint page.
Click the Configuration tab.
In the Endpoint Test Enabled field, select False from the list.
Click Apply.
|
 Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
