A pilha de serviços da Web CFX utiliza algumas das mesmas tecnologias que as pilhas Apache Axis2 e Metro, discutidas em artigos anteriores desta série. Assim como Axis2, ela usa a implementação Apache WSS4J de Segurança WS. Assim como Metro, ela usa predominantemente a configuração de serviços da Web JAX-WS 2.x e ligação de dados JAXB 2.x (usando até mesmo a mesma implementação de referência de JAXB que Metro, embora possa haver diferenças nas versões das duas pilhas). Mas além desses componentes em comum, as pilhas têm muitas diferenças, incluindo seus mecanismos de proteção e manipulação da configuração política de Segurança WS.

Artigos anteriores desta série compararam o desempenho de Axis2 com o do Macro, ambos para troca de mensagens simples e com diferentes configurações de Segurança WS. Neste artigo, você verá como o desempenho de CXF se compara com os releases mais recentes de Axis2 e Metro.

Examinando o desempenho

Assim como os artigos anteriores sobre o desempenho de serviços da Web — "O Alto Custo de (WS-)Security " e "Desempenho de Metro versus Axis2" — este artigo segue a abordagem de medir o tempo necessário para executar uma sequência particular de solicitações quando o cliente e o servidor são executados ambos em um único sistema. Essa abordagem faz um bom trabalho de comparação do gasto adicional de processamento dos serviços da Web, pois elimina o impacto das latências de rede e resultados de medição de tempo. Supondo que o código do cliente não seja significativamente mais lento que o do servidor, os números são também boas representações do desempenho real do servidor sob carga.

Este artigo também usa o mesmo aplicativo de teste que os artigos anteriores, um serviço de recuperação de dados sísmicos. O serviço usa um banco de dados de mais de 93.000 terremotos que ocorreram no mundo todo em um período de anos. Solicitações ao serviço especificam um período de tempo e um intervalo de coordenadas geográficas, e o serviço retorna todos os terremotos na faixa especificada. Consulte "O Alto Custo de (WS-)Security " para obter os detalhes completos do aplicativo de teste e um par de mensagens solicitação/resposta de amostra.

Assim como nos artigos anteriores, dois conjuntos de sequências de solicitações são usados para testes de desempenho. O primeiro conjunto usa 1.000 solicitações com parâmetros de consulta ajustados para corresponder a uma pequena porção do banco de dados de terremotos inteiro (retornando apenas 816 terremotos para as 1.000 solicitações). O segundo conjunto usa 100 solicitações ajustadas para corresponder a uma porção maior do banco de dados (retornando 176.745 terremotos correspondentes para as 100 solicitações). Essas duas sequências de solicitações enfatizam características diferentes do desempenho as pilhas de serviços da Web. A primeira mostra a velocidade com que as pilhas processam solicitações com poucos dados, e a segunda enfatiza a velocidade de processamento de volumes de dados. Cada sequência de solicitações foi executada várias vezes em diferentes configurações de segurança, e apenas o melhor tempo de cada configuração foi mantido nos resultados.

Os testes foram realizados em um sistema Linux Mandriva 2009.1 de 64 bits, com um processador Athlon X2 5400+ e 4 GB de RAM, usando uma JVM Sun (Oracle) Java 1.6.0_18 de 32 bits (que resultou em desempenho um pouco melhor que a JVM de 64 bits para o tamanho de heap dado). O código do servidor foi executado em Tomcat 6.0.20, configurado para usar 1024MB de heap, com o código do cliente usando 512MB de heap. As versões das pilhas de serviço da Web foram:

• CXF 2.1.7
• Metro 2.0
• Axis2 1.5.1 com o release 1.5 de Rampart

Se você quiser realizar os testes no seu próprio hardware e JVM, faça o download do código.

Voltar para parte superior

Desempenho sem Segurança WS

A Figura 1 mostra os tempos de teste medidos para Axis2, Metro e CXF sem o uso de Segurança WS. Como é possível ver no gráfico, Metro é significativamente mais rápido que Axis2 e CXF (aproximadamente 25 por cento mais rápido) para o caso de muitas solicitações com respostas pequenas, e mais ou menos a mesma velocidade que as pilhas Apache para o número menor de solicitações com respostas maiores. (Em todos os gráficos deste artigo, barras menores são melhores, pois indicam tempos menores.)

