5 Testing Web Services

You can test basic and advanced features of your web service, including security, quality of service (QoS), HTTP header options, and so on. You can also perform stress testing of the security features.

After you have deployed a web service to WebLogic Server, you can use one of the following tools to test your web service:

• Web Services Test Client, as described in "Using the Web Services Test Client" on page 5‐1.

• Fusion Middleware Control Test Web Service Page, as described in "Test Web Service Page in Fusion Middleware Control" on page 5‐14.

5.1 Using the Web Services Test Client

Only the users with roles as Admin or Deployer can use the Web Services Test Client to test web services.

Using the Web Services Test Client, these users can:

• Test basic functionality to ensure that the web service was deployed and is operating as expected.

• Test basic authentication security.

• Test advanced features, such as web services addressing, atomic transactions, SOAP Message Transmission Optimization Mechanism (MTOM), Fast Infoset, and Oracle Web Service Manager (OWSM) security policies.

  Note:

  For web services that use SOAP over Java Messaging Service (JMS) transport as the connection protocol, you can test only basic features.

• View the WSDL for the web service and the imported schemas, if applicable.

• Export and import test cases.

• Configure Java keystores (JKS) for use in testing security.

• Configure and use HTTP proxy settings, as required by your environment.

The following sections describe how to use the Web Services Test Client:

• Invoking the Web Services Test Client

• Selecting the Web Service to Test

• Testing Web Service Operations

• Configuring Basic Test Settings

• Testing Advanced Web Service Features and Security

• Viewing the WSDL and Imported Schemas

• Configuring the Web Services Test Client

• Editing the Input Arguments as XML Source

• Viewing the History

• Exporting and Importing Test Cases

• Enabling and Disabling the Web Services Test Client

• Logging Out of the Web Services Test Client

See Also:

• Default Global Roles

5.1.1 Invoking the Web Services Test Client

You can invoke the Web Services Test Client from any browser, using the web service endpoint, or using the Administration Console.

For more information, refer to the following sections:

• "Invoking the Web Services Test Client From a Browser" on page 5‐2

• "Invoking the Web Services Test Client Using the Web Service Endpoint" on page 5‐3

• "Invoking the Web Services Test Client Using the Administration Console" on page 5‐3

Note:

When you first invoke the Web Services Test Client, there will be a brief delay while the application deploys.

To test web services that use SOAP over JMS transport as the connection protocol, the test page must be invoked from the server on which the web service is deployed.

5.1.1.1 Invoking the Web Services Test Client From a Browser

You can invoke the Web Services Test Client from any browser by entering the following URL:

http://host:port/ws_utc

where:

• host refers to the computer on which WebLogic Server is running.

• port refers to the port number on which WebLogic Server is listening (default value is 7001).

When prompted, enter the login credentials for the Web Services Test Client.

The Web Services Test Client home page is invoked. To select the web service WSDL, see "Selecting the Web Service to Test" on page 5‐3.

5.1.1.2 Invoking the Web Services Test Client Using the Web Service Endpoint

You can invoke the Web Services Test Client by navigating to the web service endpoint.

• For an Oracle Infrastructure web service, when you navigate to the web service endpoint, the Web Services Test Client is invoked with the web service WSDL selected.

• For JAX-WS and JAX-RPC web services, an intermediary page is invoked. Click Test to invoke the Web Services Test Client with the web service WSDL selected.

When prompted, enter the login credentials for the Web Services Test Client.

To test the web service operations, see "Testing Web Service Operations" on page 5‐4.

5.1.1.3 Invoking the Web Services Test Client Using the Administration Console

To test a deployed web service using the Administration Console, follow these steps:

1. Invoke the Administration Console in your browser using the following URL:

   http://[host]:[port]/console
   

   where:

   • host refers to the computer on which WebLogic Server is running.

   • port refers to the port number on which WebLogic Server is listening (default value is 7001).

2. Select the web service in the Deployments table that you would like to test. For more information, see "How Web Services Are Displayed in the Administration Console" in Understanding WebLogic Web Services for Oracle WebLogic Server.
3. Select the Testing tab and click the Test Point link next to the web service endpoint that you want to test.
4. When prompted, enter the login credentials for the Web Services Test Client.
5. Follow the procedure described in "Test a Web Service" in Oracle WebLogic Server Administration Console Online Help.

The Web Services Test Client is invoked with the web service WSDL selected. To test the web service operations, see "Testing Web Service Operations" on page 5‐4.

5.1.2 Selecting the Web Service to Test

From the Web Services Test Client home page, you can select the WSDL corresponding to the web service that you want to test. You can return to this page at anytime by selecting Choose Another WSDL.

To select the web service to test:

1. Enter the WSDL in the Enter WSDL URL field.
2. To use the configured HTTP proxy, click the HTTP Proxy check box.

   For information about configuring the proxy, see "Configuring an HTTP Proxy" on page 5‐11.

3. Click Test.

Alternatively, you can select a WSDL that was previously loaded from the WSDL list. To toggle the list, click Show WSDL List or Hide WSDL List.

The web service operations that are available to test are displayed. For more information, see "Testing Web Service Operations" on page 5‐4.

5.1.3 Testing Web Service Operations

To test a web service operation:

1. Select the web service operation to test using one of the following methods:

   • Select the operation in the Operations pane.

   • With the web service port folder selected in the Operations pane, click Test associated with the web service operation that you want to test.

2. Enter a value for each of the parameters in the Parameters section.

   Required parameters are identified using .

   For information about editing the XML source, see "Editing the Input Arguments as XML Source" on page 5‐12.

3. Configure the basic settings for the test client, such as the endpoint URL, basic authentication settings, encoding and binding types, and whether or not you want to use the configured HTTP proxy. For information, see "Configuring Basic Test Settings" on page 5‐4.
4. Test the advanced features of your web service by configuring settings (as applicable), as described in "Testing Advanced Web Service Features and Security" on page 5‐5.

   Ensure that the advanced feature settings are compatible with the web service endpoint that you are testing. If they are not, the test will fail and the stack error displays in the Test Results section.

   Note:

   For web services that use SOAP over JMS transport as the connection protocol, you can test only basic features.

5. Click Invoke.

The Test Results section is displayed at the bottom of the content area, displaying the SOAP request and response messages. If the test fails, the stack error information is displayed in the Test Results section.

5.1.4 Configuring Basic Test Settings

Basic test settings for a test client includes Endpoint URL, User Name, Password, Encoding, BindingType, and HTTP Proxy.

