Java Web 服务: WS-Security 的大开销

核心提示： 与 WS-Security 相结合的 XML Signature 和 XML Encryption 的运行方式，以及 WS-Security 和这些 XML 标准的实现所使用的库也是影响性能的因素之一，Java Web 服务: WS-Security 的大开销(5)，还记得 “Jav

与 WS-Security 相结合的 XML Signature 和 XML Encryption 的运行方式，以及 WS-Security 和这些 XML 标准的实现所使用的库也是影响性能的因素之一。还记得 “Java Web 服务：Axis2 WS-Security 签名和加密” 这篇文章说过，签名 XML 消息需要一个叫做规范化 的步骤，用于在捕获签名值之前将 XML 转换为特定的规范格式。标准需要这一步骤是因为已经确定即使在解析器分解 XML 并重新生成它之后也需要保留签名。虽然这毫无疑问是 XML Signature 的一个实用的特性，但它为处理增加了大量的开销。在一定程度上，由于使用 DOM 模型是实现规范化最简单的一种方法，因此 XML 安全性库都被设计为操作 XML 的 DOM 表示。（这是为何 Rampart 处理程序即使在参与服务或客户机任务时也要生成 DOM 的原因，但前提是 DOM 有必要的作用）。仅将数据转换成 DOM 表示的步骤就会造成大量的 WS-Security 开销，这可以从 UsernameToken 时间看出。在大响应消息的情况中，这种开销看上去与实际的签名或加密处理相当（如 图 1 所示，比较 username 测试的红柱 — 其中，唯一的主要开销是 DOM 的创建 — 与 sign 和 encr 测试的红柱，其中，实际的加密处理是在创建 DOM 之后完成的）。

除了 DOM 问题之外，大部分 WS-Security 开销都是计算紧密型的生成摘要和加密数据的任务。这一部分的工作是必需的，而与所使用的实现方法无关，因此 WS-Security 处理时间的改善是有限的。本系列的后续文章将比较其他一些使用 Axis2/Rampart 的 WS-Security 实现的性能 — 但是，它们大多数都使用相同底层库，因此不要指望能看到巨大的差异。

WS-SecureConversation

WS-SecureConversation 是在 WS-Security 和 WS-Trust 标准之上构建的一种标准，用于支持涉及多个消息的安全交换。由于它所使用的上下文针对运行中的消息交换，因此 WS-SecureConversation 更有可能比 WS-Security 实现更高的效率。Rampart 发行版包括一个单独的 rahas 模块，它支持发起 WS-SecureConversation 所需的安全令牌。它还包括一个使用 WS-SecureConversation 的策略配置示例（samples/policy/sample04），用于作为性能测试应用程序所使用的策略基础。