Web-сервисы Java: Производительность WS-SecureConversation

Сравниваем производительность разных стеков Web-сервисов при использовании технологии WS-SecureConversation

Технология WS-SecureConversation позволяет Web-сервису осуществлять безопасный обмен сообщениями с меньшими издержками на обработку сообщений, чем при использовании обычной технологии WS-Security. В этой статье вы узнаете, как конфигурировать и использовать WS-SecureConversation в трех главных открытых стеках Web-сервисов Java™: Apache Axis2, Metro и Apache CXF. Также мы сравним производительность работы WS-SecureConversation в этих трех стеках.

Денис Сосноски, консультант, Sosnoski Software Solutions, Inc.

Денис Сосноски (Dennis Sosnoski) - основатель и ведущий специалист консалтинговой компании по технологиям Java - Sosnoski Software Solutions, Inc., специализирующейся в обучении и консультировании по проблемам XML и Web-сервисов. Он имеет более чем 30-летний опыт работы в профессиональном проектировании ПО, специализируясь на серверных XML и Java-технологиях. Денис является основным разработчиком интегрированной системы с открытым программным кодом JiBX XML Data Binding, построенной на базе технологии классов Java и связанной системы Web-сервисов JibxSoap, также как и системы Web-сервисов Apache Axis2. Он также был одним их экспертов при разработке спецификаций JAX-WS 2.0.



26.01.2012

Об этом цикле статей

Web-сервисы занимают одно из центральных мест в современных корпоративных Java-приложениях. В этой серии статей консультант по XML и Web-сервисам Деннис Сосноски рассказывает об основных инфраструктурах и технологиях, представляющих интерес для Java-разработчиков, использующих Web-сервисы. Следите за статьями этой серии, и вы будете получать самую свежую информацию о последних разработках в данной области и о том, как их применить в ваших проектах.

Технология WS-Security предоставляет важную функциональность, обеспечивающую безопасность корпоративных Web-сервисов, однако за нее приходится платить существенным снижением производительности. В статье WS-Trust и WS-SecureConversation мы узнали о технологии WS-SecureConversation, основанной на WS-Security и WS-Trust, котораая позволяет обезопасить обмен сообщениями между клиентом и сервером с помощью симметричного шифрования. В этой статье мы узнаем, как сконфигурировать WS-SecureConversation в трех важнейших стеках Web-сервисов, написанных на Java,— Apache Axis2, Metro и Apache CXF, а также сравним производительность этой технологии с асимметричным шифрованием, применяемым в WS-Security.

Конфигурируем WS-SecureConversation

Как уже говорилось в предыдущей статье, при использовании WS-SecureConversation клиент сначала соединяется с конечной точкой сервиса STS (Security Token Service) для установления контекста безопасности, включающего в себя совместно используемый секретный ключ. В дальнейшем на основе этого секретного ключа осуществляется шифрование и подписывание сообщений, которыми клиент обменивается с целевым сервисом. Контекст безопасности определяется токеном безопасности SCT (Security Context Token), который сервис STS возвращает клиенту. Клиент включает токен SCT во все запросы к сервису в рамках безопасного разговора, а сервис ссылается на этот токен во всех ответах.

Как и в случае обычной WS-Security, конфигурация безопасности определяется в политике WS-Policy. При использовании WS-SecureConversation для сервиса указывается две различных конфигурации безопасности: одна для обмена сообщениями с сервисом STS, а другая – для обмена сообщениями с целевым сервисом. Конфигурация безопасности сервиса STS вложена в определение политики токена безопасного разговора (secure conversation token).

В этой статье мы протестируем производительность Web-сервисов при использовании WS-SecureConversation:

  • для подписывания сообщений
  • для шифрования сообщений
  • для подписывания и для шифрования сообщений

В каждом из этих случаев мы будем применять одну и ту же конфигурацию безопасности STS с асимметричными ключами, используемыми как для подписывания, так и для шифрования относительного небольшого количества сообщений, передаваемых между клиентом и сервисом STS. В листинге 1 показана отредактированная версия конфигурации WS-Policy, которую мы использовали для тестов производительности в случае подписывания сообщений. Политика, применяемая для обмена сообщениями с сервисом STS, выделена жирным шрифтом (весь исходный код примеров для этой статьи можно загрузить в разделе Загрузки):