Esses resultados mostram algumas diferenças interessantes em relação à comparação anterior entre Metro 1.5 e Axis2 1.5.1. Os tempos sugerem que, pelo menos para os dados usados no aplicativo de teste, Metro 2.0 é mais rápido que Axis2e CXF no processamento por solicitação. Na conversão de dados de e para XML, as três pilhas são executadas aproximadamente na mesma velocidade. Isso é esperado no caso do metro e CXF, pois ambos usam a implementação de referência JAXB para conversões. Julgando por esses resultados, a implementação de ligação Axis2 Databinding Framework (ADB) usada por padrão no Axis2 é executada duas vezes mais rápida que JAXB.

Voltar para parte superior

Desempenho com Segurança WS

As figuras a seguir mostram os tempos de teste para as seguintes configurações de segurança:

• plain: Sem segurança (o mesmo valor que a Figura 1)
• username: texto simples de Segurança WS UsernameToken nas solicitações
• sign: Assinatura de Segurança WS no corpo e cabeçalhos, com registro de data e hora
• signencr: Assinatura de Segurança WS no corpo e cabeçalhos, com registro de data e hora e criptografia do corpo

Figura 2 mostra os tempos de teste para 1.000 solicitações com pequenas respostas:

Figura 3 mostra os tempos relativos (normalizados para os resultados do CXF) para as mesmas 1.000 solicitações com pequenas respostas:

Axis2 é consistentemente a pilha mais lenta em todas as configurações de segurança para esta etapa de teste. Metro é consistentemente o mais rápido, embora a diferença entre Metro e CXF seja menor que a diferença entre CXF e Axis2: Metro é cerca de 10 por cento mais rápido que CXF nas diferentes configurações de segurança, enquanto o Axis2 é mais que duas vezes mais lento que CXF.

Figura 4 mostra os tempos de teste medidos para 100 solicitações com respostas maiores:

Figura 5 mostra os tempos relativos (normalizados para os resultados do CXF) para as mesmas 100 solicitações com respostas maiores:

Para esta segunda etapa de teste, Axis2 é novamente muito mais lento que Metro e CXF (novamente cerca de metade da velocidade do CXF), e a diferença entre Metro e CXF nas mensagens de resposta menores é mais que o contrário, com CXF aproximadamente 15 por cento mais rápido no geral.

CXF 2.1.7 vs. 2.1.6

Esses tempos de teste mostram uma melhoria perceptível de desempenho do CXF entre as versões 2.1.6 e 2.1.7. O ajuste do código é parcialmente responsável por isso, mas uma parte mais significativa da melhoria é devida à correção de um problema discutido em "WS-Security with CXF." CXF 2.1.6 não processou uma configuração de política de Segurança WS UsernameToken a menos que uma política <sp:TransportBinding> ou alguma forma de criptografia ou assinatura estivesse presente. Normalmente, tal política adicionada estaria presente quando UsernameToken é usado — especialmente um UsernameToken de texto simples, pois sem criptografia no nível de transporte ou de mensagem, o nome de usuário e senha podem ser observados em trânsito. Mas é perfeitamente válido, do ponto de vista de uma política, usarUsernameToken sozinho (como na configuração username deste artigo), e a correção implementada em CXF 2.1.7 cuida desse caso. Como parte da correção, CXF 2.1.7 ignora a adição de manipulação de Segurança WS ao fluxo de mensagem de resposta neste caso em particular.

A remoção da Segurança WS do fluxo de mensagem na configuração username melhorou o resultado do CXF por um percentual significativo, em comparação com os mesmos testes executados no CXF 2.1.6. Essa melhoria entre versões é, infelizmente, um pouco artificial. Se a etapa de teste username usasse criptografia no nível de transporte ou de mensagem, a manipulação da Segurança WS estaria presente no fluxo e mensagem de resposta e faria com que os resultados da medição de tempo do CXF daquela configuração fossem significativamente menores. Espera-se que as versões futuras do CXF estendam a análise de política, de modo que a Segurança WS seja configurada nos fluxos de mensagem de solicitação ou de resposta apenas quando necessário, estendendo assim o benefício para o desempenho de um leque maior de casos de uso (incluindo aqueles nos quais assinatura ou criptografia é necessária em apenas uma direção).