You can configure basic settings for the Web Services Test Client, including the username and password for basic authentication, by clicking the Basic Settings tab in the Settings section, setting the values defined in Table 5–1, and clicking Invoke to invoke the web service.

Table 5-1 Basic Test Client Settings

Setting	Description
Endpoint URL	Override the web service endpoint address.
User Name	Username to use for testing basic authentication. Note: You configure the JKS keystores, as described in "Configuring the JKS Keystores" on page 5‐11
Password	Password to use for testing basic authentication. Note: You configure the JKS keystores, as described in "Configuring the JKS Keystores" on page 5‐11
Encoding	Encoding standard. Valid values include: UTF-8 and UTF-16.
BindingType	Binding type. Valid values include: SOAP Binding—Standard SOAP web service. REST/HTTP Binding—SOAP over HTTP using the invoke() method of the javax.xml.ws.Provider<T> interface.
HTTP Proxy	Flag that specifies whether the HTTP proxy is enabled. You can configure the global HTTP proxy setting, as described in "Configuring an HTTP Proxy" on page 5‐11. Note: This setting is available in development mode only.

5.1.5 Testing Advanced Web Service Features and Security

Advanced web service features include Addressing, Atomic Transactions, MTOM, Fast Infoset, and OWSM security policies.

For more information on how to test the advanced features of a web service, refer to the following sections:

• Testing Addressing

• Testing Atomic Transactions

• Testing MTOM

• Testing Fast Infoset

• Testing OWSM Security Policies

Note:

For web services that use SOAP over JMS transport as the connection protocol, you can test only basic features.

5.1.5.1 Testing Addressing

WS-Addressing provides a transport-neutral mechanism to address web services and their associated messages. Using WS-Addressing, endpoints are uniquely and unambiguously defined in the SOAP header. For more information, see "Using Web Services Addressing" in Developing JAX-WS Web Services for Oracle WebLogic Server.

You can test WS-Addressing, if enabled on the web service, by clicking the Addressing tab in the Settings section, setting the values defined in Table 5–2, and clicking Invoke to invoke the web service.

Table 5-2 Test Settings for WS-Addressing

Setting	Description
Enabled	Flag that specifies whether WS-Addressing is enabled on the Web Service Test Client.
Version	WS-Addressing version. Valid values include: W3C. For more information, see: http://www.w3.org/2002/ws/addr/ Member Submission. For more information, see http://www.w3.org/Submission/ws-addressing/
ReplyTo	Type of the ReplyTo header. Valid values include: anonymous, non-anonymous, and Addressing None.
FaultTo	Type of the FaultTo header. Valid values include: anonymous, non-anonymous, and Addressing None.

5.1.5.2 Testing Atomic Transactions

web services enable interoperability with other external transaction processing systems, such as Websphere, Microsoft .NET, and so on, through the support of the following specifications:

• Web Services Atomic Transaction (WS-AtomicTransaction) Versions 1.0, 1.1, and 1.2: http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec-cs-01/wstx-wsat-1.2-spec-cs-01.html

• Web Services Coordination (WS-Coordination) Versions 1.0, 1.1, and 1.2: http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-cs-01/wstx-wscoor-1.2-spec-cs-01.html

For more information about web services atomic transactions, see "Using Web Services Atomic Transactions" in Developing JAX-WS Web Services for Oracle WebLogic Server.

You can test atomic transactions, if enabled on the web service, by clicking the Atomic Transaction tab in the Settings section, setting the values defined in Table 5–4, and clicking Invoke to invoke the web service.

Table 5-3 Test Settings for Atomic Transactions

Setting	Description
Enabled	Flag that specifies whether atomic transactions are enabled on the Web Service Test Client.
Version	Version of the web services atomic transaction coordination context that is used for the Web Service Test Client. Valid values include: default, wsat, wsat11, and wsat12. The default value for web service clients is wsat (equivalent to WS-AT 1.0).
Transaction Flow Type	Flag that specifies whether the web services atomic transaction coordination context is passed with the transaction flow. For information about setting this value, see "Enabling Web Services Atomic Transactions on Web Services" in Developing JAX-WS Web Services for Oracle WebLogic Server.
Action After Invocation	Action required after invocation. Valid values include commit or rollback the transaction.

5.1.5.3 Testing MTOM

SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging (MTOM/XOP) defines a method for optimizing the transmission of XML data of type xs:base64Binary or xs:hexBinary in SOAP messages. When the transport protocol is HTTP, Multipurpose Internet Mail Extension (MIME) attachments are used to carry that data while at the same time allowing both the sender and the receiver direct access to the XML data in the SOAP message without having to be aware that any MIME artifacts were used to marshal the base64Binary or hexBinary data.

For more information about MTOM, see:

• JAX-WS: "Optimizing Binary Data Transmission Using MTOM/XOP" in Developing JAX-WS Web Services for Oracle WebLogic Server

• Oracle Infrastructure Web Services: "Using MTOM Encoded Message Attachments" in Developing Oracle Infrastructure Web Services.

You can test MTOM, if enabled on the web service, by clicking the MTOM tab in the Settings section, setting the values defined in Table 5–5, and clicking Invoke to invoke the web service.

Table 5-4 Test Settings for MTOM

Setting	Description
Enabled	Flag that specifies whether MTOM is enabled on the Web Service Test Client.
Threshold	Attachment threshold (in bytes) that specifies whether xs:binary64 data is sent inline or as an attachment. This value defaults to 0 (all data is sent as an attachment).

5.1.5.4 Testing Fast Infoset

Fast Infoset is a compressed binary encoding format that provides a more efficient serialization than the text-based XML format. For more information about Fast Infoset, see

• JAX-WS: "Optimizing XML Using Fast Infoset" in Developing JAX-WS Web Services for Oracle WebLogic Server.

• Oracle Infrastructure Web Services: "Optimizing XML Transmission Using Fast Infoset" in Developing Oracle Infrastructure Web Services.

You can test Fast Infoset, if enabled on the web service, by clicking the Fast Infoset tab in the Settings section, setting the values defined in Table 5–6, and clicking Invoke to invoke the web service.

Table 5-5 Test Settings for Fast Infoset