Листинг 1. Конфигурация WS-Policy, используемая для тестов производительности в случае подписывания сообщений
 <wsp:Policy wsu:Id="SecureConv" ...>
  <wsp:ExactlyOne>
   <wsp:All>
    <wsap:UsingAddressing xmlns:wsap=
"http://www.w3.org/2006/05/addressing/wsdl"/>
    <sp:SymmetricBinding>
     <wsp:Policy>
      <sp:ProtectionToken>
       <wsp:Policy>
        <sp:SecureConversationToken sp:IncludeToken=
".../IncludeToken/AlwaysToRecipient">
         <wsp:Policy>
          <sp:RequireDerivedKeys/>
          <sp:BootstrapPolicy>
           <wsp:Policy>
            <sp:AsymmetricBinding>
             <wsp:Policy>
              <sp:InitiatorToken>
               <wsp:Policy>
                <sp:X509Token sp:IncludeToken="...
/IncludeToken/AlwaysToRecipient">
                 <wsp:Policy>
                  <sp:RequireThumbprintReference/>
                 </wsp:Policy>
                </sp:X509Token>
               </wsp:Policy>
              </sp:InitiatorToken>
              <sp:RecipientToken>
               <wsp:Policy>
                <sp:X509Token sp:IncludeToken="...
/IncludeToken/AlwaysToInitiator">
                 <wsp:Policy>
                  <sp:RequireThumbprintReference/>
                 </wsp:Policy>
                </sp:X509Token>
               </wsp:Policy>
              </sp:RecipientToken>
              <sp:AlgorithmSuite>
               <wsp:Policy>
                <sp:TripleDesRsa15/>
               </wsp:Policy>
              </sp:AlgorithmSuite>
              <sp:Layout>
               <wsp:Policy>
                <sp:Strict/>
               </wsp:Policy>
              </sp:Layout>
              <sp:IncludeTimestamp/>
              <sp:OnlySignEntireHeadersAndBody/>
             </wsp:Policy>
            </sp:AsymmetricBinding>
            <sp:SignedParts>
             <sp:Body/>
             <sp:Header Name="To" Namespace=
"http://www.w3.org/2005/08/addressing"/>
             ...
             <sp:Header Name="Action" Namespace=
"http://www.w3.org/2005/08/addressing"/>
            </sp:SignedParts>
            <sp:EncryptedParts>
             <sp:Body/>
            </sp:EncryptedParts>
            <sp:Trust13>
             <wsp:Policy>
              <sp:MustSupportIssuedTokens/>
              <sp:RequireClientEntropy/>
              <sp:RequireServerEntropy/>
             </wsp:Policy>
            </sp:Trust13>
           </wsp:Policy>
          </sp:BootstrapPolicy>
         </wsp:Policy>
        </sp:SecureConversationToken>
       </wsp:Policy>
      </sp:ProtectionToken>
      <sp:AlgorithmSuite>
       <wsp:Policy>
        <sp:Basic128Rsa15/>
       </wsp:Policy>
      </sp:AlgorithmSuite>
      <sp:Layout>
       <wsp:Policy>
        <sp:Strict/>
       </wsp:Policy>
      </sp:Layout>
     </wsp:Policy>
    </sp:SymmetricBinding>
    <sp:SignedParts>
     <sp:Body/>
    </sp:SignedParts>
   </wsp:All>
  </wsp:ExactlyOne>
 </wsp:Policy>

Как и в случае обычной WS-Security, в зависимости от реализации необходимо задать дополнительные параметры времени выполнения (такие как хранилища ключей и пароли). Для работы WS-SecureConversation также необходимо применение спецификации WS-Addressing (по крайней мере во время разговора между клиентом и сервисом STS). Включение WS-Addressing также осуществляется по-разному в зависимости от реализации. В следующих трех разделах мы увидим, как в этих трех стеках задаются параметры безопасности времени выполнения и задействуется WS-Addressing.


Конфигурация Axis2

В Axis2 конфигурация WS-SecureConversation в сущности такая же, как и для любого другого варианта использования WS-Security. Если при обмене сообщениями с STS используется асимметричное шифрование, на стороне клиента нужно включить в политику элемент <ramp:RampartConfig>, в котором описываются параметры безопасности времени выполнения. Конфигурационная информация Rampart используется совместно сервисом STS и целевым сервисом.

