1. 什么是WS-Security？

WS-Security 是一个 SOAP 的扩展，它提供了对 SOAP 消息的认证和加密。 在介绍 WS-Security 之前，我们有必要了解一下 WS-Security 存在的原因。很多刚刚接触 Web 服务的人都将 SOAP 看作是通过 HTTP 在两个端点之间交换消息的方法。通过 HTTP 可以验证调用方的身份、对消息签名以及对消息内容加密。这可以在以下几方面确保消息的安全性：调用方是已知的，消息接收方可以验证消息在传输过程中没有被 更改，监视网络通信的实体无法识别出所交换的数据。但是如果准备采用 SOAP 消息传递来解决某些复杂问题，则仅仅基于 HTTP 的安全性是不够的。这些复杂问题通常涉及沿着比请求/响应更为复杂的路径发送消息，或者不使用 HTTP 进行传输。调用方以及消息的标识、完整性和安全性需要在多个跃点中保留。沿路由可能需要多个加密密钥。此外还要跨越信任域。HTTP 及其安全机制只面向点到点的安全性。而更复杂的解决方案则需要端到端的安全性。WS-Security 解决的是如何在多点消息路径中维护一个安全的环境。

2. 什么是WS-Addressing？

WS-Addressing 提供了多种与传输无关的机制对 Web 服务和消息进行寻址。 具体来说，此规范定义 XML 元素以标识 Web 服务终结点，并保护消息中的端到端终结点标识。 此规范允许消息处理系统支持通过网络（包含处理节点）以一种与传输无关的方式进行消息处理，而这些处理节点可以是终结点管理器、防火墙和网关。 Web 服务寻址 (WS-Addressing) 定义了两种结构，它们传达的信息一般由传输协议和消息处理系统以一种可互操作的方式提供。 这些结构将该底层信息规格化为一种统一的格式，而对这种格式的处理可以独立于传输或应用程序。 这两种结构就是终结点引用 和消息信息标头。

3. 什么是WS-RM （WS-ReliableMessaging）？

WS-RM 是一个 Web 服务规范，支持在 Web 服务客户机或资源和 Web 服务提供商之间实现 SOAP 消息的可靠传送。目前，有两个层次的规范：1.0 和 1.1，它们在 WebSphere Application Server Version 7（此后简称为 Application Server）中都得到支持。 WS-RM 规范定义了一个线上 (on-the-wire) 协议，旨在解决试图通过 HTTP 之类的连接传送 SOAP 消息时遇到的两个问题： 1. 源或目标端点暂时不可用时（例如，服务器意外重启时），客户机如何确保 SOAP 消息传送？ 2. 从源到目标端点的路径跨越几个不同的传输连接（比如通过防火墙）时，客户机如何确保 SOAP 消息传送？这些连接中的任何一个都可能失败；比如，由于超时。客户机如何检测该状况并重新尝试传送消息？ WS-RM 协议通过定义如何重新发送它认为没有成功发送的消息，以及防止向目标应用程序发送重复消息解决了以上两个问题。通过 Application Server V7 WS-RM 实现，应用程序开发人员可以集中精力关注具体应用程序逻辑，而不是编码与应用程序无关的重试逻辑。 Application Server 仅支持对 Java™ API for XML (JAX-WS) 应用程序和服务应用 WS-RM。您不能将 WS-RM 应用到 JAX-Remote Procedure Call (RPC) 应用程序或服务内的具体操作。

4. 什么是WS-Policy？

Web服务策略框架规范(Web Services Policy Framework，WS-Policy)提供了一种灵活、可扩展的语法，用于表示基于XML Web services的系统中实体的能力、要求和一般特性。WS-Policy定义了一个框架和一个模型，将这些特性表示为策略。策略表示法既支持简单的声明 式断言，也支持比较复杂的条件式断言。策略断言是要表示行为的个体要求、能力或其他特性。例如，可以创建一个策略断言，定义这样一个要求：必须使用受信任 的X.509证书签名SOAP消息主体。WS-Policy只是一个框架，为特定的域定义一套特定的策略断言则是系统的任务。WebLogic Server 9.0为WS-Security和WS-RM(Reliable Messaging)定义了策略断言。有了策略断言之后，还需要将其与web服务关联。至于如何关联，请看我下一篇关于WS- PolicyAttachment的文章。

