Il client di servizio generico è utile per eseguire il debug o il test di un servizio, quando non si dispone dell'accesso ad un client dedicato per inviare la richiesta. È possibile configurare una grande varietà di configurazioni di trasporto e di sicurezza per il servizio, modificare i parametri della richiesta ed inviare allegati.
Quando una richiesta viene richiamata correttamente, la restituzione del messaggio viene aggiunta alla Cronologia richieste. È possibile utilizzare questa funzione per guardare i risultati prodotti in momenti differenti.
Se si sta utilizzando IBM® Rational Performance Tester o IBM Rational Service Tester for SOA Quality, è possibile selezionare le richieste in Cronologia richieste e fare clic su Genera test per generare un test che riprodurrà tutte le richieste selezionate. È possibile modificare il test per sostituire i valori di test registrati con i dati di test variabili o aggiungere una correlazione di dati dinamici al test. È possibile anche impostare i punti di verifica sui contenuti dei documenti XML nella risposta di servizio.
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, you must 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 you want to restore the original files later. Then overwrite the files in /jre/lib/security/ directory with the unlimited jurisdiction policy files.
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, you must 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 you must 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 you must supply the service stub with the adequate certificate.
The product supports Microsoft NT LAN Manager (NTLMv1 and NTLMv2) and Kerberos authentication. The authentication information is recorded as part of the test during the recording phase.
To enable NTLMv2 support, you must add a third party library to the workbench. For more information, see Configurazione del workbench per l'autenticazione NTLMv2.
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.
Gli array non sono supportati.
A causa di una mancanza di specifiche, gli allegati non sono supportati con il trasporto JMS(Java Message Service). L'envelope viene inviato direttamente mediante la codifica UTF-8.
Tutti gli algoritmi di sicurezza non sono sempre disponibili per ogni implementazione JRE (Java Runtime Environment). Se una determinata implementazione di sicurezza non è disponibile, aggiungere le librerie richieste al percorso della classe di JRE utilizzata dal prodotto.
Il tester di servizio generico visualizza l'envelope come riportato nel documento XML. Tuttavia, gli algoritmi di sicurezza considerano l'envelope come binario. Quindi, è necessario impostare la configurazione della sicurezza SOAP in modo tale che i messaggi in entrata e in uscita siano crittografati correttamente ma restino decrittografati nel test.
Il protocollo di trasporto Microsoft .NET non supporta le transazioni, gli ambiti o le richieste in modalità duplex quali i callback o i servizi bidirezionali basati sul trasporto MS-MQ.