В листинге 2 показана клиентская конфигурация Rampart, которую мы использовали в тестах производительности в этой статье. Ту же самую конфигурацию мы использовали в предыдущих статьях для применения в Axis2 асимметричного шифрования и подписывания сообщений с помощью WS-Security.

Листинг 2. Конфигурация клиента Axis2/Rampart
<wsp:Policy ...>
  <wsp:ExactlyOne>
   <wsp:All>
    ...
    <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy"> 
      <ramp:user>clientkey</ramp:user>
      <ramp:encryptionUser>serverkey</ramp:encryptionUser>
      <ramp:passwordCallbackClass
        >com.sosnoski.ws.seismic.adb.PWCBHandler</ramp:passwordCallbackClass>
      
      <ramp:signatureCrypto>
        <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type"
            >JKS</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.file"
            >client.keystore</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password"
            >nosecret</ramp:property>
        </ramp:crypto>
      </ramp:signatureCrypto>
      
      <ramp:encryptionCrypto>
        <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type"
            >JKS</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.file"
            >client.keystore</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password"
            >nosecret</ramp:property>
        </ramp:crypto>
      </ramp:encryptionCrypto>
      
    </ramp:RampartConfig>

   </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

В листинге 3 показан код клиента Axis2, используемый для конфигурирования Rampart и включения WS-Addressing. Для конфигурирования Rampart используется тот же код, что и в предыдущих примерах с Axis2, за исключением дополнительной строки, выделенной жирным шрифтом. В ней мы активируем WS-Addressing, подключая модуль addressing.

Листинг 3. Код клиента Axis2
    Options options = client.getOptions();
    options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, policy);
    client.engageModule("addressing");
    client.engageModule("rampart");

Конфигурация сервера Axis2 хранится в файле META-INF/services.xml архива сервиса (AAR). Как и в случае клиента Axis2, базовая конфигурация Rampart совпадает с конфигурацией, использовавшейся ранее в примерах с асимметричным шифрованием и подписыванием сообщений с помощью WS-Security. Однако для активации сервиса STS необходимо добавить в файл строки, выделенные жирным шрифтом в листинге 4:

Листинг 4. Дополняем файл services.xml для сервера Axis2
<serviceGroup>
  <service name="seismic-signencr">
    ...
    <module ref="rampart"/>
    <module ref="rahas"/>
    <module ref="addressing"/>;

    <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>
          ...

          <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
            <ramp:user>serverkey</ramp:user>
            <ramp:encryptionUser>clientkey</ramp:encryptionUser>
            <ramp:passwordCallbackClass
              >com.sosnoski.ws.seismic.adb.PWCBHandler</ramp:passwordCallbackClass>

            <ramp:signatureCrypto>
              ...
            </ramp:signatureCrypto>

            <ramp:encryptionCrypto>
              ...
            </ramp:encryptionCrypto>

          </ramp:RampartConfig>
        </wsp:All>
      </wsp:ExactlyOne>
    </wsp:Policy>

    <parameter name="sct-issuer-config">
      <sct-issuer-config>
        <cryptoProperties>
          <crypto provider="org.apache.ws.security.components.crypto.Merlin">
            <property name="org.apache.ws.security.crypto.merlin.keystore.type"
              >JKS</property>
            <property name="org.apache.ws.security.crypto.merlin.file"
              >server.keystore</property>
            <property name="org.apache.ws.security.crypto.merlin.keystore.password"
              >nosecret</property>
          </crypto>
        </cryptoProperties>
        <addRequestedAttachedRef/>
        <addRequestedUnattachedRef/>

            <!--
               Key computation mechanism
               1 - Use Request Entropy
               2 - Provide Entropy
               3 - Use Own Key
            -->
        <keyComputation>3</keyComputation>

            <!--
               proofKeyType element is valid only if the keyComputation is set to 3
               i.e. Use Own Key

               Valid values are: EncryptedKey & BinarySecret
            -->
        <proofKeyType>BinarySecret</proofKeyType>
      </sct-issuer-config>
    </parameter>

    <parameter name="token-canceler-config">
      <token-canceler-config/>
    </parameter>

  </service>
</serviceGroup>