5. 什么是MTOM（Message Transmission Optimization Mechanism）？

MTOM 全称Message Transmission Optimization Mechanism，即消息传输优化机制。它提出的模型适用于大量数据的交互情况。针对Base64编码情况带来的开销提出的解决方案。当数据量小的时 候，SOAP依然使用XML进行消息的传递。 但是在大量数据情况下，如果数据依然进行Base64编码,会带来33%的额外开销，这样的情况对于大量数据交换的情况是无法容忍的。MTOM 就是针对SOAP 消息传输的基础上提出的改进办法。对于大量数据的传递，不会进行进行Base64编码，而是直接以附件的二进制原始数据的形式封装在SOAP消息的 MIME 部分，进行传输。SOAP 消息通过指向随其发送的 MIME 部分来引用二进制内容，另外包括SOAP基本的XML 数据，这些还是Base64编码。因为此模型与简单邮件协议SMTP 模型基本一致。 MTOM通过简化大量数据的编码过程，从而提高数据的处理效率。因为SOAP消息等必要的信息，MTOM 也有一些必要的开销。MTOM仅在二进制数据元素的大小超过大约 1 KB 时，才能体现出其优势。

MIME表示多用途Internet邮件扩允协议。MIME扩允了基本的面向文本的Internet邮件系统，以便可以在消息中包含二进制附件。 MIME(Multipurpose Internet Mail Extentions)，一般译作"多用途的网络邮件扩充协议"。顾名思义，它可以传送多媒体文件。 MIME (Multipurpose Internet Mail Extensions,多目的Internet邮件扩展)是创建用于电子邮件交换，网络文档，及企业网和Internet上的其他应用程序中的文件格式的 规范。

6. 什么是JSR-181？

JSR181与JSR175介绍 我们先来看一段典型的使用JSR175特征的代码。 ```java package webservices.jsr181.pojo;

import javax.jws.WebMethod;
import javax.jws.WebService; @WebService(name="StringChangerPort", targetNamespace="http://wwtt.bea.com")
public class StringChanger { @WebMethod()
public String toUpper(String upperReqString)
{

这 个类的源代码和普通的JAVA代码没太多区别，但和普通JAVA代码不同的是这里面还包含了很多以@开头的代码，或者称为注释，也就是在Java 5中的新语法，JSR-175。JSR-175规范只是定义这种语法规则，而用这种语法来如何将这个类生成一个Web Service接口，则需要由JSR-181规范来决定。所以这些JSR-175的注释才真正决定了这个Web Service的行为和外观。

也许你会觉得这种语法比较奇怪，有些像普通java方法的语法，只是前面多了一个@。实际在JSR175规范的早期，该语法并不是像现在这样的。如果按早期写法，@WebService()会该写为：

事实上JSR 181是BEA提出的用于加速Web Services开发的一种基于注释驱动的编程模式，并被批准纳入到J2EE 1.5标准。JSR181提供了一种简单的Web Service开发编程模型和标准的编译及部署方式。只需要编写JSR-175风格的注释就可以制定WSDL，消息产生属性，安全认证方式，以及特定的消 息头。

7. 什么是 SAAJ？

SAAJ(SOAP with Attachments API for JAVA) SAAJ是在松散耦合软件系统中利用SOAP协议实现的基于XML消息传递的API规范。顾名思义，SAAJ支持带附件的SOAP消息。 SAAJ 1.2 API主要由javax.xml.soap包组成，它为带有多用途互连网邮件扩展协议(MIME)附件的SOAP消息提供抽象。该API提供了创建到端点的点到点连接的方法、创建并处理SOAP消息和附件的方法，以及接收和处理SOAP错误的方法。 选择SAAJ的理由是什么呢？SAAJ无疑很适合基于文档的同步或者异步Web Service。SAAJ使用简单，有助于您在Java环境中集成各种Web Service，它扩展了对文档风格的Web Service通信的自然支持（natural support）。SAAJ还支持基于标准接口上的XML消息传递，并且这一点得到了供应商的广泛支持。