Setting	Description
Enabled	Flag that specifies whether atomic transactions are enabled on the Web Service Test Client.
Negotiation Type	Negotiation strategy. Valid values include: none—No negotiation strategy. optimistic—Client assumes that Fast Infoset is enabled. pessimistic—Initial client request, Fast Infoset is not enabled. Subsequent requests will use Fast Infoset if enabled on the service. For more information about the content negotiation strategy, see: JAX-WS: "Configuring the Content Negotiation Strategy" in Developing JAX-WS Web Services for Oracle WebLogic Server. Oracle Infrastructure Web Services: "Configuring the Content Negotiation Strategy" in Developing Oracle Infrastructure Web Services.

5.1.5.5 Testing OWSM Security Policies

You can test OWSM security policies by clicking the OWSM tab in the Settings section, setting the values defined in Table 5–8, and clicking Invoke to invoke the web service.

Note:

For Java EE web services, this tab is available only if you have OWSM installed.

Only a subset of the OWSM predefined policies is available, and you can configure only the attributes presented for those policies. All of the other policy attributes use only the policy defaults.

This means that copies you made of the predefined policies are not available. It also means that you cannot enable Secure Conversation, change the message security algorithm suite, and so forth.

Table 5-6 Test Settings for OWSM

Setting	Description
Enabled	Flag that specifies whether OWSM policies are enabled on the Web Service Test Client.
Policies	Select the policies that you want to test on the client by selecting the associated check box. You can test only a subset of security policies. Note: For the policy selected, you must configure the required properties below. Otherwise, an exception is thrown.
Username	Username used for basic authentication.
Password	Password used for basic authentication.
Keystore Location	Location of the keystore file. Click Choose File to navigate to the file in your local directory, which is typically in DOMAIN_HOME\domain_name\config\fmwconfig.
Remote Keystore Location	Location of the remote keystore. If not specified, the keystore local to the server is used.
Keystore Password	Password used for keystore access.
Encryption Key Alias	Alias of the key within the keystore that will be used to decrypt the response from the service. This property is not used in WSS11 policies.
Encryption Key Password	Password for the key within the keystore that will be used for decryption. This property is not used in WSS11 policies.
Signature Key Alias	Alias of the key within the keystore that is used for digital signatures. For WSS11 policies, this property is used for mutual authentication only.
Signature Key Password	Password for the alias of the key within the keystore that is used for digital signatures.
Recipient Key Alias	Alias for the recipient's public key that is used to encrypt type outbound message.
SAML Audience URI	Relying party, as a comma-separated URI. This property accepts wildcards.
SAML Issuer Name	SAML issuer name to use when trying access a service that is protected using SAML mechanism.
Include User Roles	User roles in a SAML assertion.
Attesting Mapping Attribute	Mapping attribute used to represent the attesting entity. Only the DN is currently supported. This attribute is applicable only to sender vouches message protection use cases. It is not applicable to SAML over SSL policies.

5.1.6 Viewing the WSDL and Imported Schemas

To view the WSDL for the current web service, click WSDL.

To view the imported WSDL and schemas, click Imported WSDL and Schema. From the dialog box, click the imported file that you wish to view. Click x in the upper right corner to close the dialog box.

5.1.7 Configuring the Web Services Test Client

You can configure the Web Services Test Client to define an HTTP proxy, set the default working directory, or define a Java Keystore (JKS).

Note:

Configuration settings are available in development only.

For more information on how to configure web services, refer to the following sections:

• Configuring an HTTP Proxy

• Configuring the JKS Keystores

• Configuring the Default Working Directory

5.1.7.1 Configuring an HTTP Proxy

You configure an HTTP proxy for your Web Services Test Client on the General Settings page.

To configure an HTTP proxy:

1. Click in the upper-right corner of the Web Services Test Client.
2. Click General in the navigation pane.
3. Enter the proxy host in the Http Proxy Host field.
4. Enter the proxy port in the Http Proxy Port field.
5. Click Submit.

5.1.7.2 Configuring the JKS Keystores

You configure the JKS keystores that are associated with the OWSM security policies that you are testing on the Web Services Test Client Security Settings page.

For more information about defining the JKS keystores on WebLogic Server, see "How to Configure a JKS Keystore on WebLogic Server" in Securing Web Services and Managing Policies with Oracle Web Services Manager.

To configure the Java Keystores (JKS):

1. Click in the upper-right corner of the Web Services Test Client.

2. Click Security in the navigation pane.

3. To add a new JKS keystore:

   1. Click Add.

   2. Enter a name for the JKS keystore in the Setting Name field.

   3. Enter the password for the JKS keystore in the Keystore Password field.

      Note:

      Defining the password for the JKS keystore in a production environment is not recommended.

   4. Enter the path to the file in the Keystore File field, or click Choose File to navigate to the file in your local directory.

   5. Click Submit.

4. To edit or delete an existing JKS keystore:

   1. Click Edit.

   2. To delete a JKS keystore, click .

   3. To edit a JKS keystore, click , edit the fields, and click Submit Edit.

   4. To exit edit mode, click Cancel Edit.

5.1.7.3 Configuring the Default Working Directory

You can configure the default working directory for the Web Services Test Client. By default, the working directory is set to the following subdirectory within the domain directory:

<domain-directory>/tmp/WSTestPageWorkDir

To configure the default working directory:

1. Click in the upper-right corner of the Web Services Test Client.
2. Click General in the navigation pane.
3. Edit the Current Working Home field to reflect the desired working home directory.
4. Click Submit.

5.1.8 Editing the Input Arguments as XML Source

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. To view the input argument as XML, click Raw Message. To toggle back to the user-friendly form, click Form Entry.

5.1.9 Viewing the History

You can access the details of the test operations that you have performed from the Invocation History pane.

Note:

The Invocation History pane displays only after you invoke your first test operation and is available in development mode only.

You can view the results for tests executed previously within the current session by clicking on the operation in the Invocation History pane. Failed test instances appear in red in the Invocation History pane.

5.1.10 Exporting and Importing Test Cases

You can export individual test cases from the Web Services Test Client and then import them into another test environment.

Note:

This feature is available in development mode only.

For more information, refer to the following sections:

• Exporting a Test Case

• Importing a Test Case

5.1.10.1 Exporting a Test Case

To export a test case, click in the upper-right corner of the Web Services Test Client. The test case is saved as an XML file using the following filename: ws-testcase.xml. If you save multiple test cases, a suffix is added to the filename as follows: ws-testcase(n).xml, where n is incremented each time a new test case is saved.

5.1.10.2 Importing a Test Case

To import a text case:

