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.
L'environnement JRE (Java Runtime Environment) utilisé par le plan de travail doit prendre en charge le niveau de chiffrement requis par le certificat numérique sélectionné. Par exemple, vous ne pouvez pas utiliser de certificat numérique qui requiert un chiffrement sur 256 bits avec un environnement JRE qui ne prend en charge que le chiffrement sur 128 bits. Par défaut, le plan de travail est configuré avec des codes de chiffrement restreints ou de force limitée. Pour utiliser des algorithmes de chiffrement moins restreints, vous devez télécharger et appliquer les fichiers de règles de juridiction illimitée (local_policy.jar et US_export_policy.jar).
Vous pouvez les télécharger sur le site suivant : http://www.ibm.com/developerworks/java/jdk/security/50/
Cliquez sur IBM SDK Policy files puis connectez-vous à developerWorks pour obtenir les fichiers de règles à juridiction illimitée. Avant d'installer ces fichiers de règles, sauvegardez les fichiers de règles existants au cas où vous souhaiteriez les restaurer ultérieurement. Remplacez ensuite les fichiers dans le répertoire /jre/lib/security/ par les fichiers de règles à juridiction illimitée.
Authentification simple (authentification serveur) : Dans ce cas, le client de test doit déterminer si le service est digne de confiance. Il n'est pas nécessaire de configurer un magasin de clés. Si vous sélectionnez l'option Toujours faire confiance, vous n'avez pas besoin d'indiquer de fichier de clés de certificat serveur.
Si vous désirez authentifier réellement le service, vous pouvez configurer un fichier de clés de certificat contenant les certificats des services accrédités. Dans ce cas, le test s'attendra à recevoir un certificat valide.
Double authentification (authentification client et serveur) : dans ce cas, le service doit authentifier le client de test d'après son propre certificat. Vous devez indiquer le fichiers de clés de certificat client devant être soumis afin d'authentifier le test en tant que client accrédité.
Lors de l'enregistrement d'un test de service via proxy, ce dernier est positionné entre le service et le client. Dans ce cas, vous devez configurer les paramètres SSL du proxy d'enregistrement afin que ce dernier s'authentifie en tant que le service lui-même auprès du client (pour authentification simple), et en tant que client auprès du service (pour authentification double). Ceci signifie que vous devez fournir au proxy d'enregistrement les certificats requis.
Lorsque vous utilisez des services de module de remplacement, vous pouvez également configurer les paramètres SSL du service afin qu'il s'authentifie en tant que le serveur lui-même. Ceci signifie que vous devez fournir au module de remplacement du service le certificat approprié.
Le produit prend en charge Microsoft NT LAN Manager (NTLMv1 et NTLMv2) et l'authentification Kerberos. Les informations d'authentification sont enregistrées dans le cadre du test pendant la phase d'enregistrement.
Pour activer le support NTLMv2, vous devez ajouter une bibliothèque tierce au plan de travail. Pour plus d'informations, voir Configuration du plan de travail pour l'authentification NTLMv2.
Vous pouvez tester des services avec des certificats numériques pour les protocoles de sécurité SSL et SOAP. Les certificats numériques doivent se trouver dans les ressources de magasin de clés JKS (Java Key Store) accessibles dans l'espace de travail. Lors de l'utilisation de fichiers de clés, vous devez définir le mot clé requis pour l'accès aux clés à la fois dans l'éditeur de sécurité et dans l'éditeur de test. Pour la sécurité SOAP, il peut être nécessaire d'indiquer un nom explicite pour la clé et un mot de passe pour accéder aux clés privées dans le fichier de clés.
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.