Présentation du client de service générique

L'objectif du client de service générique est d'envoyer des demandes à tout service utilisant un transport HTTP, JMS, WebSphere MQ, ou Microsoft .NET. Le client de service générique affiche également la réponse renvoyée par le service.

Le client de service générique est utile pour déboguer ou tester un service lorsque vous n'avez pas accès à un client dédié pour envoyer la demande. Vous pouvez configurer une large gamme de configurations de transport et de sécurité pour le service, modifier les paramètres de la demande et envoyer des pièces jointes.

Lorsqu'une demande aboutit, son retour de message est ajouté à l'historique des demandes. Vous pouvez utiliser cette fonction pour revenir à des résultats générés à différents moments.

Si vous utilisez IBM® Rational Performance Tester ou IBM Rational Service Tester for SOA Quality, vous pouvez sélectionner des demandes dans l'Historique des demandes et cliquer sur Générer un test pour générer un test qui exécutera toutes les demandes sélectionnées. Vous pouvez éditer le test pour remplacer les valeurs test enregistrées par des données de test variables ou ajouter une corrélation de données dynamiques au test. Vous pouvez également définir des points de vérification en fonction du contenu des documents XML dans le retour du service.

Services pris en charge

Le client de service générique vous permet d'envoyer des demandes pour de nombreux types de services utilisant les protocoles de transport suivants :
  • HTTP
  • JMS (Java™ Message Service), y compris les implémentations JBoss et WebSphere
  • WebSphere MQ
  • Microsoft .NET Framework Windows Communication Foundation (WCF).
Remarque : Si vous utilisez IBM Security AppScan, seul le protocole de transport HTTP est pris en charge.

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

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

NTLM and Kerberos Authentication

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 Configuration du plan de travail pour l'authentification NTLMv2.

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.

Limitations

Les tableaux ne sont pas pris en charge.

Suite à un manque de spécification, les pièces jointes ne sont pas prises en charge avec le transport JMS (Java Message Service). L'enveloppe est directement envoyée en utilisant le codage UTF-8.

Tous les algorithmes de sécurité ne sont pas toujours disponibles pour chaque implémentation de l'environnement d'exécution Java. Si une implémentation de sécurité déterminée n'est pas disponible, ajoutez les bibliothèques obligatoires aux chemins d'accès aux classes de l'environnement d'exécution Java que ce produit utilise.

Le testeur de services générique affiche l'enveloppe, comme indiqué dans le document XML. Toutefois, les algorithmes de sécurité considèrent l'enveloppe comme un élément binaire. Par conséquent, vous devez configurer la sécurité SOAP de sorte que les messages entrants et sortants sont correctement chiffrés mais demeurent déchiffrés dans le test.

Le protocole de transport Microsoft .NET ne prend pas en charge les transactions, les portées, ou les demandes en mode duplex telles que des rappels ou des services bidirectionnels basés sur le transport MS-MQ.


Retour d'informations