SOAP 基于 Java 消息服务

W3C 刚刚发布了推荐候选 SOAP 基于 Java 消息服务 1.0 详细描述了 SOAP(SOAP 1.1 和 SOAP 1.2) 应当如何绑定到一个支持 Java 消息服务 (JMS) 的消息系统。这一推荐的主要目的是：

…是在于保证不同的 Web 服务供应商实现之间互操作性。同时还应当支持消息者实现他们自己的 Web 服务来作为其基础设施的一部分，并让它们与供应商提供的 Web 服务进行互操作。

这一规范由两个主要部分组成：SOAP/JMS 底层协议绑定 - 规范一致实现所要求的 - 以及 WSDL(1.1 和 2.0) 用于 SOAP/JMS 绑定 - 规范一致实现的可选项。

SOAP 底层传输绑定定义了使用 Java 消息服务发送和接收 SOAP 消息的规则。SOAP/JMS 底层协议绑定包括了哪些 JMS 特性 / 属性在 SOAP 格式层次是“可见的”以及需要哪些 JMS 调用来支持它们；消息内容，包括属性和报头，比如优先级，soapAction，targetService 等等，是如何被处理的；以及 JMS 服务的连接细节。

这一规范将连接到服务目的点一般化了，使用 soapjms:lookupVariant，详细描述了用于查找指定目的名称的技术。该规范所要求的唯一一个 lookupVariant 是基于 JNDI 的 -jms-variat:jndi。其余的连接属性 -soapjms:destinationName，soapjms:jndiConnectionFactoryName，soapjms:jndiInitialContextFactory，soapjms:jndiURL 以及 soapjms:jndiContextParameterType- 都是为基于 JNDI 的 lookupVariant 作支持的。对于非 JNDI 的查找，作出合适的映射就要取决于其实现者了。

该规范同时还引入了一个 SOAP 参数集合，允许将 JMS 特定的消息报头暴露出来。这包括了 soapjms:deliveryMode，soapjms:timeToLive，soapjms:priority，soapjms:replyToName 以及 soapjms:topicReplyToName。最后两个看似完全不合时宜，因为它们是属于 WS-Addressing，而不属于 SOAP 基本定义。

额外的灵活性来自于对 SOAP 特定的 JMS 消息属性的定义：

• soapjms:targetService - 可以被一个目标实现用于分发服务请求。这可以支持在单个队列上复用多个服务访问。
• soapjms:bindingVersion - 被用于指示 SOAP 绑定所使用的版本。
• soapjms:contentType - 允许指明主要消息负载的 MIME 类型。同时它还认定了该消息负载是使用 SOAP1.1，SOAP1.2，SOAP 带附件消息，还是 MTOM 来作为其主要的负载。
• soapjms:soapAction - 它的使用跟 SOAP/HTTP 中的使用一模一样。
• soapjms:isFault - 被用于指明一个消息是错误消息。
• soapjms:requestURI - 用于指明服务的 JMS URI。该规范将这一 URI 定义为一个带有查询参数的 JMS 目的地 URI，表示目的地与参数属性。

该规范同时还讨论了 JMS 消息类型，安全考虑以及消息交换模式。

该规范的第二部分描述了 WSDL 将如何被用来指明使用以及控制 JMS 绑定的操作。

就 WSDL1.1 来说，该规范定义了如下的扩展：

• wsdl11soap11:binding 元素的传输属性获取一个反应了 JMS 传输的新 URL。
• 允许使用 SOAPAction 报头，尽管它是 WSDL 规范显式禁止的。
• 定义了如何设置各种属性来控制绑定的行为 (连接参数，运行时设定)。
• 使用 JMS URI 来定位服务。

就 WSDL2.0 来说，有如下的扩展：

• 绑定元素的 wsoap:protocol 属性获取一个反映 JMS 传输的新的 URL。
• 定义了如何设置各种属性来控制绑定的行为 (连接参数，运行时设定)。
• 使用 JMS URI 来定位服务。

尽管 SOAP 基于 HTTP 允许可操作的消息实现，在很多需要达到零宕机时间和零数据丢失的任务关键系统里，消息是一个更合适的底层传输支撑。因此，许多 Web 服务实现，不管是在 Java 领域还是.NET 领域，都提供了私有的基于消息的 SOAP 支持。从这个角度来看，一个 SOAP 绑定消息的规范已经缺失太久了。

另一方面，这一将 SOAP 映射到 JMS 的规范看上去却并没有为其目标提供一个解决方案“…是在于保证不同的 Web 服务供应商实现之间互操作性”。首先，它将 SOAP 绑定到 JMS，仅此一项就排除了.NET 和 / 或大型机实现。同时，它将 SOAP 拴在了 JNDI 上，这就算在单个企业里都有可能造成互操作性的问题 - 典型的是多个不同的应用服务器集群会有它们自己的 JNDI。最后，除非使用了 高级消息队列协议 (AMQP)，否则不同供应商的消息实现之间不会有线上的互操作性。

查看英文原文： SOAP Over Java Messaging Service