1. Click in the upper-right corner of the Web Services Test Client.
2. Click Choose File.
3. Navigate to the test case file, and click Open.

   Click Import.

5.1.11 Enabling and Disabling the Web Services Test Client

In a development environment, the Web Services Test Client is enabled, by default. In a production environment, the Web Services Test Client is disabled (and undeployed), by default.

You can enable or disable the Web Services Test Client in one of the following ways:

• Using the Administration Console, as described below.

• Using Fusion Middleware Control at the domain or web service endpoint level, as described in "Enabling or Disabling the Web Services Test Client Using Fusion Middleware Control" on page 4‐25.

• Using WLST, as described in "Enabling or Disabling the Web Services Test Client Using WLST" on page 4‐58.

You should disable the Web Services Test Client to increase security by reducing the externally visible details of an application that exposes web services.

Note:

It is recommended that you not enable the Web Services Test Client in production mode. For information about production mode, see "Domain Modes" in Understanding Domain Configuration for Oracle WebLogic Server.

To enable or disable the Web Services Test Client at the domain level using the Administration Console:

1. Invoke the Administration Console, as described in "Accessing Oracle WebLogic Administration Console" on page 2‐2.
2. Click Domain in the Domain Configurations section of the console home page.
3. Select Configuration > General to display the general configuration options for the domain.
4. Click Advanced to view the advanced configuration settings.
5. Toggle the Enable Web Service Test Page configuration flag to enable or disable the Web Services Test Client.
6. Click Save.
7. Restart the server so that the configuration settings take effect.

   When enabling the Web Service Test Client in a production environment, the client will be deployed when you restart the server.

5.1.12 Logging Out of the Web Services Test Client

You can log out of the Web Services Test Client at any time by clicking in the upper-right corner of the Web Services Test Client.

5.2 Test Web Service Page in Fusion Middleware Control

You can use the Test Web Service page in Fusion Middleware Control to verify that you are receiving the expected results from a SOAP web service (WSDL) or a RESTful (WADL) service.

Using the Test Web Service page, you can:

• Test basic functionality to ensure that the web service was deployed and is operating as expected.

• Test advanced features, such as web services addressing, reliable messaging, MTOM, and HTTP headers.

• Test security features.

• Stress test the web service endpoint.

The Test Web Service page allows you to test any of the operations exposed by a WSDL or WADL document. 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 or WADL 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 or WADL URL and use the resulting encoded WSDL or WADL URL in the Test Web Service page.

When testing web services that use policies, the OWSM component must be installed in the same domain from which Fusion Middleware Control is being run. Otherwise, an invalid policy exception will be returned.

For more information, refer to the following sections:

• Accessing a Web Service for Testing

• Testing a SOAP Web Service

• Testing an Asynchronous Web Service

• Introduction to Testing a RESTful Web Service

• Testing Security

• Enabling Quality of Service Testing

• Testing HTTP Headers

• Editing the Input Arguments as XML Source

• Stress Testing the Web Service Operation

5.2.1 Accessing a Web Service for Testing

You can navigate to the Test Web Service page in many ways.

The following sections describes two typical ways to access a web service.

Access your web service from the Oracle WebLogic Server Domain Home page

1. In the navigation pane, expand WebLogic Domain to show the domain in which you want to test a web service.

2. Select the domain.

3. From the WebLogic Domain menu, select Web Services, and then Test Web Service. The Test Web Service input page appears.

4. Enter the WSDL or WADL URL of the web service you want to test. If you do not know the WSDL or WADL, click the search icon and select from the registered web services, if any.

5. Click Parse WSDL or WADL.

   If the WSDL or WADL is secured with HTTP Basic Authentication, click HTTP Basic Auth Option for WSDL or WADL Access and enter the username and password before parsing the WSDL or WADL.

   The complete Test Web Services page displays, as shown in Figure 5–1 for a WSDL and in Figure 5–8 for a WADL.

Access your web service from the Web Service Application Home page

1. In the navigation pane, expand Application Deployments to view the applications in the domain.
2. Select the application for which you want to test the web service.
3. In the Web Services section of the page, click Test for the web service endpoint you want to test.

   The Test Web Service page displays, as shown in Figure 5–1 for a WSDL and in Figure 5–8 for a WADL. Note that the WSDL or WADL field is automatically populated with the WSDL or WADL for the endpoint.

5.2.2 Testing a SOAP Web Service

When the Test Web Services page refreshes with the WSDL details for the SOAP web service, you can select the Service, Port, and Operation type that you want to test, as well as specify a variety of input parameters.

To test a SOAP Web Service:

1. Access the Test Web Service page using one of the methods described in Section;5.3.1, "Accessing a Web Service for Testing."
2. Click Parse WSDL or WADL.

   If the WSDL is secured with HTTP Basic Authentication, click HTTP Basic Auth Option for WSDL or WADL Access and enter the username and password before parsing the WSDL.

   Figure 5-1 Test Web Service Page for a WSDL – Collapsed View

   
   

   
   Description of "Figure 5-1 Test Web Service Page for a WSDL – Collapsed View"

   
   
3. Select the service and port to be tested. As shown in Figure;5–1, 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.
4. Select the operation that you want to test from the Operation menu. The available operations are determined from the WSDL.
5. If you want to change the endpoint URL of the test, click Edit Endpoint URL and edit the URL.
6. Select the Request tab if it is not already selected.
7. Expand the test option sections. The expanded view of the Test Web Service page is shown in Figure;5–2.

   Figure 5-2 Bottom Portion of Test Web Service Page for a WSDL – Expanded View

   
   

   
   Description of "Figure 5-2 Bottom Portion of Test Web Service Page for a WSDL – Expanded View"

   
   
8. In the Security section, specify whether you want to test a web service using OWSM security policies, basic HTTP authentication, authentication from a custom policy, or no credentials. The security setting is not determined from a policy in the WSDL; you can specify the type of security you want to test. The default is None. Depending on the option selected, additional fields are displayed. For details about the options available, see Section;5.3.5, "Testing Security."
9. 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" on page;5‐37.
10. In the HTTP Header section, you can add, modify, or delete HTTP headers to pass request information to a web service. For more information, see "Testing HTTP Headers" on page;5‐37.
11. 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" on page;5‐38.

    Note:

    The Asynchronous Test Response and Response Key fields are unique for testing asynchronous web services. For more information, see Section;5.3.3, "Testing an Asynchronous Web Service".

