O cliente de serviço genérico será útil para depurar ou testar um serviço, quando você não tiver acesso a um cliente dedicado para enviar a solicitação. É possível configurar uma variedade grande de configurações de transporte e segurança para o serviço, editar os parâmetros da solicitação e enviar anexos.
Quando uma solicitação for chamada com sucesso, seu retorno de mensagem será incluído no Histórico de Solicitação. Você pode utilizar esse recurso para lembrar os resultados que foram gerados em momentos diferentes.
Se você estiver usando IBM® Rational Performance Tester ou IBM Rational Service Tester for SOA Quality, poderá selecionar solicitações no Histórico de Solicitação e clicar em Gerar Teste para gerar um teste que reproduzirá todas as solicitações selecionadas. É possível editar o teste para substituir os valores de teste registrados pelos os dados de teste variáveis ou incluir correlação de dados dinâmicos no teste. Também é possível configurar pontos de verificação no conteúdo dos documentos XML na resposta do serviço.
O JRE (Java Runtime Environment) que o ambiente de trabalho utiliza deve suportar o nível de criptografia necessário para o certificado digital que você selecionar. Por exemplo, você não pode utilizar um certificado digital que requer criptografia de 256 bits com um JRE que suporta apenas criptografia de 128 bits. Por padrão, o ambiente de trabalho é configurado com cifras restritas ou de força limitada. Para utilizar algoritmos de criptografia com menos restrição, você deve fazer o download e aplicar os arquivos de políticas de jurisdição ilimitada (local_policy.jar e US_export_policy.jar).
É possível fazer download dos arquivos de políticas de jurisdição ilimitada deste site: http://www.ibm.com/developerworks/java/jdk/security/50/
Clique em Arquivos de Políticas do SDK IBM e, em seguida, efetue login no developerWorks para obter os arquivos de políticas de jurisdição ilimitada. Antes de instalar esses arquivos de políticas, faça o backup dos arquivos de políticas existentes caso deseje restaurar os arquivos originais futuramente. Em seguida, sobrescreva os arquivos no diretório /jre/lib/security/ pelos arquivos de políticas de jurisdição ilimitada.
Autenticação simples (autenticação do servidor): Nesse caso, o cliente de teste precisa determinar se o serviço pode ser confiado. Não é necessário configurar um keystore. Se você selecionar a opção Sempre confiar, não é necessário fornecer um keystore de certificado do servidor.
Se você realmente desejar autenticar o serviço, poderá configurar um armazenamento confiável de certificado, que contém os certificados de serviços confiados. Nesse caso, o teste esperará receber um certificado válido.
Autenticação dupla (autenticação do cliente e do servidor): Nesse caso, o serviço precisa autenticar o cliente de teste de acordo com sua autoridade-raiz. É necessário fornecer o keystore de certificado do cliente que precisa se criado para autenticar o teste como um cliente de certificado.
Ao gravar um teste de serviço através de um proxy, o proxy de gravação situa-se entre o serviço e o cliente. Nesse caso, é necessário definir as configurações do SSL do proxy de gravação para autenticar a si mesmo como o serviço real para o cliente (para autenticação simples) e como o cliente para o serviço (para autenticação dupla). Isso significa que é necessário fornecer o proxy de gravação com os certificados adequados.
Ao usar os stubs de serviço, também é possível definir as configurações SSL do serviço de stub para autenticar a si mesmo como o servidor real. Isso significa que é necessário fornecer o stub de serviço com o certificado adequado.
O produto suporta autenticação Microsoft NT LAN Manager (NTLMv1 e NTLMv2) e Kerberos. As informações sobre autenticação são registradas como parte do teste durante a fase de gravação.
Para ativar suporte NTLMv2, você deve incluir uma biblioteca de terceiros no ambiente de trabalho. Para obter mais informações, consulte Configurando o Ambiente de Trabalho para a Autenticação do NTLMv2.
Você pode testar serviços com certificados digitais para protocolo de segurança SSL e SOAP. Os certificados digitais devem estar contidos em recursos de armazenamento de chaves JKS (Java Key Store) acessíveis na área de trabalho. Ao tratar de arquivos de armazenamento de chaves, você deve configurar a senha necessária para acessar as chaves tanto no editor de segurança quanto no editor de teste. Para a segurança SOAP, talvez seja necessário fornecer um nome explícito para a chave e fornecer uma senha para acessar as chaves privadas no armazenamento de chaves.
A matrizes não são suportadas.
Em razão de falta de especificação, os anexos não são suportados com o transporte JMS (Java Message Service). O envelope é enviado diretamente utilizando-se a codificação UTF-8.
Todos os algoritmos de segurança nem sempre estão disponíveis para cada implementação Java Runtime Environment (JRE). Se uma implementação de segurança específica não estiver disponível, inclua as bibliotecas necessárias no caminho de classe do JRE utilizado por este produto.
O testador de serviço genérico exibe o envelope conforme refletido no documento XML. No entanto, os algoritmos de segurança consideram o envelope como binário. Portanto, é necessário definir a configuração de segurança do SOAP para que as mensagens de entrada e saída sejam criptografadas corretamente, mas permaneçam decriptografadas no teste.
O protocolo de transporte Microsoft .NET não suporta transações, escopos ou solicitações de modo duplex, como retornos de chamada ou serviços de duas vias com base no transporte do MS-MQ.