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
评论