12. 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.

    For SOAP web services, you can save the payload as XML and can load a previously saved payload. Click Save Payload to save the current payload as an XML file on your local file system. To load a saved payload, click Browse to find and select one, or click Update to replace the currently loaded payload. (Browse is replaced by Update when a saved payload is loaded.)

13. 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;5–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.

    Figure 5-3 Successful Test for a WSDL

    
    

    
    Description of "Figure 5-3 Successful Test for a WSDL"

    
    

    If the test fails, an error message is displayed. For example, Figure;5–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.

14. 
    

    Figure 5-4 Data Validation Error

    
    

    
    Description of "Figure 5-4 Data Validation Error"

    
    

5.2.3 Testing an Asynchronous Web Service

When the Test Web Services page refreshes with the WSDL details for an asynchronous web service, it is nearly identical to the Test Web Services page for a SOAP web service, except that Additional Test Options are available.

• Asynchronous Test Response – Specifies whether to request an asynchronous response upon running the test.

• Response Key – Enter a value (for example, myasynctest), which will correlate with the test's asynchronous response. Each response key must be unique. The asynchronous response can also be tracked later on the Asynchronous Test Response page by specifying the corresponding response key.

Figure 5-5 Asynchronous Testing Options on the Test Web Service Page

Description of "Figure 5-5 Asynchronous Testing Options on the Test Web Service Page"

If the test is successful, the Test Status field indicates Request Successfully received with the response time. The user-defined Response Key value that corresponds with the asynchronous response is also displayed.

Click Show Response to display the test response, if a response exists, in the Response field in XML format, as shown in Figure 5–6.

Figure 5-6 Successful Test and Response for an Asynchronous Web Service

Description of "Figure 5-6 Successful Test and Response for an Asynchronous Web Service"

Note:

An asynchronous request can only have a response if the server has not been restarted.

If the response is not available, it can also be tracked later on the Asynchronous Test Response page by using the corresponding response key.

Accessing an asynchronous test response after testing

1. In the navigation pane, expand WebLogic Domain to show the domain in which you want to access an asynchronous web service test response.
2. Select the domain.
3. From the WebLogic Domain menu, select Web Services, and then Asynchronous Test Response.
4. On the Asynchronous Test Response page, specify the corresponding response key by either:

   • Using the Response Key List to select an existing, user-defined response key.

   • Using Search Response Key field to search for an existing, user-defined response key.

5. Click Show Response to display the test response, if a response exists, in the Response field in XML format.

   Figure 5-7 Asynchronous Test Response page showing a test response

   
   

   
   Description of "Figure 5-7 Asynchronous Test Response page showing a test response"

   
   

   Note:

   An asynchronous request can only have a response if the server has not been restarted.

6. Repeat step 4 to access and view any other asynchronous test responses that have a response key.

5.2.4 Introduction to Testing a RESTful Web Service

The Web Application Description Language (WADL) is an XML-based file format that describes a RESTful web services application.

When the Test Web Services page refreshes with the WADL details for the RESTful web service, it is similar to the Test Web Services page for a WSDL, except that you can select the Resource, Method, and Media type that you want to test. You can also specify a variety of input parameters, though for this release they are more limited compared to a WSDL page.

• Testing a RESTful Web Service

• The WebRestApp1 Web Service

• The Mime_Multipart_rs Web Service

5.2.4.1 Testing a RESTful Web Service

Access the Test Web Service page to test RESTful web services.

To test a RESTful web service:

1. Access the Test Web Service page using one of the methods described in Section 5.3.1, "Accessing a Web Service for Testing."
2. Click Parse WSDL or WADL.

   If the WADL is secured with HTTP Basic Authentication, click HTTP Basic Auth Option for WSDL or WADL Access and enter the username and password before parsing the WADL.

   Figure 5-8 Test Web Service Page for a WADL

   
   

   
   Description of "Figure 5-8 Test Web Service Page for a WADL"

   
   
3. Select the resource and method type to be tested. The Method field displays the corresponding HTTP method for the selected resource path in the Resource field

   If the WADL has multiple resources methods, these fields are available as drop-down menus, as shown in Figure;5–8. If the WADL has only one resource and method, these fields are read-only.

   Note:

   Only the GET and POST methods are supported in this release. (Other methods are ignored if they are present in the WADL.)

4. Select the MIME media type that you want to use for the test request from the Representation Media Type for Request menu. The available types, if one exists, are determined from the WADL.
5. Select the MIME media type that you want to use for the test response from the Representation Media Type for Response menu. The available types, if one exists, are determined from the WADL. The following media types are supported in this release:

   • application/xml

   • application/json

   • text/plain

   • text/xml

   • application/x-www-form-urlencoded

6. Select the Request tab if it is not already selected.
7. In the Security section, the options are OWSM Security Policies, HTTP Basic Authentication, and None. The default is None. For more information, see "Testing Security" on page;5‐31.
8. In the HTTP Header section you can add, modify, or delete HTTP headers to pass request information to a RESTful web service. For more information, see "Testing HTTP Headers" on page;5‐37.
9. In the Input Arguments section, enter the input arguments for the RESTful web service in the Value fields. The parameters and type and the required input values, are determined from the WADL. The Style column enables you to visualize REST services with input parameters of the following, different styles:

   • Template: Parameters that parameterize the path to a REST request. (RESOURCE level only).

   • Matrix: Parameters that define parameters to be added to the actual path of the resource, but preceding the query string.

   • Query: Parameters that are appended to the path of the URL when submitting a request (most common parameter type). For example, you typically see them added to the path after the ‘?' in a GET HTTP request or as a Key value pair in the request body of the POST and PUT request as part of HTML form submit.

   • Header: Parameters that are added to the out-going headers of a HTTP request.

   Style values are determined by your Resource and Method menu selections.

   Select Tree View or Raw View to toggle between a hierarchical list of input parameters and the raw data view, where you can provide input directly to the request Header and Body sections.

   Note:

   Tree View is available only for GET methods.

10. Click Test Web Service to initiate the test.

    The test results appear in the Response tab upon completion. A message and an icon indicates the status of the response: a green flag for success, a red flag for failure, and a yellow flag for not yet executed.

    If the test is successful, the Test Status field indicates Request Successfully received, with the green flag, and the response time is displayed, as shown in Figure;5–9.

    Figure 5-9 Successful Test for a WADL

    
    

    
    Description of "Figure 5-9 Successful Test for a WADL"

    
    

    Only the Raw View is available on the Response tab, which will display the entire response from the request invocation.

    If the test fails, an error message is displayed. For example, Figure;5–10 shows an error resulting from a type error.

