Generic service client overview
The purpose of the generic service client is to send requests to any service that uses an HTTP, JMS, WebSphere MQ, or Microsoft .NET transport. The generic service client also displays the response returned by the service.
The generic service client is useful for debugging or testing a service when you do not have access to a dedicated client to send the request. You can...
- set up a large variety of transport and security configurations for the service
- edit the parameters of the request
- send attachments
When a request is successfully invoked, its message return is added to the Request History.
If you are using IBM Rational Performance Tester or IBM Rational Service Tester for SOA Quality, you can...
- Select requests in the Request History
- Click Generate Test to generate a test that will replay all the selected requests
You can edit the test to replace recorded test values with variable test data, or add dynamic data correlation to the test. You can also set verification points on the contents of the XML documents in the service response.
Supported services
The generic service client sends requests for services using the following transport protocols:
- HTTP
- JMS, including JBoss and WebSphere implementations
- WebSphere MQ
- Microsoft .NET Framework Windows Communication Foundation (WCF).
If you are using IBM Rational AppScan, only the HTTP transport protocol is supported.
Encryption and security
The JRE that the workbench uses must support the level of encryption required by the digital certificate that you select. For example, you cannot use a digital certificate that requires 256-bit encryption with a JRE that supports only 128-bit encryption. By default, the workbench is configured with restricted or limited strength ciphers. To use less restricted encryption algorithms, you must download and apply the unlimited jurisdiction policy files...
- local_policy.jar
- US_export_policy.jar
Click on IBM SDK Policy files, and then log in to developerWorks to obtain the unlimited jurisdiction policy files. Before installing these policy files, back up the existing policy files in case to restore the original files later. Then overwrite the files in...
-
/jre/lib/security/
...with the unlimited jurisdiction policy files.
SSL Authentication
Service tests support simple or double SSL authentication mechanisms:
-
Simple authentication (server authentication): In this case, the test client needs to determine whether the service can be trusted. You do not need to setup a key store. If you select the Always trust option, you do not need to provide a server certificat key store.
To really authenticate the service, you can configure an certificate trust store, which contains the certificates of trusted services. In this case, the test will expect to receive a valid certificate.
-
Double authentication (client and server authentication): In this case, the service needs to authenticate the test client according to its root authority. Provide the client certificate keystore that needs to be produced to authenticate the test as a certified client.
When recording a service test through a proxy, the recording proxy sits between the service and the client. In this case, configure the SSL settings of the recording proxy to authenticate itself as the actual service to the client (for simple authentication), and as the client to the service (for double authentication). This means that supply the recording proxy with the adequate certificates.
When using stub services, you can also configure the SSL settings of the stub service to authenticate itself as the actual server. This means that supply the service stub with the adequate certificate.
Digital certificates
You can test services with digital certificates for both SSL and SOAP security protocol. Digital certificates must be contained in Java Key Store (JKS) keystore resources that are accessible in the workspace.
When dealing with keystore files, set the password required to access the keys both in the security editor and the test editor.
For SOAP security you might have to provide an explicit name for the key and provide a password to access the private keys in the keystore.
If you are deploying tests to agent computers, these files must also be added to the JRE that the IBM Agent Controller uses.
Arrays are not supported.
Because of a lack of specification, attachments are not supported with the JMS transport. The envelope is directly sent using UTF-8 encoding.
All security algorithms are not always available for every JRE implementation. If a particular security implementation is not available, add the required libraries to the class path of the JRE that this product uses.
The generic service tester displays the envelope as reflected in the XML document. However, security algorithms consider the envelope as a binary. Therefore, set up the SOAP security configuration so that incoming and outgoing messages are correctly encrypted but remain decrypted inside the test.
The Microsoft .NET transport protocol does not support transactions, scopes, or duplex mode requests such as callbacks or two-way services based on the MS-MQ transport.
Send service requests with WSDL files
Send HTTP endpoint requests
Send a JMS endpoint request
Send a WebSphere MQ endpoint request
Test all operations in a WSDL file
View message content
Synchronize a remote WSDL file
Add static XML headers to a service request
Open file attachments
Create SSL configurations
Create a WebSphere MQ transport configuration
Create an HTTP transport configuration
Create a JMS transport configuration
Create Microsoft .NET transport configurations
Configure the environment for SOAP security
Error 404 - Not Found
The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.