Der Generic Service Client ist beim Debuggen oder Testen eines Service hilfreich, wenn für das Senden der Anforderung kein Zugriff auf einen dedizierten Client möglich ist. Sie können zahlreiche Transport- und Sicherheitskonfigurationen für den Service definieren, die Parameter der Anforderung bearbeiten und Anhänge senden.
Wenn eine Anforderung erfolgreich aufgerufen wurde, wird die zugehörige Nachrichtenrückgabe zum Anforderungsprotokoll hinzugefügt. Mit dieser Funktion können Sie auf Ergebnisse zurückblicken, die zu unterschiedlichen Zeiten erzeugt wurden.
Wenn Sie IBM® Rational Performance Tester oder IBM Rational Service Tester for SOA Quality verwenden, können Sie Anforderungen im Anforderungsprotokoll auswählen und auf Test generieren klicken, um einen Test zu generieren, in dem alle ausgewählten Anforderungen wiederholt werden. Sie können den Test so bearbeiten, dass aufgezeichnete Testwerte durch variable Testdaten ersetzt werden, oder eine dynamische Datenkorrelation zum Test hinzufügen. Sie können außerdem Prüfpunkte für den Inhalt der XML-Dokumente in der Serviceantwort definieren.
Die Java Runtime Environment (JRE), die von der Workbench verwendet wird, muss die Verschlüsselungsebene unterstützen, die von dem ausgewählten digitalen Zertifikat unterstützt wird. So können Sie beispielsweise kein digitales Zertifikat, das eine 256-Bit-Verschlüsselung erfordert, für eine JRE verwenden, die nur eine 128-Bit-Verschlüsselung unterstützt. Standardmäßig ist die Workbench mit eingeschränkter oder begrenzter Verschlüsselung konfiguriert. Zur Verwendung weniger eingeschränkter Verschlüsselungsalgorithmen müssen Sie die Dateien für uneingeschränkte Standortrichtlinien (local_policy.jar und US_export_policy.jar) herunterladen und anwenden.
Sie können uneingeschränkte Standortrichtliniendateien von der folgenden Site herunterladen: http://www.ibm.com/developerworks/java/jdk/security/50/
Klicken Sie auf IBM SDK Policy files, und melden Sie sich dann bei developerWorks an, um die uneingeschränkten Standortrichtliniendateien zu erhalten. Es wird empfohlen, vor dem Installieren dieser Richtliniendateien die vorhandenen Richtliniendateien zu sichern, falls Sie diese zu einem späteren Zeitpunkt wiederherstellen möchten. Überschreiben Sie anschließend die Dateien im Verzeichnis /jre/lib/security/ mit den uneingeschränkten Standortrichtliniendateien.
Einfache Authentifizierung (Serverauthentifizierung): In diesem Fall muss der Testclient bestimmen, ob der Test vertrauenswürdig ist. Das Einrichten eines Keystores ist nicht notwendig. Wenn Sie die Option Immer vertrauen auswählen, müssen Sie keinen serverspezifischen Zertifikatskeystore einrichten.
Wenn Sie den Service wirklich authentifizieren wollen, können Sie einen Zertifikatstruststore konfigurieren, der die Zertifikate vertrauenswürdiger Services enthält. In diesem Fall erwartet der Test den Eingang eines gültigen Zertifikats.
Doppelte Authentifizierung (Client- und Serverauthentifizierung): In diesem Fall muss der Service den Testclient gemäß seiner Rootberechtigung authentifizieren. Sie müssen den clientspezifischen Zertifikatskeystore angeben, der erstellt werden muss, um den Test als zertifizierten Client zu authentifizieren.
Beim Aufzeichnen eines Servicetests über einen Proxy befindet sich der Recorder-Proxy zwischen dem Service und dem Client. In diesem Fall müssen Sie die SSL-Einstellungen des Recorder-Proxy konfigurieren, um diesen als den tatsächlichen Service für den Client (für die einfache Authentifizierung) und den Client für den Service (für doppelte Authentifizierung) zu authentifizieren. Das bedeutet, dass Sie den Recorder-Proxy mit den entsprechenden Zertifikaten angeben müssen.
Bei Verwendung von Stub-Services können Sie auch die SSL-Einstellungen des Stub-Service konfigurieren, damit dieser sich als tatsächlicher Server authentifizieren kann. Das bedeutet, dass Sie den Service-Stub mit dem entsprechenden Zertifikat angeben müssen.
Das Produkt unterstützt Microsoft NT LAN Manager (NTLMv1 und NTLMv2) sowie Kerberos-Authentifizierung. Die Authentifizierungsinformationen werden als Teil des Tests während der Aufzeichnungsphase aufgezeichnet.
Zur Aktivierung der NTLMv2-Unterstützung müssen Sie eine Bibliothek eines anderen Anbieters zur Workbench hinzufügen. Weitere Informationen siehe Konfiguration der Workbench zur NTLMv2-Authentifizierung.
Sie können Services mit digitalen Zertifikaten für die Sicherheitsprotokolle SSL und SOAP testen. Digitale Zertifikate müssen in Java-Keystoreressourcen (JKS) enthalten sein, die über den Arbeitsbereich zugänglich sind. Bei der Arbeit mit Keystore-Dateien müssen Sie das für den Zugriff auf die Schlüssel erforderliche Kennwort sowohl im Sicherheitseditor als auch im Testeditor festlegen. Bei der SOAP-Sicherheit kann es notwendig sein, einen expliziten Namen für den Schlüssel sowie ein Kennwort für den Zugriff auf die privaten Schlüssel im Keystore anzugeben.
Arrays werden nicht unterstützt.
Da keine entsprechende Spezifikation vorhanden ist, werden Anhänge beim Java Message Service-Transport (JMS) nicht unterstützt. Die Rahmenanweisung wird direkt mit UTF-8-Codierung gesendet.
Es stehen nicht immer alle Sicherheitsalgorithmen für alle Java Runtime Environment-Implementierungen (JRE) zur Verfügung. Wenn eine bestimmte Sicherheitsimplementierung nicht verfügbar ist, fügen Sie die erforderlichen Bibliotheken zum Klassenpfad der JRE hinzu, die vom Produkt verwendet wird.
Im Generic Service Tester wird die Rahmenanweisung wie im XML-Dokument angezeigt. Sicherheitsalgorithmen gehen jedoch von einer binären Rahmenanweisung aus. Sie müssen die SOAP-Sicherheitskonfiguration daher so konfigurieren, dass die eingehenden und abgehenden Aufrufe ordnungsgemäß verschlüsselt werden und im Test immer entschlüsselt bleiben.
Das Microsoft .NET-Transportprotokoll unterstützt keine Transaktionen, Geltungsbereiche oder Anforderungen im Duplexmodus wie Rückrufe oder bidirektionale Services, die auf dem MS-MQ-Transport basieren.