Java Web Services: Desempenho de WS-SecureConversation – Parte 02

Os serviços de Web são uma parte crucial do papel desempenhado pela tecnologia Java na computação empresarial. Na primeira parte deste artigo, vimos o modo de configuração e uso para o WS-SecureConversation para Apache Axis2. Acompanhe agora as configurações específicas para Metro e Apache CXF, além de uma comparação no desempenho de WS-SecureConversation.

Configuração do CXF

Configurar o CXF para WS-SecureConversation é mais direto do que a abordagem do Axis2. No lado do cliente, tudo o que é preciso fazer é adicionar os parâmetros de tempo de execução de segurança ao arquivo cxf.xml usado no cliente. Isso funciona da mesma forma para os parâmetros usados em WS-Security regular, apenas usando nomes diferentes para os parâmetros (todos terminam com o sufixo .sct). A listagem 5 mostra a versão do cxf.xml usada nos testes para este artigo, com os parâmetros SCT em destaque:

Listagem 5. cxf.xml de cliente CXF

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:jaxws="http://cxf.apache.org/jaxws"
   xsi:schemaLocation="http://www.springframework.org/schema/beans 
   http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   http://cxf.apache.org/jaxws 
   http://cxf.apache.org/schemas/jaxws.xsd">

  <jaxws:client name="{http://ws.sosnoski.com/seismic/wsdl}seismic" createdFromAPI="true">
    <jaxws:properties>
<entry key="ws-security.signature.properties.sct"
          value="client-crypto.properties"/>
      <entry key="ws-security.signature.username.sct" value="clientkey"/>
      <entry key="ws-security.encryption.properties.sct"
          value="client-crypto.properties"/>
      <entry key="ws-security.encryption.username.sct" value="serverkey"/>
      <entry key="ws-security.callback-handler.sct"
          value="com.sosnoski.ws.seismic.cxf.ClientCallback"/>
    </jaxws:properties>
  </jaxws:client>

</beans>

A configuração do lado do servidor também é fácil no CXF, mas exige mudanças no arquivo web.xml que define a configuração de contexto do CXF e no arquivo cxf-servlet.xml, que fornece a definição de serviço individual. O arquivo web.xml, mostrado na listagem 6, tem uma linha adicional que faz referência à configuração cxf-extension-addr.xml. Essa referência adicional inclui suporte ao WS-Addressing na configuração do CXF, como exigido para troca de mensagens entre o cliente e o STS (e também usado na troca de mensagem entre o cliente e o serviço real, com a política da listagem 1).

Listagem 6. web.xml do servidor do CXF

<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee">
  <display-name>CXFLibrary</display-name>
  <description>CXF Seismic Service</description>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      classpath:META-INF/cxf/cxf.xml
      classpath:META-INF/cxf/cxf-extension-soap.xml
      classpath:META-INF/cxf/cxf-servlet.xml 
      classpath:META-INF/cxf/cxf-extension-policy.xml
      classpath:META-INF/cxf/cxf-extension-ws-security.xml
      classpath:META-INF/cxf/cxf-extension-http.xml
      classpath:META-INF/cxf/cxf-extension-addr.xml
     </param-value>
  </context-param>
  <servlet>
    <servlet-name>CXFServlet</servlet-name>
    <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>CXFServlet</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>
</web-app>

A listagem 7 mostra o arquivo de configuração cxf-servlet.xml, com um conjunto de definições de parâmetro de SCT correspondente às mostradas para o cliente na listagem 5:

Listagem 7. cxf-servlet.xml do servidor do CXF

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jaxws="http://cxf.apache.org/jaxws"
    xmlns:soap="http://cxf.apache.org/bindings/soap"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
      http://cxf.apache.org/jaxws
      http://cxf.apache.org/schemas/jaxws.xsd">

  <jaxws:endpoint id="Processor"
      implementor="com.sosnoski.ws.seismic.cxf.CxfSeismicImpl"
      wsdlLocation="WEB-INF/wsdl/seismic.wsdl"
      address="/">

    <jaxws:properties>
<entry key="ws-security.signature.properties.sct" 
          value="server-crypto.properties"/>
      <entry key="ws-security.signature.username.sct" value="serverkey"/>
      <entry key="ws-security.encryption.username.sct" value="useReqSigCert"/>
      <entry key="ws-security.callback-handler.sct"
          value="com.sosnoski.ws.seismic.cxf.ServerCallback"/>
    </jaxws:properties>

  </jaxws:endpoint>
</beans>

Configuração do Metro

O Metro, assim como o Axis2, usa acréscimos customizados feitos à política de segurança para passar parâmetros de tempo de execução de segurança. Os parâmetros são passados para o WS-SecureConversation da mesma forma que para o WS-Security. Diferentemente do Axis2, o Metro não precisa de informações de configuração adicionais do STS no servidor, o que torna a configuração do Metro muito mais simples que a do Axis2.

