Generic service client overview
The purpose of the generic service client is to invoke calls to any kind of service that uses an HTTP, JMS or WebSphere MQ transport and to view the message 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 invoke the service call. You can set up a large variety of transport and security configurations for the service, edit the parameters of the call and send attachments.
When a request is successfully invoked, its message return is added to the Call History. You can use this feature to look back at results that were produced at different times.
You can select calls in the Call History and click Generate Test to generate a test that will replay all the selected calls. You can edit the test to replace recorded test values with variable test data, or add dynamic data to the test. You can also set verification points on the contents of the XML documents in the message returns.
Supported services
The generic service client enables you to invoke requests for many types of services that use the following transport protocols:
- HTTP
- JMS, including JBoss and WebSphere implementations
- WebSphere MQ
Encryption and security
The Java Runtime Environment (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, download and apply the unlimited jurisdiction policy files (local_policy.jar and US_export_policy.jar).
You can download unlimited jurisdiction policy files from this site: http://www.ibm.com/developerworks/java/jdk/security/50/
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/ directory with the unlimited jurisdiction policy files.
If you are deploying tests to remote computers, these files must also be added to the JRE used by the IBM Agent Controller.
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.
If you want 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. You must 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, you must 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 Agent Controller uses.
Web service attachments
The product enables you to send SOAP Messages with Attachments (SwA) and Message Transmission Optimization Mechanism (MTOM) attachments. To use Web service attachments, add the following Java libraries to the JRE that the workbench uses:
- mail.jar
- activation.jar
These files are provided with RPTv8. See Configure the environment for handling file attachments for more information.
If you are deploying tests to agent computers, the library files must also be added to the JRE that the Rational Agent Controller uses.
Limitations
Arrays are not supported.
Because of a lack of specification, attachments are not supported with the Java Message Service (JMS) transport. The envelope is directly sent using UTF-8 encoding.
All security algorithms are not always available for each Java Runtime Environment (JRE) implementation. If a particular security implementation is not available, add the required libraries to the class path of the JRE that Rational Performance Tester 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.
Related tasks
Invoke a call with a WSDL file Invoke an HTTP endpoint call Invoke a JMS endpoint call Invoke a WebSphere MQ endpoint call Opening file attachments Create an SSL configuration Create a WebSphere MQ transport configuration Create an HTTP transport configuration Create a JMS transport configuration Configure the environment for SOAP security