11. 
    

    Figure 5-10 Data Validation Error

    
    

    
    Description of "Figure 5-10 Data Validation Error"

    
    

5.2.4.2 The WebRestApp1 Web Service

You can view and manage token issuer trust configurations using a set of representational state transfer (REST) resources.

The following table lists the REST Resources for WebRestApp1.

Resource	Method	Resource Path
persons	GET	rest/persons
headerGetPerson	GET	rest/headerGetPerson
person{id}	GET	rest/person/{id}
personMatrixAdd	POST	rest/personMatrixAdd
personXXXAdd	POST	rest/personXXXAdd
personPathAdd	POST	rest/personPathAdd/{id}
headerAddPerson	POST	rest/headerAddPerson
personQueryAdd	POST	rest/personQueryAdd
personAddForm	POST	rest/personAddForm
personQueryDefaultAdd	POST	rest/personQueryDefaultAdd
persondelete	DELETE	rest/persondelete
personUpdate	PUT	rest/personUpdate
verifyPart1	POST	rest/verifyPart1

5.2.4.2.1 GET persons Method

REST Request

Use the GET method to view all created persons.

GET rest/persons

Input Parameters

None.

Response

Media Type	Result
application/xml	first_name, last_name, ph_no and ID of all available persons created, in XML format
application/json	first_name, last_name, ph_no and ID of all available persons created, in Json format

5.2.4.2.2 GET headerGetPerson Method

Use the GET method to view the header details for a person with specified firstname.

REST Request

GET rest/headerGetPerson

Input Parameters

Create a HTTP header with name/value as “fname/<firstname>".

Response

Media Type	Result
application/xml	first_name, last_name, ph_no and ID of thefname entered in header, in XML format
application/json	first_name, last_name, ph_no and ID of thefname entered in header, in Json format

5.2.4.2.3 GET person{id} Method

Use the GET method to view a person with specified ID.

REST Request

GET rest/person/{id}

Input Parameters

Enter the id of the person to be searched.

Response

Media Type	Result
application/xml	all the details of ID entered in inputparameters, in XML format
application/json	all the details of ID entered in inputparameters, in Json format

5.2.4.2.4 POST personMatrixAdd Method

Use the POST method to create a new person and details.

REST Request

POST rest/personMatrixAdd

Input Parameters

Enter string values for FirstName and LastName, Integer values for ID and Phone_no.

Response

Media Type	Result
application/xml	first_name, last_name, ph_no and ID ofperson created, in XML format
application/json	first_name, last_name, ph_no and ID ofperson created, in Json format

5.2.4.2.5 POST personXXXAdd Method

Use the POST method to create a person's details.

REST Request

POST rest/personXXXAdd

Input Parameters

Input parameters depend on the media type:

• When selecting application/vnd.xxx+xml for request media type:

  <person> <firstname>Firstname 12345/<firstname> <id>12345/id <lastname>Last 12345/lastname <phone_no>12345/phone_no/<person>

• When selecting application/vnd.xxx+json for request media type: {"firstname":"cc","id":14,"lastname":"cc","phone_no":14} <person>

Response

Text message to confirm person has been added.

5.2.4.2.6 POST personPathAdd Method

Use the POST method to create a person with details.

REST Request

POST rest/personPathAdd/{id}/{fname}/{lname}/{phno}

Input Parameters

Enter string values for FirstName and LastName, Integer values for ID and Phone_no.

Response

Text message to confirm person has been added.

5.2.4.2.7 POST headerAddPerson Method

Use the POST method to create an HTTP header with person details.

REST Request

POST rest/headerAddPerson

Input Parameters

Create a HTTP header with name/value as:

“fname = <firstname>"

“lname = <lastname>"

“phone_no = <phone_no>"

“id = <id>"

Response

Media Type	Result
application/xml	first_name, last_name, ph_no and ID ofperson created in XML format
application/json	first_name, last_name, ph_no and ID ofperson created in Json format

Text message to confirm person has been added.

5.2.4.2.8 POST personQueryAdd Method

Use the POST method to create a person with details.

REST Request

POST rest/personQueryAdd

Input Parameters

Enter string values for FirstName and LastName, Integer values for ID and Phone_no.

Response

Text message to confirm person has been added.

5.2.4.2.9 POST personAddForm Method

Use the POST method to create a person with details.

REST Request

POST rest/personAddForm

Input Parameters

Enter string values for FirstName and LastName, Integer values for ID and Phone_no.

Response

Text message to confirm person has been added.

5.2.4.2.10 POST personQueryDefaultAdd Method

Use the POST method to create a new person and details.

REST Request

POST rest/personQueryDefaultAdd

Input Parameters

This method may be invoked with or without input parameters specified.

• Enter string values for FirstName and LastName, Integer values for ID and Phone_no.

• Keep all the values blank and invoke the test; default values are picked up and person is created

Response

Media Type	Result
application/xml	first_name, last_name, ph_no and ID ofperson created, in XML format
application/json	first_name, last_name, ph_no and ID ofperson created, in Json format

5.2.4.2.11 DELETE persondelete Method

Use the DELETE method to delete a specified person.

REST Request

DELETE rest/persondelete

Input Parameters

Enter the id of the person to be deleted.

Response

Text message to confirm person has been deleted.

5.2.4.2.12 PUT personUpdate Method

Use the PUT method to update details for a specified person.

REST Request

PUT rest/personUpdate

Input Parameters

Enter the id of the person to be updated and make changes to other input variables.

Response

Text message to confirm person has been deleted.

5.2.4.2.13 POST verifyPart1 Method

Use the POST method to send content as parts.

REST Request

POST rest/verifyPart1

Input Parameters

Create PARTs under Control, then Actions, as follows:

1. Enter part name as “part1" and part content as “part1_contents". Click OK.

2. Select File from Input mode. Enter part name as “part2" and browse for any file.

   Click OK.

Response

Result contains the number of parts sent and details about each part.

5.2.4.3 The Mime_Multipart_rs Web Service

You can view and manage greeting string multipart configurations using a set of representational state transfer (REST) resources, as summarized below.