Во-первых, в листинге 4 добавлены ссылки на модули rahas и addressing. Модуль rahas – это просто конфигурационное дополнение к базовой поддержке Rampart, используемое для активации сервиса STS. В модуле addressing активируется поддержка WS-Addressing, точно так же, как в клиентском коде из листинга 3.

Во-вторых, в листинге 4 добавлен элемент <parameter name="sct-issuer-config">. В нем настраивается, каким именно образом сервис STS должен генерировать токены SCT. Комментарии в содержимом элемента взяты непосредственно из одного из примеров работы с Rampart; видимо, они являются единственной документацией для этой конфигурации. К сожалению, эти комментарии неточны: в действительности при тестировании с использованием Axis2 1.5.1/Rampart 1.5 изменение значения <keyComputation> не влияло на работу сервиса STS, который всегда генерировал ключ самостоятельно и возвращал его клиенту. Это поведение не соответствует используемой политике, согласно которой секретный ключ должен генерироваться на основе сочетания случайных данных, предоставленных как клиентом, так и сервером.


Конфигурация CXF

Конфигурировать WS-SecureConversation в CXF проще, чем в Axis2. На стороне клиента нужно лишь добавить параметры безопасности времени выполнения в используемый клиентом файл cxf.xml. Это делается так же, как и для параметров, используемых для обычной технологии WS-Security. Отличаются лишь имена параметров (все они заканчиваются суффиксом .sct). В листинге 5 показана версия файла cxf.xml, использованная для тестов в этой статье. Относящиеся к SCT параметры выделены жирным шрифтом:

Листинг 5. Клиентский файл cxf.xml
<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>

Сконфигурировать CXF на стороне сервера тоже просто. Нужно изменить файл web.xml, в котором определяется конфигурация контекста CXF, а также файл cxf-servlet.xml, в котором определяется конфигурация конкретного сервиса. В листинге 6 показан файл web.xml, в который мы добавили строку со ссылкой на конфигурацию cxf-extension-addr.xml. В этом файле конфигурируется поддержка технологии WS-Addressing в CXF, которая необходима для обмена сообщениями между клиентом и сервисом STS (а также используется в обмене сообщениями между клиентом и самим сервисом при использовании политики из листинга 1).

Листинг 6. Файл web.xml на серверной стороне 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>

В листинге 7 показан конфигурационный файл cxf-servlet.xml, в котором задан ряд параметров токена SCT, соответствующих параметрам, указанным для клиента в листинге 5:

Листинг 7. Файл cxf-servlet.xml для сервера 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>

Конфигурация Metro

В Metro, как и в Axis2, для задания параметров безопасности времени выполнения следует дополнить политику безопасности. И, так же, как в Axis2, эти параметры для WS-SecureConversation передаются точно таким же образом, как и для WS-Security. В отличие от Axis2, в Metro не нужно указывать на сервере дополнительную конфигурационную информацию о сервисе STS, что делает процесс конфигурирования в Metro намного проще, чем в Axis2.

В листинге 8 показана отредактированная версия клиентского WSDL, в котором параметры безопасности времени выполнения для Metro выделены жирным шрифтом:

Листинг 8. Клиентский WSDL стека Metro с параметрами безопасности
<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>

В листинге 9 показан серверный WSDL, в котором параметры времени выполнения также выделены жирным шрифтом:

Листинг 9. Серверный WSDL стека Metro с параметрами безопасности
<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>

Остальная конфигурация сервиса STS берется непосредственно из общей политики.


Проверяем производительность

Для сравнения производительности мы, как и в предыдущих статьях, будем использовать тестовый сервис, извлекающий данные о сейсмической активности. Этот сервис работает с базой данных, содержащей данные о более чем 93000 землетрясений, произошедших по всему миру за несколько лет. В запросах к сервису указываются интервалы времени и географических координат, а сервис возвращает все землетрясения, попадающие в эти рамки. В статье "The high cost of (WS-)Security" можно ознакомиться с деталями тестового приложения, а также с примерами запроса и ответа.

Как и в предыдущих статьях, мы будем использовать в тестах производительности два набора запросов. Первый набор состоит из 1000 запросов, параметрам которых удовлетворяет малое количество землетрясений из базы данных (в сумме для 1000 запросов возвращается 816 землетрясений). Второй набор состоит из 100 запросов, параметрам которых соответствует большое количество записей в базе данных (в сумме для 100 запросов возвращается 176745 землетрясений). В этих двух последовательностях запросов делается акцент на различных характеристиках производительности стеков Web-сервисов. Результаты первой серии запросов иллюстрируют, насколько быстро стеки обрабатывают запросы с небольшим количеством данных, а второй – насколько быстро стеки обрабатывают большие объемы данных. Каждая последовательность запросов выполнялась несколько раз с различными конфигурациями безопасности, причем отбирались лучшие результаты для каждой конфигурации. Мы тестировали следующие конфигурации безопасности:

  • без применения технологий безопасности (plain)
  • WS-SecureConversation с подписыванием тел всех запросов/ответов (sign)
  • WS-SecureConversation с шифрованием тел всех запросов/ответов (encr)
  • WS-SecureConversation с подписыванием и шифрованием тел всех запросов/ответов (signencr)

Тесты запускались на 64-разрядной системе Mandriva 2009.1 Linux® с процессором Athlon X2 5400+ и 4 ГБ оперативной памяти, с 32-разрядной виртуальной машиной Java 1.6.0_18 от Sun (Oracle) (при данном размере кучи она работает несколько быстрее, чем 64-разрядная JVM). Код сервера выполнялся на Tomcat 6.0.20, сконфигурированном на использование 1024 МБ памяти кучи, а код клиента использовал 512 МБ памяти кучи. В тестах использовались следующие версии стеков Web-сервисов:

  • Axis2 1.5.1 с Rampart версии 1.5
  • Metro 2.0
  • CXF 2.1.8

Если вы хотите выполнить тесты на своей системе и JVM, загрузите код в разделе Загрузки.

Результаты тестов производительности

На рисунке 1 показано время выполнения для серии «маленьких» запросов. Как и в предыдущих тестах, Metro работает несколько быстрее, чем Axis2 и CXF при обработке маленьких сообщений без применения политик безопасности. Это преимущество сохраняется и в случае применения WS-SecureConversation. В целом в тестах с маленькими сообщениями Metro работает примерно на 25 процентов быстрее, чем CXF, и примерно в два раза быстрее, чем Axis2. (На всех графиках этой статьи маленькие столбики - лучше, так как они обозначают более короткое время работы).

Рисунок 1. Время выполнения маленьких запросов
Measured times with small responses

На рисунке 2 показано время выполнения серии больших тестовых запросов. Здесь Metro снова показал себя быстрее остальных стеков, однако его преимущество не так велико, как в тестах с маленькими запросами. В данном случае CXF работает почти также быстро, как Metro, во всех конфигурациях, за исключением использования WS-SecureConversation для подписывания сообщений. И Metro, и CXF работают намного быстрее Axis2 во всех конфигурациях с использованием WS-SecureConversation (более чем на 40 процентов).

Рисунок 2. Время выполнения больших запросов
Measured times with large responses

Преимущество WS-SecureConversation в производительности

Предполагается, что плюсом использования WS-SecureConversation является выигрыш в производительности за счет использования симметричного шифрования вместо асимметричного. На трех следующих графиках показаны результаты соответствующих измерений. На них сравнивается время выполнения тестов в каждом стеке при использовании WS-Security с парами закрытый ключ-сертификат (асимметричное шифрование) и при использовании WS-SecureConversation с секретным ключом (симметричное шифрование). Результаты выполнения тестов с WS-Security взяты из статьи "CXF Performance comparison". В ней тесты выполнялись на той же машине и практически на тех же версиях стеков Web-сервисов (отличается только версия CXF). Результаты выполнения тестов с WS-Security не включают конфигурацию с шифрованием сообщений (она не поддерживается при использовании сертификатов), поэтому мы сравним только время выполнения тестов при подписывании, а также при подписывании и шифровании сообщений.

На рисунке 3 сравнивается время выполнения тестов при использовании Axis 2:

Рисунок 3. Сравнение производительности Axis2
Axis2 performance comparison

На рисунке 4 сравнивается время выполнения тестов при использовании Metro:

Рисунок 4. Сравнение производительности Metro
Metro performance comparison

На рисунке 5 сравнивается время выполнения тестов при использовании CXF:

Рисунок 5. Сравнение производительности CXF
CXF performance comparison

На всех трех графиках вырисовывается одна и та же картина. В случае подписывания маленьких сообщений технология WS-SecureConversation с использованием симметричного шифрования работает намного быстрее, однако это преимущество теряется при работе с большими сообщениями. В случае подписывания и шифрования технология WS-SecureConversation с использованием симметричного шифрования также работает гораздо быстрее с маленькими сообщениями (разница даже больше, чем в случае обычного подписывания сообщений). В случае больших сообщений также наблюдается значительный выигрыш, который все же заметно меньше, чем при маленьких сообщениях.

Итак, о чем это говорит? Подписывание сообщений всегда включает в себя предварительную обработку сообщений, заключающуюся в конвертации XML в каноническую форму. После этого на основе XML генерируется значение хеша. Именно этот хеш в итоге включается в подпись, а генерация подписи – это единственный шаг, которым отличаются симметричное и асимметричное шифрование. С другой стороны, в случае шифрования обработке подвергается весь XML с незначительными модификациями.

Это объясняет результаты. При подписывании большого количества маленьких сообщений в случае асимметричного шифрования большая часть времени тратится на создание подписи. При подписывании больших сообщений намного большее время тратится на приведение XML в каноническую форму и генерацию хеша. Симметричное шифрование всегда работает быстрее, чем асимметричное шифрование (примерно той же надежности), однако в случае подписывания и шифрования выигрыш затушевывается остальными шагами.


Заключение

Технология WS-SecureConversation может дать значительный выигрыш в производительности — при обмене маленькими сообщениями она работает более чем в два раза быстрее асимметричного шифрования с использованием пар закрытый ключ/сертификат в WS-Security. Выигрыш в производительности может быть еще больше, если вы выполняете авторизацию клиентов сервиса, так как авторизацию можно осуществить в рамках работы с сервисом STS, избавившись от авторизации каждого отдельного запроса к сервису.

На начальном этапе WS-SecureConversation требует интенсивного обмена сообщениями на протяжении относительного короткого промежутка времени. Если ваш сервис из тех, с которыми клиенты работают по принципу «запросил и забыл», то не стоит использовать WS-SecureConversation. При ее использовании вы просто добавите много накладных расходов на обмен сообщениями между клиентом и сервисом STS.

Также может случиться, что реализации WS-SecureConversation не столь хорошо взаимодействуют друг с другом, чем реализации обычной WS-Security. В дальнейшем в этой серии статей мы рассмотрим данную тему более подробно. Но сначала в следующей статье мы обсудим использование симметричного шифрования с обычной технологией WS-Security.


Загрузка

ОписаниеИмяРазмер
Исходный код тестов для этой статьиj-jws16-src.zip4.87 МБ

Ресурсы

  • Познакомьтесь с оригиналом статьи - Java web services: WS-SecureConversation performance (developerWorks, июнь 2010 г.).(EN)
  • Axis2 стек Web-сервисов с открытым кодом от Apache Software Foundation.
  • Metro - стек Web-сервисов с открытым кодом, включающий в себя последние реализации Java-стандартов JAXB 2.x и JAX-WS 2.x.
  • CXF - еще один стек Web-сервисов с открытым кодом от Apache.
  • WSS4J - реализация WS-Security с открытым кодом от Apache Software Foundation, используемая как в Axis2, так и в CXF.
  • XWSS - компонент Metro, занимающийся обработкой сообщений согласно политикам WS-SecurityPolicy.
  • Understanding Web Services specifications: в этой серии руководств представлено множество важных стандартов Web-сервисов. Отметим среди них:
  • OASIS Web Services Security (WSS) TC: эта организация отвечает за спецификацию WS-Security, в том числе и за описание профилей токенов безопасности. На их сайте можно найти ссылки на все версии этих стандартов.
  • The W3C Web Services Policy Working Group: эта группа консорциума W3 определяет спецификацию WS-Policy.
  • OASIS Web Services Secure Exchange (WS-SX) TC: эта организация отвечает за технологию WS-SecurityPolicy, WS-SecureConversation и WS-Trust.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java, SOA и web-сервисы, Open source
ArticleID=789483
ArticleTitle=Web-сервисы Java: Производительность WS-SecureConversation
publish-date=01262012