A listagem 8 mostra uma versão editada do WSDL do lado do cliente com os parâmetros de tempo de execução de segurança do Metro mostrados em negrito azul:

Listagem 8. WSDL do cliente Metro com parâmetros

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" ...>
  <wsp:Policy xmlns:sp=".../ws-sx/ws-securitypolicy/200702"
      xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
      xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecureConv">
    <wsp:ExactlyOne>
      <wsp:All>
        <wsap:UsingAddressing xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/>
        <sp:SymmetricBinding>
          ...
        </sp:SymmetricBinding>
        ...
<wssc:KeyStore alias="clientkey" keypass="clientpass" location="client.keystore"
            storepass="nosecret" xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
            wspp:visibility="private"
            xmlns:wssc="http://schemas.sun.com/2006/03/wss/client"/>
        <wssc:TrustStore location="client.keystore" peeralias="serverkey"
            storepass="nosecret" xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
            wspp:visibility="private"
            xmlns:wssc="http://schemas.sun.com/2006/03/wss/client"/>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy>
  ...
  <wsdl:service name="SeismicMetro">
    <wsdl:port binding="wns:SeismicBinding" name="seismic">
      <soap:address location="http://localhost:8080/metro-seismic"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

A listagem 9 mostra o WSDL do lado do servidor, novamente com os parâmetros de tempo de execução em destaque.

Listagem 9. WSDL do servidor Metro com parâmetros

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" ...>
  <wsp:Policy xmlns:sp=".../ws-sx/ws-securitypolicy/200702"
      xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
      xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecureConv">
    <wsp:ExactlyOne>
      <wsp:All>
        <wsap:UsingAddressing xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/>
        <sp:SymmetricBinding>
          ...
        </sp:SymmetricBinding>
        ...
  <wsss:KeyStore alias="serverkey"
            keypass="com.sosnoski.ws.seismic.metro.KeystoreAccess"
            location="server.keystore" storepass="nosecret"
            xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy" wspp:visibility="private"
            xmlns:wsss="http://schemas.sun.com/2006/03/wss/server"/>
        <wsss:TrustStore location="server.keystore" storepass="nosecret"
            xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy" wspp:visibility="private"
            xmlns:wsss="http://schemas.sun.com/2006/03/wss/server"/>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy>
  ...
  <wsdl:service name="SeismicMetro">
    <wsdl:port binding="wns:SeismicBinding" name="seismic">
      <soap:address location="http://localhost:8080/metro-seismic"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

O restante da configuração do STS é tirado diretamente da política comum.

Verificando o desempenho

As comparações de desempenho usam o mesmo código de teste utilizado em uma série anterior de artigos publicados no developerWorks, 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 vários anos. As solicitações do serviço especificam um intervalo de tempo e um intervalo de coordenadas geográficas. A partir daí, o serviço retorna todos os terremotos dentro do intervalo especificado.

Assim como em experiências anteriores, dois conjuntos de sequências de solicitações são usados para os testes de desempenho. O primeiro conjunto usa mil solicitações, com parâmetros de consulta ajustados para corresponder a uma pequena porção de todo o banco de dados de terremotos – retornando apenas 816 terremotos correspondentes 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 diferentes características de desempenho das pilhas de serviços da Web. A primeira mostra a rapidez com que as pilhas processam as solicitações com poucos dados, e a segunda enfatiza a velocidade de processamento de volumes de dados. Cada sequência de solicitação foi executada várias vezes em diferentes configurações de segurança, com apenas o melhor tempo para cada configuração mantido nos resultados. As configurações de segurança testadas foram:

Sem segurança (simples)
WS-SecureConversation assinando todos os corpos de mensagem de solicitação/resposta (sign)
WS-SecureConversation criptografando todos os corpos de mensagem de solicitação/resposta (encr)
WS-SecureConversation assinando e criptografando todos os corpos de mensagem de solicitação/resposta (signencr)

Os testes foram executados em um sistema Linux de 64 bits Mandriva
2009.1 com um processador Athlon X2 5400+ e 4 GB de RAM, usando uma JVM
de 32 bits Sun (Oracle) Java 1.6.0_18 – que teve um desempenho
ligeiramente melhor em relação à JVM de 64 bits para um determinado
tamanho de heap.

O código do servidor foi executado em Tomcat 6.0.20,
configurado para usar 1024 MB do heap com o código do cliente usando
512 MB de heap. As versões de pilha de serviço da Web testadas foram:

Axis2 1.5.1 com o release 1.5 do Rampart
Metro 2.0
CXF 2.1.8

Resultados do desempenho