Resource	Method	Resource Path
greetingsMultipart	POST	/hello/greetingsMultipart
greetings	GET	/hello/{greetings}
greetingsImagePOST	POST	/hello/greetingsImagePOST
greetings_matrix_to	GET	/hello/greetings_matrix_to
greetings_query_to	GET	/hello/greetings_query_to
greetingsMsg	GET	/hello/greetingsMsg
greetingsImagePOST1	POST	/hello/greetingsImagePOST1
greetingsMsgQP	POST	/hello/greetingsMsgQP
hello	GET	/hello

5.2.4.3.1 POST greetingsMultipart Method

Use the POST method to send content as parts.

REST Request

POST /hello/greetingsMultipart

Input Parameters

Create PARTs under Control, then Actions, as follows:

1. Enter part name as “part1" and part content as “part1_contents". Click OK.

2. Select File from Input mode. Enter part name as “part2" and browse for any file.

   Click OK.

Response

Click the “Click the download response content" button. The text file shows the response.

5.2.4.3.2 GET greetings Method

Use the GET method to view a greeting string.

REST Request

GET /hello/{greetings}

Input Parameters

Enter a string value for greetings.

Response

Click the “Click the download response content" button. The text file shows the response with the contents of the input you entered.

5.2.4.3.3 POST greetingsImagePOST Method

Use the POST method to add an image file.

REST Request

POST /hello/greetingsImagePOST

Input Parameters

Browse and add a .png image file.

Response

Click the “Click the download response content" button. The text file shows the response with the image file contents.

5.2.4.3.4 GET greetings_matrix_to Method

Use the GET method to view a greeting string.

REST Request

GET /hello/greetings_matrix_to

Input Parameters

Enter a string value for greetings.

Response

Click the “Click the download response content" button. The text file shows the response with the contents of the input you entered.

5.2.4.3.5 GET greetings_query_to Method

Use the GET method to view a greeting string.

REST Request

GET /hello/greetings_query_to

Input Parameters

Enter a string value for greetings.

Response

Click the “Click the download response content" button. The text file shows the response with the contents of the input you entered.

5.2.4.3.6 GET greetingsMsg Method

Use the GET method to view a greeting string.

REST Request

GET /hello/greetingsMsg

Input Parameters

Enter a string value for greetings in the contents text area.

Response

The response shows the contents of the input you entered.

5.2.4.3.7 POST greetingsImagePOST1 Method

Use the POST method to add an image file.

REST Request

POST /hello/greetingsImagePOST1

Input Parameters

Browse folders and add an image file.

Response

Verify that the attached file size is returned.

5.2.4.3.8 POST greetingsMsgQP Method

Use the POST method to add an image file.

REST Request

POST /hello/greetingsMsgQP

Input Parameters

Enter a string value for greetings.

Response

Click the “Click the download response content" button. The text file shows the response with the image file contents.

5.2.4.3.9 GET hello Method

Use the GET method to view a greeting string.

REST Request

GET /hello

Input Parameters

None.

Response

Click the “Click the download response content" button. The text file contains the response.

5.2.5 Testing Security

You can use the Test Web Service Page to test web services security using OWSM security policies, HTTP basic authentication, or custom policies including copies of predefined policies. You can choose the type of test by selecting one of the options in the Security section of the page.

The security setting is not determined from a policy in the WSDL or WADL; you can specify the type of security you want to test. The default is None.

The following options are available. They are described in more detail in subsequent sections:

• OWSM Security Policies– Uses the credentials and other security options required by the OWSM security policies for authentication and message protection.

  The options available when you select OWSM Security Policies differ slightly, depending on whether you are testing a RESTful web service or a SOAP web service, as described later in this section.

• HTTP Basic Auth – Inserts the username and password credentials in the HTTP transport header. Both the username and password are required.

  If you do specify a username and password, they must exist and be valid.

• Advanced – Uses a custom policy to authenticate the user. All user defined or non-default OWSM policies, and the copies of the default policies are termed as custom policies. You must specify the URI for the policy. You can also specify configuration overrides.

  Note:

  This option is not available for RESTful web services.

• None – No credentials are included.

5.2.5.1 OWSM Security Policies

Only a subset of the OWSM predefined policies is available, and you can configure only the attributes presented for those policies. All of the other policy attributes use the policy defaults. For example, you cannot enable Secure Conversation, change the message security algorithm suite, and so forth.

Note:

For a list of client policies supported by the test function, see "Supported Client Security Policies for SOAP Services" on page 5‐36 and "Supported Client Security Policies for RESTful Services" on page 5‐37.)

Non-security policies and policies not supported by the test function are shown as read-only and cannot be selected. If a service has service policies whose corresponding client policies are not supported, including copies, those policies are shown as read only. This means that copies you made of the predefined policies are not directly listed and are available only through the Advanced option.

For example, assume that your web service has a copy of the oracle/wss11_message_protection_service_policy policy attached, and you have made a copy of the oracle/wss11_message_protection_client_policy. The test client displays both the oracle/wss11_message_protection_client_policy and oracle/wss11_message_protection_client_policy_copy policies, but the oracle/wss11_message_protection_client_policy_copy policy is unavailable and grayed out.

You can choose one of two approaches:

• If for testing purposes the predefined oracle/wss11_message_protection_client_policy policy satisfies your requirements, select the oracle/wss11_message_protection_client_policy.

  The JKS Keystore Location and JKS Keystore Password fields are required and presented on the page. Enter the location and password and click Load Keys.

• If you want to use your own oracle/wss11_message_protection_client_policy_copy policy:

  1. Select Advanced.

  2. Enter the policy URI, in this case oracle/wss11_message_protection_client_policy_copy.

  3. For message protection and SSL policies, the JKS Keystore Location and JKS Keystore Password properties are required.

     Enter the JKS keystore location and password values using the full property names from "Client Policy Configuration Properties That Can Be Overridden at Design Time" in Securing Web Services and Managing Policies with Oracle Web Services Manager:

     oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_LOCATION
     oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_PASSWORD

5.2.5.2 SOAP and RESTful OWSM Security Policies

The options available when you select OWSM Security Policies differ slightly, depending on whether you are testing a SOAP web service or a RESTful web service.

The options for a SOAP web service are shown in Figure 5–11. The options for a RESTful web service are shown in Figure 5–12, with the Advanced Options field selected to display all of the available fields.

Figure 5-11 OWSM Security Policies Test Options for SOAP Web Services

Description of "Figure 5-11 OWSM Security Policies Test Options for SOAP Web Services"

Figure 5-12 OWSM Security Policies Test Options for RESTful Web Services

Description of "Figure 5-12 OWSM Security Policies Test Options for RESTful Web Services"

