Una volta generato il test, gli envelope della chiamata al messaggio sono creati in base a XSD (XML schema definition). Durante questo processo, vengono creati i campi obbligatori e vengono selezionate le opzioni predefinite. È possibile modificare tali elementi nell'editor di test.
JRE (Java Runtime Environment) che il workbench utilizza deve supportare il livello di crittografia richiesto dal certificato digitale selezionato. Ad esempio, non è possibile utilizzare un certificato digitale che richiede la crittografia a 256 bit con un JRE che supporta solo la crittografia a 128 bit. Per impostazione predefinita, il workbench viene configurato con una codifica di lunghezza limitata o vincolata. Per utilizzare algoritmi meno vincolati, è necessario scaricare e applicare file di politiche di giurisdizione limitata (local_policy.jar e US_export_policy.jar).
È possibile scaricare file di giurisdizione non limitata da questo sito: http://www.ibm.com/developerworks/java/jdk/security/50/
Fare clic su IBM SDK Policy files e accedere a developerWorks per ottenere i file di giurisdizione illimitata. Prima di installare questi file delle politiche, eseguire il backup dei file delle politiche esistenti nel caso in cui successivamente si desidera ripristinare i file originali. Sovrascrivere, quindi, i file nella directory /jre/lib/security/ con file delle politiche di giurisdizione illimitata.
Se si distribuiscono i test sui computer remoti, occorre aggiungere questi file a JRE utilizzato da IBM® Agent Controller.
L'autenticazione semplice (autenticazione server): In questo caso, il client del test deve determinare se il servizio è attendibile. Non è necessario configurare un archivio chiavi. Se viene selezionata l'opzione Considera sempre attendibile, non è necessario fornire un archivio chiavi del certificato del server.
Se si desidera veramente autenticare il servizio, è possibile configurare un truststore del certificato che contiene i certificati dei servizi attendibili. In questo caso, il test presuppone di ricevere un certificato valido.
Autenticazione doppia (autenticazione client e server): In questo caso, il servizio deve autenticare il client del test in base all'autorità root. È necessario fornire l'archivio chiavi del certificato client che deve essere prodotto per autenticare il test come un client certificato.
Quando si registra un test del servizio tramite un proxy, il proxy di registrazione si trova tra il servizio ed il client. In questo caso, è necessario configurare le impostazioni SSL del proxy di registrazione per l'autenticazione come servizio effettivo al client (per l'autenticazione semplice), e come client al servizio (per l'autenticazione doppia). Questo significa che è necessario fornire il proxy di registrazione con i certificati adeguati.
Quando si utilizzano i servizi dello stub, è inoltre possibile configurare le impostazioni SSL del servizio stub per l'autenticazione come server effettivo. Questo significa che è necessario fornire lo stub di registrazione con il certificato adeguato.
È possibile eseguire il test sui servizi con i certificati digitali per entrambi i protocolli di sicurezza SSL e SOAP. I certificati digitali devono essere contenuti nelle risorse dell'archivio chiavi JKS (Java Key Store) accessibili nello spazio di lavoro. Quando si utilizzano i file dell'archivio chiavi, è necessario impostare la password richiesta per accedere alle chiavi in entrambi gli editor di sicurezza e di test. Per la sicurezza SOAP potrebbe essere necessario fornire un nome esplicito per la chiave e fornire una password per accedere alle chiavi private nell'archivio chiavi.
Se si stanno distribuendo i test a computer agent, tali file devono essere aggiunti anche a JRE utilizzato da IBM Agent Controller.
Il prodotto consente di inviare allegati Swa( SOAP Messages with Attachments) e MTOM (Message Transmission Optimization Mechanism).
Tali file vengono forniti con il prodotto. Per ulteriori informazioni, vedere Configurazione dell'ambiente per la gestione degli allegati file.
Se si stanno distribuendo i test a computer agent, tali file di librerie devono essere aggiunti anche a JRE utilizzato da Rational Agent Controller.
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.
Le prestazioni dell'utente virtuale dipendono dall'implementazione dell'applicazione del contenitore. Per un trasporto HTTP, sul prodotto è stato eseguito il test con un massimo di 900 utenti virtuali simultanei in Windows® e 600 in Linux®. Per JMS, il massimo è di 100 utenti virtuali simultanei, sebbene tale numero può variare a causa dell'implementazione asincrona di JMS. Al di là di tali valori, è possibile che si verifichino errori di connessione e la velocità di transazione diminuirà.