Java Web Services:不使用客户端证书的WS-Security

核心提示：性能比较性能比较使用与之前文章相同的测试代码，即地震数据查询服务，Java Web Services:不使用客户端证书的WS-Security(3)，这个服务使用了几年里全世界所发生的超过 93,000 次地震的数据库，发向服务的请求指定了一个时间范围和地理坐标范围，大约快 30%，（在本文的两个图表中，而这个服务将返

性能比较

性能比较使用与之前文章相同的测试代码，即地震数据查询服务。这个服务使用了几年里全世界所发生的超过 93,000 次地震的数据库。发向服务的请求指定了一个时间范围和地理坐标范围，而这个服务将返回所指定范围的所有地震数据。请阅读 “WS-Security 的大开销” 了解更多关于这个测试应用和示例请求/响应消息对的详细信息。

在之前的文章中，性能测试使用了两组请求序列。第一组使用了 1,000 个请求，其中查询参数被调整为只匹配整个地震数据库的一小部分（1,000 个请求只返回 816 个匹配的地震）。第二组使用了 100 个请求，其中查询参数被调整为匹配更大范围的数据库（100 个请求只返回 176,745 个匹配的地震）。这两个请求序列侧重于 Web Services 协议的不同性能特征。第一个显示这些协议处理包含少量数据的请求的速度有多快，而第二个强调处理数据容量的速度。每一个请求序列都会以不同的安全性配置多次运行，而结果只保存每一种配置的最短时间。而这一次，我们只测试两个安全性配置：

使用 SymmetricBinding 加密所有的请求/响应消息体的 WS-Security （direct）

加密所有请求/响应消息体的 WS-SecureConversation（securconv）

securconv 配置本质上与 “WS-SecureConversation 性能” 中所使用的配置是相同的，唯一的区别是它在 Metro 和 CXF 的客户端和 STS 之间的消息交换中使用了 SymmetricBinding。因为所测试的 SymmetricBinding STS 策略不能在 Axis2 中运行，用于计时测试的 Axis2 配置与前一篇文章所使用的是相同的。在策略中使用 SymmetricBinding 的变化更多是出于演示的目标，而不会对性能带来重要影响，所以这个区别不会影响到结果。

这些测试是在运行 Mandriva 2009.1 32-bit Linux® 的笔记本电脑上的，它使用了 Turion X2 ZM-85 处理器，有 3GB 的 RAM，安装了 Sun (Oracle) Java 1.6.0_10 32-bit JVM。（注意，它与前面文章的性能测试所使用的系统不一样。）服务器代码运行在 Tomcat 6.0.20 上，它的配置使用 1024MB 的堆，其中客户端代码使用 512MB 的堆。所测试的 Web Services 工具版本如下：

Axis2 1.5.1 和 Rampart 1.5

Metro 2.0

CXF 2.1.8

如果您想要在您自己的主机和 JVM 上进行这些测试，您可以从这里 下载 代码。

性能测试结果

图 1 显示了在小响应测试中所测得的时间。正如 “WS-SecureConversation 性能” 所介绍的，在 WS-SecureConversation 计时中 Metro 比 CXF 稍微快一些（大约快 10%）。Metro 甚至比直接使用对称加密实现 WS-Security 还要快一些，大约快 30%。（在本文的两个图表中，较短的数据条表示更快一些的时间）。

图 1. 使用小响应的测试时间