To test the web service security using OWSM security policies:

1. Select the policies with which you want to test the service. The policies available differ, depending on whether you are testing a SOAP web service or a RESTful web service.

   • Selecting Policies for Testing a SOAP Web Service

     From the Compatible Client Policies list, which displays the compatible client policies as specified in the WSDL, select the client policy to test.

     Alternatively, to perform a negative test on the endpoint, you can select a non-compatible policy, or All from the Other Client Policies list.

   • Selecting Policies for Testing a RESTful Web Service

     From the Client Policies list, select the client policy to test.

   The Configuration Properties required by the selected policy are indicated with an asterisk (*). For example:

   • For username_token and http_token policies, the Username and Password fields are required; for SAML policies only the Username field is required.

   • For message protection and SSL policies, the JKS Keystore Location and JKS Keystore Password fields are required. (The KSS keystore is not supported.)

2. Provide values for the required fields as determined by the policy.

   If the JKS Keystore Location and JKS Keystore Password fields are required by the policy, enter the location and password of a user-created keystore that is NFS accessible and click Load Keys. The associated keystore fields under Advanced Options are populated with the aliases specified in the keystore.

   For more information about creating a keystore, see "Generating Private Keys and Creating the Java Keystore" in Securing Web Services and Managing Policies with Oracle Web Services Manager.

3. Click Advanced Options. Additional keystore alias and SAML properties fields are displayed. Properties required by the selected policies are indicated with an asterisk. Enter the required values, or provide override values in the applicable fields.

5.2.5.3 HTTP Basic Auth

This option requires Username and Password credentials that are inserted into the HTTP transport header. The username and password must exist and be valid for the WebLogic Server.

5.2.5.4 Advanced

Note:

The Advanced option is not available for RESTful web services.

The options available when you select the Advanced option are shown in Figure 5–13.

Figure 5-13 Advanced Test Options

Description of "Figure 5-13 Advanced Test Options"

The Advanced option allows you to use a custom policy, including a copy of a predefined policy, to test the web service security. To do so:

1. Specify the URI of the custom policy in the Policy URI field. For example, oracle/wss11_message_protection_client_policy_copy. This field is required.

2. Specify any configuration overrides for the policy in the Name and Value fields.

   For username_token and http_token policies, Username and Password properties are required; for SAML policies only the username property is required.

   For message protection and SSL policies, the JKS Keystore Location and JKS Keystore Password properties are required. (The KSS keystore is not supported.)

   To add properties, click Add and provide the name/value pair for the configuration override. To delete a property, select it in the table and click Delete.

   Note:

   Properties must be specified using the full name of each property, for example oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_LOCATION. For a complete list of property names for properties that can be overridden, see "Overriding Client Policy Configuration Properties at Design Time" in Securing Web Services and Managing Policies with Oracle Web Services Manager.

   All of the other policy attributes use the policy defaults. For example, if you enabled Secure Conversation or changed the message security algorithm suite, those policy values are used.

5.2.5.5 Supported Client Security Policies for SOAP Services

The following OWSM client security policies SOAP services are supported by the test function. Copies of these predefined policies are not directly listed and are available only through the Advanced option.

• oracle/wss_http_token_client_policy

• oracle/wss_http_token_over_ssl_client_policy

• oracle/wss_saml_token_bearer_over_ssl_client_policy

• oracle/wss_saml_token_over_ssl_client_policy

• oracle/wss_saml20_token_bearer_over_ssl_client_policy

• oracle/wss_saml20_token_over_ssl_client_policy

• oracle/wss_username_token_client_policy

• oracle/wss_username_token_over_ssl_client_policy

• oracle/wss10_message_protection_client_policy

• oracle/wss10_saml_token_with_message_integrity_client_policy

• oracle/wss10_saml_token_with_message_protection_client_policy

• oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

• oracle/wss10_saml20_token_with_message_protection_client_policy

• oracle/wss10_username_id_propagation_with_msg_protection_client_policy

• oracle/wss10_username_token_with_message_protection_client_policy

• oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

• oracle/wss10_x509_token_with_message_protection_client_policy

• oracle/wss11_message_protection_client_policy

• oracle/wss11_saml_token_identity_switch_with_message_protection_client_policy

• oracle/wss11_saml_token_with_message_protection_client_policy

• oracle/wss11_saml20_token_with_message_protection_client_policy

• oracle/wss11_username_token_with_message_protection_client_policy

• oracle/wss11_x509_token_with_message_protection_client_policy

5.2.5.6 Supported Client Security Policies for RESTful Services

The following OWSM client security policies for RESTful services are supported by the test function:

• oracle/http_basic_auth_over_ssl_client_policy

• oracle/http_saml20_token_bearer_client_policy

• oracle/http_saml20_token_bearer_over_ssl_client_policy

• oracle/wss_http_token_client_policy

• oracle/http_jwt_token_client_policy

• oracle/http_jwt_token_over_ssl_client_policy

5.2.6 Enabling Quality of Service Testing

Three characteristics of Quality of Service (QoS) can be tested: Web services reliable messaging (WS-RM), WS-Addressing, and MTOM in the Quality of Service section of the Test Web Service Page.

Note:

This section is not applicable when testing RESTful web services.

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 5-14 Quality of Service Parameters on the Test Web Service Page

Description of "Figure 5-14 Quality of Service Parameters on the Test Web Service Page"

5.2.7 Testing HTTP Headers

The HTTP Header section allows you to add, modify, or delete HTTP headers to pass request information to a SOAP or RESTful web service.

After the service invocation, the HTTP headers should be displayed as part of the message response.

Figure 5-15 HTTP Header on the Test Web Service Page

Description of "Figure 5-15 HTTP Header on the Test Web Service Page"

5.2.8 Editing the Input Arguments as XML Source

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.

Figure 5-16 Input Arguments - XML View

Description of "Figure 5-16 Input Arguments - XML View"

Figure 5-17 Input Arguments - Tree View

Description of "Figure 5-17 Input Arguments - Tree View"

5.2.9 Stress Testing the Web Service Operation

Select the Enable Stress Test check box (Figure 5–18) to invoke a continuous series of invocations of the web service operation (Figure 5–18). 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 5-18 Stress Testing Parameters on the Test Web Service Page

  
  

  
  Description of "Figure 5-18 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 5-19 Stress Test Results on Test Web Service Page

Description of "Figure 5-19 Stress Test Results on Test Web Service Page"