个支持Java消息服务(JMS)
消息系统
这推荐主要目是:...是在于保证区别
Web服务供应商实现的间互操作性同时还应当支持消息者实现他们自己Web服务来作为其基础设施部分
并让它们和供应商提供Web服务进行互操作
这规范标准由两个主要部分组成:SOAP/JMS 底层协议绑定-规范标准致实现所要求-以及WSDL(1.1和2.0)用于SOAP/JMS绑定-规范标准致实现可选项SOAP底层传输绑定定义了使用Java消息服务发送和接收SOAP消息
规则SOAP/JMS底层协议绑定包括了哪些JMS特性/属性在SOAP格式层次是“可见”以及需要哪些JMS
来支持它们；消息内容包括属性和报头比如优先级soapActiontargetService等等是如何被处理；以及JMS服务连接细节这
规范标准将连接到服务目点般化了使用soapjms:lookupVariant详细描述了用于查找指定目名称技术该规范标准所要求唯个lookupVariant是基于JNDI-jms-variat:jndi其余连接属性-soapjms:destinationNamesoapjms:jndiConnectionFactoryNamesoapjms:jndiInitialContextFactorysoapjms:jndiURL以及soapjms:jndiContextParameterType-都是为基于JNDIlookupVariant作支持对于非JNDI查找作出合适映射就要取决于其实现者了该规范标准同时还引入了
个SOAP参数集合允许将JMS特定消息报头暴露出来这包括了soapjms:deliveryModesoapjms:timeToLivesoapjms:prioritysoapjms:replyToName以及soapjms:topicReplyToName最后两个看似完全不合时宜
它们是属于WS-Addressing而不属于SOAP基本定义额外
灵活性来自于对SOAP特定JMS消息属性定义:* soapjms:targetService -可以被
个目标实现用于分发服务请求这可以支持在单个队列上复用多个服务访问 * soapjms:bindingVersion - 被用于指示SOAP绑定所使用
版本 * soapjms:contentType - 允许指明主要消息负载
MIME类型同时它还认定了该消息负载是使用SOAP1.1SOAP1.2SOAP带附件消息还是MTOM来作为其主要负载 * soapjms:soapAction - 它
使用跟SOAP/HTTP中使用模样 * soapjms:isFault - 被用于指明
个消息是
消息 * soapjms:requestURI - 用于指明服务
JMS URI该规范标准将这URI定义为个带有查询参数JMS目地URI表示目地和参数属性 该规范标准同时还讨论了JMS消息类型
安全考虑以及消息交换模式该规范标准
第 2部分描述了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)否则区别供应商消息实现的间不会有线上互操作性
最新评论