WS-标准

WS-AtomicTransaction（原子）：

是一种可互操作的事务协议。它使您能够使用 Web 服务消息对分布式事务进行流处理并以可互操作的方式在异类事务基础结构之间进行协调。WS-AT 使用两阶段提交协议在分布式应用程序、事务管理器和资源管理器之间驱动原子结果的生成。

WS-Coordition（协调） protocols：

在介绍WS-Coordination规范前，首先让我们了解一下Coordination的概念以及它的应用背景。

简而言之,一个实体和一个活动的参与者之间传递消息的过程就可以称之为Coordination。例如在实现分布式事务时，就需要由事务管理器在各个资源管理器之间相互协调，并且由2PC（两阶段提交协议）规定了具体的协调过程。为了控制工作流的运行，也会需要使用协调者与工作流中的各个活动打交道。使用Coordination的目的可以是为了在多个参与者之间达成一致的结果，也可以仅仅是为了在某个特定的条件下让参与者都接收到在应用领域中某个特定的消息。 

根据以上特点，不难推断在分布式领域中存在许多需要使用Coordination的应用。但是，在实际的应用中，不同的开发平台都使用各自不同的协调框架。比如在OASIS的Business Transactions Protocol和OMG的Object Transaction Service中同样为了实现分布式事务却各自设计了不同的协调框架。在这种情况下不仅出现了重复设计的问题，并且由于协调框架与事务处理框架的紧密结合，使得开发者无法灵活高效的使用到Coordination的功能。 因此设计出一个更加通用并且专门针对Coordination需求的框架，成为了一项非常有应用价值的任务。Coordination框架在事务处理，工作流管理甚至活动状态管理中都将发挥重要作用。

为了能够在Web Services的环境下拥有一个通用的协调框架，以解决各种需要使用协调功能的应用，BEA,IBM,MS等公司共同制定了WS-Coordination规范。WS-Coordination规范的一个重要特点就是它提供一个开放的协调框架，每个具体的应用都可以在此基础上设计自己的协调协议以控制整个协调过程，以达到各自的应用目的。比如在WS-AtomicTransaction规范中，设计了Completion和2PC(2 Phrase Commit)两套协议以实现Web Services组合活动的事务性。

WS-ReliableMessaging：

在 Web 服务中，可靠的消息传递的目标是使应用程序简单地、可靠地、有效地发送和接收消息，甚至在应用程序、平台或网络失败的情况下。最近由 BEA、IBM、Microsoft 和 Tibco 联合发布的 WS-ReliableMessaging 规范（请参阅 参考资料）定义了一种协议和一套机制，使 Web 服务的开发人员能够确保在两个端点之间可靠地传递消息，该规范还具有各种传递保证和健壮性特征。

然而，仅靠 WS-ReliableMessaging 规范并不足以解决在实现不同程度的健壮性、完整性和性能（它们通常是应用程序要求的）时必须考虑的许多重要注意事项。

 

WS-Security

WS-Security 描述通过消息完整性、消息机密性和单独消息认证提供 保护质量对 SOAP消息传递的增强。这些机制可以用于提供多种安全性模型和加密技术。 

WS-Security 还提供关联安全性令牌和消息的通用机制。WS-Security 不需要特定类型的安全性令牌。它在设计上就是可扩展的（例如支持多安全性令牌格式）。举例来说，客户机可能会提供身份证明和他们有特定商业认证的证明。

另外，WS-Security 还描述如何对二进制安全性令牌编码。此规范特别描述如何对 X.509证书和 Kerberos票据编码以及如何加入难于理解的加密密钥。它还包括可以用于进一步描述消息中包含的凭证特征的扩展性机制。 

随着客户应用程序用例的逐步发展，确定了一套有关安全性的非功能性需求：

1.客户与其业务伙伴之间的通信在因特网上传播时不应该被第三方看到。 

2.客户必须能够确定消息来自哪个人并能够证实发送方就是那个发送方声称的发送方。 

3.客户必须能够确定被传送的数据没有被篡改。 

使用 HTTPS/SSL 传输安全性可以解决非功能性需求 #1。 因为这个应用程序将是个点到点应用程序，不涉及第三方服务提供者或者中介者，所以目前只是对使用密码术加密整个 SOAP 消息或加密 SOAP 消息的一部分这种想法进行了评价但还未实现。假如不涉及第三方，用来对 SOAP 消息的某一段进行加密的额外加密步骤所带来的价值就不足以证明实现某种形式的消息级加密所需的额外开发成本和复杂性是值得的。

使用数字签名和数字证书可以解决非功能性需求 #2 和 #3。当使用数字证书方法时，Web 服务请求者必须有一个由 可信认证中心签署的数字证书。请求者将使用这个证书来表明他们的身份，并对 SOAP 消息进行数字签名，这样就可以验证请求者的身份和消息的完整性。 

一旦客户的系统接收到消息，就要对消息做时间戳记并进行日志记录。此时，数字签名会得到验证。验证过程将确保消息来自发送方，并且由于消息内容是在发送方的站点上签署的，所以还要验证消息内容在传输过程中没有被篡改。我们的客户在 DB2 中创建的 SOAP 消息日志将被用于实现不可抵赖性。

实现 WS-Security

Web 服务安全性（WS-Security）

WS-Trust 

WS-Security 规范已经定义了通过使用安全性令牌来安全地交换消息的基本机制。WS-Trust 规范以这个模型为基础进行构建，定义了如何发出和交换这些安全性令牌。

WS-Trust原理上类似SSL或TLS的机制，客户端不必有服务端的证书，服务端证书可以通过消息交换交换到客户端。WS-Security 规范则不同，它没有定义安全令牌的交换，所以客户端需要事先把安装服务端证书，并在通讯时指定服务端证书。