Voltar para parte superior

Conclusões

Baseado nos tempos de teste relatados neste artigo, parece que Metro 2.0 é mais rápido no processamento de solicitação/resposta básico que Axis2 1.5.1 ou CXF 2.1.7. Quando se trata de processamento de Segurança WS, no entanto, a biblioteca XWSS do Metro não é mais rápida, no geral, que a biblioteca WSS4J usada pelo Axis2 e pelo CXF.

Provavelmente o aspecto mais interessante desses resultados é a implicação para Axis2. Testes anteriores mostraram que Axis2 era muito mais devagar que Metro para processamento de Segurança WS. Esses resultados de teste mostram que a diferença não é devido ao código de implementação de Segurança WS, portanto deve ser devido à maneira como o Axis2 (e o módulo de segurança Rampart) lidam com mensagens sendo passadas entre WSS4J. Isso confirma os resultados discutidos em "Desempenho de Metro versus Axis2." Axis2 também exige significativamente mais memória para executar os testes que as outras pilhas, especialmente a configuração signenecr (Axis2 precisou de cerca de 80 MB de memória no cliente; CXF foi executado bem com 48 MB). Esses problemas reforçam a impressão anterior de que o Axis2 desperdiça tempo de processamento e memória fazendo conversões desnecessárias entre diferentes representações de mensagem como parte da manipulação de Segurança WS.

O gasto adicional de desempenho do uso de assinatura e criptografia de Segurança WS é substancial para todas as pilhas testadas. Esse gasto adicional pode ser um problema para serviços com uso pesado. No próximo artigo, você aprenderá sobre as tecnologias de add-on Ws-Trust e WS-SecureConversation, que podem reduzir o gasto adicional de Segurança WS quando clientes fazem uso extensivo de um serviço em particular.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

• CXF: CXF é uma pilha de serviços da Web de software livre da Apache Software Foundation.
  
  
• Axis2: Axis 2 é outra pilha de serviços da Web de software livre da Apache.
  
  
• Metro: Metro é uma pilha de serviços da Web de software livre que incorpora as mais recentes implementações de referência dos padrões Java JAXB 2.x e JAX-WS 2.x.
  
  
• WSS4J: WSS4J é a implementação de software livre de Segurança WS da Apache Software Foundation, usada por Axis2 e CXF para processamento de Segurança WS.
  
  
• XWSS: XWSS é o componente do Metro que cuida do processamento de política de Segurança WS.
  
  
• Understanding Web Services specifications: Esta série de tutoriais apresenta vários dos padrões de serviços da Web importantes, incluindo:
  • "Understanding Web Services specifications: Web Services Description Language (WSDL)" (Nicholas Chase, developerWorks, julho de 2006)
  • "Understanding Web Services specifications: WS-Security" (Nicholas Chase, developerWorks, agosto de 2006)
  • "Understanding Web Services specifications: WS-Policy" (Tyler Anderson, developerWorks, fevereiro de 2007).
  
  
• OASIS Web Services Security (WSS) TC: Esta é a organização responsável pela especificação e perfis de tokens da Segurança WS. É possível encontrar aqui links para todas as versões desses padrões.
  
  
• O W3C Web Services Policy Working Group: Esse grupo define a especificação da WS-Policy.
  
  
• OASIS Web Services Secure Exchange (WS-SX) TC: Esta organização é responsável pela política de Segurança WS e especificações relacionadas.
  
  

Sobre o autor

Dennis Sosnoski é um consultor e instrutor especializado em XML e serviços da Web baseados em Java. Sua experiência em desenvolvimento de software profissional se estende por mais de 30 anos, sendo que nos últimos 10 focou tecnologias XML e Java do lado do servidor. Dennis é o desenvolvedor líder da estrutura de software livre JiBX XML Data Binding e a estrutura de serviços da Web associada JiBX/WS, assim como um committer na estrutura de serviços da Web Apache Axis2. Também foi um dos membros do Grupo de Especialistas para as especificações JAX-WS 2.0 e JAXB 2.0. O material para a série Serviços da Web Java é baseado nas aulas de treinamento de Dennis.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Examinando o desempenho
• Desempenho sem Segurança WS
• Desempenho com Segurança WS
• Conclusões
• Download
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais