看看 Web 服務棧 WS-SecureConversation 性能相比較有何不同
簡介：WS-SecureConversation 能讓您保證正在進行的 Web 服務消息交換的安全，同時花費比普通 WS-Security 更少的處理開銷。在本文中，您將學習如何配置 WS-SecureConversation 並將其用於三個 主要的開源 Java™ Web 服務棧：Apache Axis2、Metro 和 Apache CXF。還將看到這三個棧的 WS -SecureConversation 性能上的對比。
WS-Security 提供了必要的特性以保證商務 Web 服務的安全，但經常會付出沉重的性能代價。在 “WS-Trust 與 WS-SecureConversation” 中，您了解到如何在 WS-Security 和 WS-Trust 上構造 WS-SecureConversation 用對稱加密來保證客戶端和服務器端持續進行的消息交換的安全。本文 中，您將學習如何配置 WS-SecureConversation，用於三個主要開源 Java Web 服務棧 — Apache Axis2、Metro 和 Apache CXF — 還將看到與 WS-Security 非對稱加密相比，對性能的影響。
配置 WS-SecureConversation
如 上篇文章 所討論的，WS-SecureConversation 消息交換中的 客戶端首先連接到 Security Token Service (STS) 終端來建立安全上下文，它包含一個共享密鑰。然後 該共享密鑰用作加密及/或與目標服務的簽名消息交換。安全上下文由 Security Context Token (SCT) 確認，由 STS 返回到客戶端。SCT 由客戶端包含在所有對服務的請求中，作為安全對話的一部分， 並被 服務在所有響應中引用。
至於普通 WS-Security，安全配置在 WS-Policy 文檔中定義。當使用 WS-SecureConversation 時：兩個單獨的安全配置出現在服務策略中，一個用 STS 用於消息交換，另一 個用於目標服務。STS 安全配置嵌在安全對話令牌的策略定義中。
本文中不同的 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 是另一與實現相依賴的特性。以下三節中， 您將看到三個 Web 服務棧如何各自處理安全運行時參數和 WS-Addressing 使用。
Axis2 配置
WS-SecureConversation 的 Axis2 客戶端配置與所有 WS-Security 用法基本相同。如果與 STS 的消息交換使用非對稱加密，客戶端必須在策略中包含 <ramp:RampartConfig> 元素以提供安全運 行時參數。Rampart 配置信息在 STS 和服務自身之間共享。
清單 2 顯示本文中性能測試中用到 的 Rampart 客戶端配置。這與此前文章中 WS-Security 非對稱簽名和加密的 Axis2 例子中的配置一致 。
清單 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 顯示的是用於配置 Rampart 和激活 WS-Addressing 的 Axis2 客戶端代碼。Rampart 配置使用此前 Axis2 例子中同樣的代碼，除了在粗體行中添加了通過啟用 addressing 模塊激活 WS-Addressing。
清單 3. Axis2 客戶端代碼
Options options = client.getOptions();
options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, policy);
client.engageModule("addressing");
client.engageModule ("rampart");
Axis2 服務器配置包含在服務檔案 (AAR) 文件的 META-INF/services.xml 文件中。至於 Axis2 客戶端，基本的 Rampart 配置與之前 WS-Security 非對稱和加密的 Axis2 例子中 一致。激活服務的 STS 還需要補充一些東西，如清單 4 中已編輯版本的粗體部分：
清單 4. Axis2 服務器 services.xml 添加項
<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 配置
配置 CXF 的 WS-SecureConversation 比 Axis2 方法更 簡單。在客戶端，所要做的就是向客戶端使用的 cxf.xml 文件添加安全運行時參數。同樣方法可用於常 規 WS-Security 的參數，只要用不同的參數名（都以後綴 .sct 結尾）。清單 5 顯示的是本文測試中使 用的 cxf.xml，SCT 參數粗體顯示：
清單 5. CXF 客戶端 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 中服務器端的配置也很簡單，但需要改變定義 CXF 上下文配置的 web.xml 文件和給出單個服務定義的 cxf-servlet.xml 文件。web.xml 文件，如清單 6 所示，添加了一 行引用 cxf-extension-addr.xml 配置。加入的引用中包含 CXF 配置的 WS-Addressing 支持，這是客戶 端和 STS 之間交換消息所需的（還用於客戶端和實際服務的消息交換，使用的是 清單 1 策略）。
清單 6. CXF 服務器 web.xml
<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 服務器 cxf-servlet.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"
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. Metro 客戶端 WSDL 及參數
<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. Metro 服務器 WSDL 及參數
<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 配置其余部分直接 從通用策略中取得。
檢驗性能
性能比較采用與之前文章一樣的測試代碼，地震數據檢索服 務。服務使用的是幾年中發生的超過 93,000 次地震的數據庫。服務請求指定時間范圍和地理坐標范圍， 服務返回指定范圍內的所有地震。見 “WS-Security 的大開銷”，其中詳細介紹測試應用程 序和請求/響應消息示例。
如此前文章所述，有兩組請求序列用於性能測試。第一組使用 1,000 次請求，查詢參數設置為整個地震數據庫的一小部分（1,000 次請求返回 816 次匹配的地震）。第二組 使用 100 次請求，設置為匹配數據庫的較大部分（100 次請求返回 176,745 次匹配地震）。這兩個請求 序列強調不同的網絡服務堆棧的性能特點。第一個顯示棧處理少量數據的請求有多快，第二個強調處理大 量數據的速度。每個請求序列在不同安全配置下運行多次，結果取每種配置下的最好成績。測試的安全配 置如下：
無安全（plain）
WS-SecureConversation 對所有請求/響應消息主體簽名（sign ）
WS-SecureConversation 對所有請求/響應消息主體加密（encr）
WS- SecureConversation 對所有請求/響應消息主體加密簽名並加密（signencr）
測試是在 Mandriva 2009.1 64-bit Linux 系統，Athlon X2 5400+ 處理器和 4GB RAM 上運行，使用的是 Sun (Oracle) Java 1.6.0_18 32-bit JVM（對於給定的堆尺寸，它性能比 64-bit JVM 好得多）。服務器代碼運行在 Tomcat 6.0.20 上，配置為使用 1024MB 的堆，客戶端代碼使用 512MB 堆。測試的 web 服務棧版本是：
Axis2 1.5.1 與 Rampart 1.5 發行版
Metro 2.0
CXF 2.1.8
如果您想在自己的 硬件和 JVM 上測試，請查看 下載，獲取代碼。
性能結果
圖 1 顯示的是小響應測試系列 的測出次數。與 前一組測試 中的表現一樣，Metro 在無安全運行時處理這些小消息比 Axis2 和 CXF 快 一點，並且這種優勢延續到使用 WS-SecureConversation 的測試。總的來說，Metro 在這個小響應系列 中比 CXF 快 25%，是 Axis2 的兩倍。（ 在本文圖表中，更短的指示條更好，這表示更快。）
圖 1. 小響應測出次數
圖 2 顯示的是小響 應系列的測出次數。Metro 還是其中最快的，但不如小響應測試中明顯。本例中，CXF 實際上在所有配置 中與 Metro 一樣，除了 WS-SecureConversation 用於僅簽名時。Metro 和 CXF 在所有 WS- SecureConversation 中都比 Axis2 快（快超過 40% ）。
圖 2. 大響應測出次數
WS-SecureConversation 優勢
WS-SecureConversation 的一個優勢是使用對稱加密比使 用非對稱加密更能取得性能收益。以下三張圖片顯示實際是如何達到的。對比每個棧使用 WS-Security 及私鑰和證書（非對稱加密），以及同樣的棧使用 WS-SecureConversation 與密鑰（對稱加密）運行測 試的次數。WS-Security 次數從 “CXF 性能比較” 中獲取，在同樣的硬件和幾乎一樣的 web 服務棧上運行。（只有 CXF 版本不一樣。）由於 WS-Security 測試次數不包括僅加密配置（不支持使用 證書），只比較簽名與簽名加密測試。
圖 3 比較了 Axis 2 次數：
圖 3. Axis2 性能對 比
圖 4 比較了 Metro 次數：
圖 4. Metro 性能對比
圖 5 比較了 CXF 次 數：
圖 5. CXF 性能對比
這三張圖顯示了類似 的模式。在小響應中使用 WS-SecureConversation 對稱加密的僅簽名測試結果要快得多，但當返回大響 應時，其優勢喪失。在大響應中使用 WS-SecureConversation 對稱加密的簽名加密測試獲得較大性能收 益（甚至比僅簽名結果更好），但在大響應中明顯偏小。
這說明什麼？簽名消息總是包含預處理 ，將 XML 轉換成標准格式。完成之後，XML 被翻譯生成 hash 值。hash 值最終包含在實際簽名中，生成 的簽名是非對稱與對稱僅有的不同之處。另一方面，加密消息，只對所有 XML 進行小修改。
這就 解釋了以上結果。當使用非對稱加密對很多消息簽名時，大多數處理時間花在簽名上。如果對大消息簽名 ，更多的時間花在規范化和消化步驟上。對稱加密總是比非對稱加密快（對大致相當的強度而言），但對 簽名和加密都有的情況，收益就平均了。
結束語
WS-SecureConversation 能提供大幅性能 收益 — 小響應測試中超過雙倍 — 對於持續進行的消息交換，與使用私鑰證書對 WS- Security 非對稱加密對比而言。當授權服務客戶端時，收益會更大，這是因為授權步驟在 STS 中處理而 不是在對服務的單個請求中處理。
為了能獲取收益，WS-SecureConversation 需要正在持續的消 息序列處於相對較短時間內。如果用於客戶端一次性訪問的服務，由於客戶端和 STS 之間消息交換的原 因，實際是增加了開銷。
WS-SecureConversation 支持的交互性可能不如普通 WS-Security。我 將在本系列的後續文章中詳述。但在下個月的專欄中，我們將首先討論使用對稱加密及常規 WS-Security 。
下載
描述 名字 大小 下載方法 本文源代 碼 j-jws16-src.zip 4.87MB HTTP