A Figura 1 mostra os tempos medidos na série de testes de resposta pequena. O Metro é um pouco mais rápido que o Axis2 e o CXF em manipular essas mensagens pequenas ao ser executado sem segurança. Essa vantagem de desempenho é transportada para os testes usando o WS-SecureConversation. No geral, o Metro é cerca de 25% mais rápido que o CXF na série de testes de resposta pequena e cerca de duas vezes mais rápido que o Axis2. (Em todos os gráficos deste artigo, barras mais curtas são melhores porque indicam tempo mais rápido.)

Figura 1. Tempos medidos com pequenas respostas

A Figura 2 mostra os tempos medidos na série de testes de resposta grandes. Aqui o Metro novamente é a mais rápida das pilhas, mas essa vantagem não é tão pronunciada como nos testes de resposta pequena.

Nesse caso, o CXF fica basicamente empatado com o Metro em todas as configurações, exceto quando o WS-SecureConversation é usado apenas para assinatura. O Metro e o CXF são muito mais rápidos que o Axis2 em todas as configurações do WS-SecureConversation – 40% mais rápidos.

Figura 2. Tempos medidos com grandes respostas

Vantagem do WS-SecureConversation

Uma vantagem do WS-SecureConversation deve ser um ganho de desempenho pelo uso da criptografia simétrica em vez da criptografia assimétrica. As três figuras a seguir mostram se isso realmente corresponde às expectativas. Elas comparam os tempos de cada teste de execução das pilhas usando WS-Security com chaves privadas e certificados (criptografia assimétrica) e a mesma pilha usando WS-SecureConversation com chave secreta (criptografia simétrica).

Os tempos do WS-Security são tirados da Comparação de desempenho do CXF, executada no mesmo hardware e quase nas mesmas versões das pilhas de serviços da Web. Apenas a versão do CXF é diferente, porque os tempos de teste do WS-Security não incluíram configuração apenas para criptografia – que não é suportada com o uso de certificados. Apenas os tempos para testes de assinatura e criptografia foram comparados.

Figura 3. Comparação de desempenho do Axis2

Figura 4. Comparação de desempenho do Metro

Figura 5. Comparação de desempenho do CXF

Os resultados do teste apenas com assinatura são muito mais rápidos usando a criptografia simétrica do WS-SecureConversation para casos de respostas pequenas, mas essa vantagem se perde quando são retornadas respostas grandes.

Os resultados dos testes de assinatura e criptografia mostram um grande ganho de desempenho usando a criptografia simétrica do WS-SecureConversation para o caso de respostas pequenas – mais até do que nos resultados apenas de assinatura, além de um ganho significativo mas consideravelmente menor em respostas grandes.

Assinar mensagens sempre envolve pré-processamento para converter XML em uma forma canônica. Depois de isso ter sido feito, o XML é compilado para gerar o valor do hash. Esse valor do hash é o que finalmente é incluído na assinatura real e a geração da assinatura é a única etapa na qual a criptografia simétrica versus assimétrica é diferente. A criptografia de mensagens apenas processa todo o XML com poucas modificações.

Ao assinar um grande número de mensagens pequenas com criptografia assimétrica, a maior parte do seu tempo de processamento é gasta na etapa de assinatura. Se estiver assinando mensagens grandes, muito mais tempo será gasto nas etapas de canonicalização e compilação. A criptografia simétrica sempre será mais rápida que a criptografia assimétrica – para forças basicamente equivalentes, mas no caso de assinatura e criptografia, os tempos mesclados basicamente resultam na média de ganhos.

Conclusões

O WS-SecureConversation pode fornecer um ganho substancial de desempenho (mais do que o dobro em testes com mensagens pequenas) para trocas contínuas de mensagens – em comparação com o uso de pares de chave privada/certificados para a criptografia assimétrica do WS-Security.

Os benefícios de desempenho podem ser ainda maiores se estivermos autorizando clientes de um serviço, visto que a etapa de autorização pode ser manuseada no processamento do STS em vez de em cada solicitação individual para o serviço.

Para ser de real benefício, o WS-SecureConversation exige uma sequência contínua de mensagens por um intervalo relativamente curto de tempo. Se for usado para um serviço que os clientes acessam apenas uma vez, na verdade estará sendo acrescentado muito gasto adicional devido às trocas de mensagens entre o cliente e o STS. O suporte ao WS-SecureConversation provavelmente também não é tão interoperável quanto o WS-Security simples.

Acompanhe mais detalhes dessa série no dW Brasil e aguarde pelo artigo em que vamos tratar do uso da criptografia simétrica com WS-Security regular. Até a próxima!

artigo publicado originalmente em IBM developerWorks, por Dennis Sosnoski

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. Entre em contato com Dennis no endereço enquiry@sosnoski.com.

De 0 a 10, o quanto você recomendaria este artigo para um amigo?

Powered by: