• Оптимизация
  • Социальные сети
  • Sitemap
  • Drupal
  • Usability
  • Юзабилити
  • B2b
  • Антивирус
  • Семантическое ядро
  • Новости
    • <

    Web-сервіси Java: Продуктивність WS-SecureConversation

    1. Серія контенту:
    2. Цей контент є частиною серії: Web-сервіси Java
    3. Про це циклі статей
    4. Конфігуріруем WS-SecureConversation
    5. Лістинг 1. Конфігурація WS-Policy, яка використовується для тестів продуктивності в разі підписування...
    6. конфігурація Axis2
    7. Лістинг 2. Конфігурація клієнта Axis2 / Rampart
    8. Лістинг 3. Код клієнта Axis2
    9. Лістинг 4. Доповнюємо файл services.xml для сервера Axis2
    10. конфігурація CXF
    11. Лістинг 5. Клієнтський файл cxf.xml
    12. Лістинг 6. Файл web.xml на серверній стороні CXF
    13. Лістинг 7. Файл cxf-servlet.xml для сервера CXF
    14. Лістинг 8. Клієнтський WSDL стека Metro з параметрами безпеки
    15. Лістинг 9. Серверна WSDL стека Metro з параметрами безпеки
    16. перевіряємо продуктивність
    17. Результати тестів продуктівності
    18. Малюнок 1. Час виконання маленьких запитів
    19. Малюнок 2. Час виконання великих запитів
    20. Малюнок 3. Порівняння продуктивності Axis2
    21. Малюнок 4. Порівняння продуктивності Metro
    22. Малюнок 5. Порівняння продуктивності CXF
    23. Висновок
    24. Ресурси для скачування

    Web-сервіси Java

    Порівнюємо продуктивність різних стеків Web-сервісів при використанні технології WS-SecureConversation

    Серія контенту:

    Цей контент є частиною # з серії # статей: Web-сервіси Java

    https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=web-сервисы+java

    Слідкуйте за виходом нових статей цієї серії.

    Цей контент є частиною серії: Web-сервіси Java

    Слідкуйте за виходом нових статей цієї серії.

    Про це циклі статей

    Web-сервіси займають одне з центральних місць в сучасних корпоративних Java-додатках. В цій jsp?sort_by=&show_abstract=true&show_all=&search_flag=&contentarea_by=%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F+Java&search_by=Web-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B+Java%3A&topic_by=-1&type_by=%D0%B2%D1%81%D0%B5&ibm-search=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA> серії статей консультант по 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: IncludeTimes tamp /> <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.keysto re </ 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 </ prop erty> <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 ie 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: Se ismicBinding "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 bind ing = "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. Час виконання маленьких запитів

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

    Малюнок 2. Час виконання великих запитів

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

    На малюнку 3 порівнюється час виконання тестів при використанні Axis 2:

    Малюнок 3. Порівняння продуктивності Axis2

    На малюнку 4 порівнюється час виконання тестів при використанні Metro:

    Малюнок 4. Порівняння продуктивності Metro

    На малюнку 5 порівнюється час виконання тестів при використанні CXF:

    Малюнок 5. Порівняння продуктивності CXF

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

    Отже, про що це говорить? Підписування повідомлень завжди включає в себе попередню обробку повідомлень, яка полягає в конвертації XML в канонічну форму. Після цього на основі XML генерується значення хешу. Саме цей хеш в результаті включається в підпис, а генерація підпису - це єдиний крок, яким відрізняються симетричне і асиметричне шифрування. З іншого боку, в разі шифрування обробці піддається весь XML з незначними модифікаціями.

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

    Висновок

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

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

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

    Ресурси для скачування

    Схожі тими

    • Зустрітися з оригіналом статті - 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.

    Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів

    Jsp?
    Отже, про що це говорить?
    IRC (Internet Relay Chat)

    Все права защищены © 2013 IRC-сервер — Irc.Online.com.ua