IBM MessageBroker笔记系列

IBM MessageBroker笔记系列(一)
前言
       SOA 已经在中国喊了几年,连象牙塔的大学生都知道了,但实施的案例并不多,而作为SOA 基础设施的企业服务总线ESB ,在国内的应用更是稀少,主要都是银行和电信等大牌企业在使用。我算非常好彩,打工所在的公司恰好要为客户开发一个基于MB WAS 的平台,让我有很多机会接触到MB 的应用。现在国内MB 的资料非常少,主要是IBM 的红皮书,可惜全部都是英文的,看起来颇费力,效率也不高;出版物我所知的只有一本,是陈宇翔先生所著的《精通Websphere Message Broker 》【中国水利水电出版社】,也是目前手边唯一的一本参考书。因此希望将这段时间的一些使用心得记下来,作为一个从未接触过SOA MB (甚至没用过websphere 产品)的菜鸟,面对这个上百万人民币的庞然大物,应该怎样下手
 
书评
       先来说说这段时间翻阅的一些MB 的书籍,包括纸质和电子版,首先是上文说到的《精通Websphere Message Broker 》这本书。本来这种书给人的第一反应就是:一本红皮书的翻译,无非就是从IBM 的各个红皮书里面摘抄文字,翻译好之后综合一下的“大杂烩”。老实说这本书里面的确有很多翻译的内容,比如MB toolkit 中自带的一些教程,以及MB Information center 里面的部分实例,书的后半部分都是附录,包括函数库、命令库,等等。但是不可否认的是,IBM 的红皮书、InfoCenter 本身就是相当好的教程库,而这本书用到其中的内容也翻译的流畅,所以也是方便了国内读者。而且,作者本身也的确有一些MB 的使用经验,书中也有他自己的内容。所以,这本书作为入门的话,实在是比较辛苦,因为没有考虑太多初学者的难处,内容的编排也不太合理,但是作为一本参考书却是不错的选择。在如今没什么资料的情况下,最好咬牙坚持看下去。
       再说说IBM 提供的电子资源,包括红皮书和网上资料,以及InfoCenter 。只要你买了MB 的产品,IBM 自然会提供一堆红皮书给你,当然你也可以慢慢从网上下载,这些红皮书很多写的不错,但是要从头看太痛苦,作参考比较好。此外如果你购买MB 的培训,那么培训机构也会给你一些pdf 材料(其实都是IBM 出品的),这些材料相对易懂,适合入门。再有就是developerWorks IBM 的官方技术网站,里面提供最新最全的资料,有空多去看看,也可以订阅它的邮件。最后是InfoCenter ,其实说白了是网页版的手册,可以在线看也可以下载,相对其他来说,难度介于中等,而且不像网站的资源那么零散,所以也是很好的提高阶段的学习资料。
 
ESB产品
       如果你还不清楚ESB 的概念,和IBM 的相关产品,可以去IBM 网上查查资料, 作为一个菜鸟我没法全面评论当前的ESB 产品,只能记录一下自己的所见所闻(就是跟IBM BEA 公司打交道的时候听到的一些内容)。撇开两者的应用服务器不谈(这方面的口水战已经够多了,国内用BEA 的相对多,容易上手适合快速开发,性价比很高),SOA ESB 方面,IBM 无疑是走在前面的,这个可以从两者的产品线看出来。BEA ESB 产品只有一款AquaLogicBus IBM 却已经开始划分各类市场、推出不同档次的产品了(但这个也是BEA 宣传的好处之一,买一个就能到处用,见仁见智了);其二,BEA 自己的销售都对AquaLogic 不甚了解,而且在国内尚无成熟应用,这点是很多企业最关注的,没有成熟应用意味着没有好的技术支持,出了问题不知道找谁解决,甚至从没有人遇过这种问题;而IBM 这两年在SOA 的推广方面做得比较好,广告也做得多,在国内已经有一些成功案例,技术支持也更加完善,我们在广州就能直接联系到工程师,而不必等北京、上海,甚至国外的支持。
       MB 在对异构环境的支持方面,做得也比AquaLogicBus 好,可以支持几十种通信协议和平台,而且天生和IBM 自家的大型机等结合的比较好,AquaLogicBus 支持的就相对比较少,主要是基于java 平台的SOA 流行协议,比如web service ,给人感觉更像是websphere ESB 的竞争对手。但是BEA 的产品向来给人的感觉是除了在IBM 的平台,其他平台上都比IBM 的同类产品性价比要高,不知道AquaLogicBus 是不是也一样表现优秀,这个就需要专业的测试了。
       另外很重要的一点,就是BEA 的消息中间件做得不如IBM MQ 强大,而MB 又是依托于MQ 才能有如此强大的功能,这个是BEA 的销售也不得不承认的。尽管Web service 是当前SOA 的主流,但是性能方面却是不敢恭维,在企业内部实施SOA ,如果服务组件都用web service 连接,虽然更加通用、更加廉价易用,但是往往会有性能瓶颈,关键地方还得靠消息中间件。
       最后呢,就是BEA 工作人员对于自家的产品,底气明显不足,一方面是不熟悉,另一方面也是国内用的少,也侧面反映了对于这类重量级产品、而且关乎整个系统性能的底层部件,人们还是倾向于选择IBM ,将来SOA 应用普及了,AquaLogicBus 肯定也会遍地开花,就像现在的weblogic 一样。只是目前来看,还是选择MB 更让人放心。
       还有一个不得不提到的有力竞争者是来自开源社区的JBOSS ESB ,这个产品我没了解过,但是现在Reahat 收购了JBOSS ,在JBOSS AS ESB 上也下了相当大力气,誓要在SOA 市场与IBM BEA 分一杯羹。很看好JBOSS 的潜力,只是开源产品在中国连个服务中心都没有,暂时只能供高手们自己研究着玩了。
 
IBM Message Broker笔记系列(二)
赶在这周结束前,再写一篇
MB概述
MB的全称是message broker,即“消息代理”。“消息”一词前几年比较火,消息中间件也卖的很火,当时似乎J2EE的产品都要跟“消息”、“中间件”扯上点关系,以彰显潮流。我觉得初学者只需记住“消息”的异步性即可,也就是“消息”和传统的网络连接、远程方法调用等的最大区别,就是你一旦发出消息以后,不用再管它的死活,中间件会处理一切事务,出了问题也会通知你,这样可以更好的分离业务逻辑。把消息当成邮件的话,那么传统网络连接就是由你去送信,而中间件则好比邮局,它来提供送信服务,并且可以跨国境、跨语言,完全不用你操心(相当于中间件可以连接异构平台),使用者只需等在家门口收信。
在说“代理”之前,先讲一下MQ的基本概念。MQ即message queue,消息队列,也就是IBM的主打消息中间件产品,IBM几乎所有SOA相关的产品,都是构建于MQ之上的,没有MQ强大的消息传输能力,那么IBM很多产品都做不起来。在这里不赘述MQ的功能,初学者只需把MQ当成一个非常可靠的传输通道即可,你只要往里面放东西,MQ就会把消息传到目的地。
那有了强大的MQ还要“代理”干什么呢?如果你用过MQ,或者类似的产品如apache的开源JMS产品“ActiveMQ”,就会发现,尽管用MQ不必考虑网络连接、平台异构,但是你在配置的时候、以及使用MQ编程的时候,都要指定目的地,比如设置IP地址。这样的程序依旧存在很大耦合性,万一某个组件的IP变了,所有跟他相关的组件都得改动,轻则修改配置文件、重则重写代码。这时“代理”的作用就开始凸显了。
所有组件的MQ队列都可以直接连接到MB上,MB相当于一个公共服务中心。MB接收所有消息,然后自动分析其中的内容,找到相应的目的地,进行路由转发,好比你在写信时,只需写明收信人的姓名、身份证,哪怕收信人搬到天涯海角,只要他在MB邮局中登记了,那MB就可以把信交给他,这样进一步地分离了业务和底层通信,我只需要知道业务概念上的“他”,就可以把消息交给他。此外,MB还可以进行消息转换,这就像是自动翻译信件,我现在可以用中文写封信给本拉登,我不需要知道他具体藏在哪里,信件就会自动翻译成阿富汗的文字,送到本拉登手里。
所以,代理的两个核心功能就是:“消息路由”和“消息格式转换”。MB本质上也是一个服务总线,所有的服务组件接入到MB中,服务将消息塞给MB,MB来决定怎么转发,这样让服务愈加成为一个独立的实体,和其他服务的耦合性进一步降低,从而达到SOA的境界。
 
MB初览
说了那么多大道理,终于开始讲到MB的具体内容了。下面的图片摘自IBM的红皮书,是MB的总体架构,我粗略的描述一下。
IBM MessageBroker笔记系列_第1张图片
可以看到,MB里面有两大块内容,一个是toolkit,也就是开发环境,后面我们会讲到;还有一个是broker domain,即代理域。代理域里面有两个核心部件,一个是配置管理器configuration manager,一个是代理broker。
配置管理器其实很像MQ的队列管理器,或者是WAS的deployment manager,都是起到一个管理作用,在MB里当然是管理众多的broker了。我们平时对broker的管理、维护操作,其实都是通过配置管理器完成的。
代理broker是真正体现MB设计思想的地方,上面的图片中有像流程图一样的东西,即message flow,是消息的流程图(从什么地方流进来,再从什么地方流出去);还有message set,即消息集,说白了是描述消息长什么样子,它的结构、内容是怎样的。其实,message flow对应了上文所说的“消息路由”,而message set则对应“消息格式转换”,你肯定要清楚两种消息的格式,才能定义互相转换的规则。
IBM MessageBroker笔记系列_第2张图片
MB的外围是各种类型的应用程序,他们接入MB的方式可以多种多样,可以是Webservice,也可以是数据库、文件、HTTP连接,等等,不一定局限于MQ
圆柱体代表的则是数据库了,这是尽IT人皆知的。因为MB的很多信息,包括配置信息、以及broker的运行时信息都要通过数据库保存。broker本身也可以操作数据库,你可以在流程的某个节点上增删查改某个数据库
 
下图是WMBT(websphere mb toolkit)的界面
IBM MessageBroker笔记系列_第3张图片
可以看到,WMBT是基于eclipse的,所以大部分java开发者应该能很快上手。开发MB程序和开发J2EE程序差不多,也是先新建一个项目,然后编辑,最后部署。
1号区域是一个消息流,可以看到非常直观:从MQ读入——计算(转换成web service格式)——发送http请求到web service的url——计算(转换回MQ消息格式)——放入MQ
2号区域是节点选择面板,MB自带了几十种节点给我们选择,同时我们也可以自己创建节点
3号区域是属性面板,当你选择某个节点时,可以在其中编辑节点的属性
4号区域是域连接面板,开发好的消息流和消息格式,必须首先在MBT中连接到对应的配置管理器,再将打包好的流程部署到对应的broker中,这个过程也可以由命令行完成
5号区域则类似eclipse的项目集合,里面是所有的MB项目
总结
还是打个比方。首先,我们把MB看做一个功能超级强大的路由器,它支持多种接入方式,也就是MB路由器上的端口有很多种,MQ是比较常用的一种方式,所以MQ就像常用的RJ45接口的5类双绞线。但同时MB还支持JMS、SCADA等各类接入标准。在MB内部,我们管理员定义好路由规则(编写消息流)。其次,从MQ过来的信号,可以转换成其他网络协议的信号(消息格式转换),这类似于网桥功能,可以跨越不同网络。同时,MB的性能非常好,可以进行大数据量交换,这一点又很像是交换机。最后,MB可以理解业务逻辑,它的路由不仅像路由器那样针对消息头进行路由,还可以根据消息的业务内容进行路由,酷似应用网关。
 
 
IBM Message Broker笔记系列(三)
安装配置
准备工作
 
MB的运行依赖于MQ,所以首先要安装MQ,MQ的具体安装过程略,并且以后假设你已经有关于MQ的基础知识,比如队列管理器、队列、通道,等等。
 
安装好MQ后,创建一个队列管理器(简称QM),名为TESTQM(MQ里面的对象是区分大小写的,为了避免不必要的麻烦,这里统一用大写,以下划线分隔),这个队列管理器是MB运行的基础,当你用MB的脚本创建配置管理器、代理和执行组时,都要指定QM的名字
 
然后创建运行时数据库,名为TESTDB,MB自带了derby,你也可以选择DB2,注意此处的数据库是指MB自身运行所需的数据库,目前6.1版本只能用derby或者DB2。创建的方法,可以用MB的脚本命令:mqsicreatedb,也可以用对应数据库自身的脚本命令或图形界面来创建。
 
关于MB的数据库:
配置管理器只能用derby,而代理可以用多种数据库,只是不同数据库的创建命令各自不同(包括在不同平台上也有差异,具体参考红皮书);代理的数据库可以共用,配置管理器也可以和某个代理共用一个derby数据库;使用mqsicreatedb创建数据库时,如果你已经安装了DB2,则默认创建一个DB2数据库,否则derby
 
以上是为MB的运行创造运行时环境,接下来开始创建MB的实例
 
首先当然是要安装MB了,过程挺简单的,略去不表。安装完成后,会在“开始菜单”中有个“命令控制台”,如下图:

单击它,进入MB的一个命令控制台环境,其实和普通的windows命令控制台没什么区别,主要在于它帮你设好了相关的环境变量,你就可以在里面直接输入MB的命令脚本了
 
前文提到过,MB的配置管理器是用来统一管理MB的各个运行时组件的,因此首先要创建一个配置管理器
mqsicreateconfigmgr –i user –a password –q TESTQM
指定用户名、密码和队列管理器,用户名密码是你登陆本地机器时输入的,必须要有足够的权限(具体权限就不清楚了,我直接用管理员帐号,深入讨论请参考MB的红皮书)
你会发现这里没有指定数据库的名称,因为配置管理器在创建时会自动新建一个derby数据库,而且只能用derby数据库,用户无法改动
配置管理器的名称也没有指定,在windows下是会创建默认名称的:ConfigMgr
 
然后是创建代理,名为TESTBROKER
mqsicreatebroker TESTBROKER –i user –a password –q TESTQM –n TESTDB
大部分都和创建配置管理器一样,只是多了一个选项,用于指定数据库,再次提醒,必须是derby或DB2,二选一。
 
最后,使用“mqsistart组件名” 来启动配置管理器和代理
配置MB toolkit
WMBT本身的安装没什么特殊要求,这里就不啰嗦了
 
接下来的关键是在WMBT里面连接到刚才创建的配置管理器,其作用就好像你在Eclipse中要配置好应用服务器的实例,才能把你的J2EE项目直接以图形界面的方式部署,而不必自己敲命令
 
如图,文件->新建->域连接
 

IBM MessageBroker笔记系列_第4张图片

在弹出的窗口中,填入相关参数
这里只需填入队列管理器的名称、域名、端口,注意是队列管理器而不是配置管理器(其实你在创建配置管理器时也没有指定端口,因为它用的就是所在的队列管理器的端口)
此外对于SVRCONN通道名,SYSTEM.BKR.CONFIG是在你创建配置管理器时自动生成的,可以在“MQ 资源管理器”中,通过“显示系统对象”来查看,你也可以自己建一个服务器连接通道,然后在这里输入该通道的名字

IBM MessageBroker笔记系列_第5张图片

 
一切正常的话,就能看到左下角的“域”窗口中,多了一个新的域连接,里面以树形结构显示了你刚才创建的代理(前提是你的代理基于derby数据库,如果基于DB2,则需要在域连接那里显式增加“代理引用”),现在你可以右键单击 TESTBROKER ,然后创建执行组。等你开发好 MB 项目后,打个包,拖到执行组里面,就可以部署了。
 
IBM MessageBroker笔记系列(四)
 
前面讲了那么多MB的原理和配置,这一篇blog开始正式讲讲我个人学MB的感受。“假如时间可以重来”,我会怎样利用手头的资源,以最快的速度入手。
体验MB
在安装完WMBT之后,会出现“欢迎”(这个也是eclipse环境安装后都会有的东西,你也可以在“帮助”->“欢迎”里面找到),里面有不少很浅显的例子,让你对MB是如何工作的有个感性认识。强烈建议把里面的“入门”部分看完。
学习开发
看完“入门”后,重点就应该放在“样例”中。在样例库里面,有数十个基础的样例,每个样例都针对某类节点,比如消息映射、JMS、数据库操作、Webservice调用,等等。那么多的例子,当然不可能一下子看完,而且对于一张白纸的新手,里面有些基础知识还不懂,我的建议是:结合之前提到的那本书《精通Websphere Message Broker》,看完一方面的内容,比如数据库操作,你就可以打开“样例库”,将里面的数据库样例导入至WMBT,然后看看其中的ESQL代码、相关节点的设置,等等。一开始会比较枯燥,而且让这些样例跑起来也不是件容易的事情,但坚持下去就会慢慢体会到其中的乐趣了。
掌握Debug利器
一般来说,WMBT会自动帮你配置好样例程序运行所需的环境(比如创建队列管理器、数据库,等等),然后将样例部署到MB的执行组中。这一切都是自动完成的,但有时候出于各种原因,试运行样例的时候不能得到预期的结果。首先排除掉打包和部署时的错误,因为样例程序的源代码通常是没有问题的,那么余下的问题就只能靠debug来解决了。另一方面,当你看了书之后,对InputRoot、Environment、ExceptionList这些东西的结构、细节肯定会很好奇,但是书中提到的很少很零散,最好的方法就是在debug模式下,让消息流挂起在某一点,然后你再慢慢浏览其中的各类变量,很多东西都不言自明了。用IBM工程师的话说,就是“没有debug就根本没法学会MB”。为什么?相关资料太少了,去google有时候还不如直接问MB自己,所以也是很考验你的自学能力的。
配置debug环境
这些内容在《精通》那本书中都有讲到,只是比较粗略,我在这里补充我个人的经验。
首先右键单击某个执行组,“属性”,在“JVM调试端口”中输入一个tcp端口号,不要和其他程序冲突就行,假设9090。再次右键执行组,“调试”->“启用调试9090”。然后,切记,重启执行组所在的broker
重启后,把bar文件部署到该执行组,然后进入“debug”视图,找到下图右下角的那个按钮:

如果是该按钮是红色的,说明debug守护程序没有启动;如果是绿色的,鼠标移过去,会显示“debug守护程序正在监听XX端口”,需要注意的是,这里的端口可不是之前在执行组设置的端口,刚好相反,必须和之前的9090不同。单击旁边的下拉箭头,可以启动或者更改守护程序的端口,这里改为9099,不必重启。
 
接下来,就和一般的eclipse调试一样了,在绿色的小昆虫按钮设置debug参数。新建一个debug,注意这里的“java调试端口”则必须与执行组的一致,你也可以“选择执行组….”,系统会根据你选择的执行组,自动设置端口
 

IBM MessageBroker笔记系列_第6张图片

然后,在“源”选项卡中,添加你要调试的项目。确定之后,就可以运行debug了。
What next?
debug配置成功后,就开始慢慢研究那些样例吧,按照之前我说的思路,“书本+样例”,按照每个人自己的学习习惯和项目开发的需要,将你要学习的样例,一步步调试过去,看看每条ESQL语句的结果,很快的你就知道其中的运行机理了。
小结
由于MB不能像java那样,输出东西到控制台,只能输出到日志文件,而且还得写一堆语句,或者配置trace节点,很麻烦,所以传统的在程序中插入输出语句的方式在这里没太大意义。很多情况下,要依靠debug来观察消息流执行过程中消息的变化,来决定bug的所在。
 
IBM MessageBroker笔记系列(五)
学习资源
专门整理一下最近用到的一些学习资源,并稍作评论
一、           《精通Websphere Message Broker
其实对这本书,我是爱恨交加。一方面,它是仅有的一本中文的纸质图书,也是我翻得最多的一本参考书;另一方面,它也就是参考书,作为入门的图书太难了,编排也不怎么样。但是总的来说,开发MB还是少不了它呀,当你要查某个节点的用法、某个ESQL函数的参数,大部分人还是倾向于翻书而不是翻一堆英文资料吧
 
二、           Websphere Message Broker InfoCenter
这个东西的使用频率是仅次于上面那本书的,比起书来说,有哪些好处呢?首先是内容量大而且全,几乎你要找的所有信息都能在里面找到。此外,电子资源的一大好处是可以搜索、可以用金山词霸,对于一些书上没有的或者你根本不知道躲在哪个角落的信息,用这个最方便了。
但是不足之处也显而易见,首先是全英文,看起来比较费力;另外是对着屏幕上一页页的英文看半天,个人感觉对眼睛很不好,很费精力。
 
三、           IBM技术支持
IBM的服务分为收费与免费两种,当你购买了相关产品后,就能获得相关的技术支持,一般是指派一两个售后工程师,你可以随时联系他们,包括手机和电邮。当你在开发中遇到问题时,大可不必客气地狂问他们问题。能不能给你个满意的答复就看情况了,因为有些问题不面对面交流是无法描述清楚的,而要他们过来你这边通常需要预约(IBM的工程师都很忙,貌似事情特别多,三天两头开会、培训学习什么的)。
而且,作为专业服务队伍的一大特点,就是只负责他熟悉的产品,假如你的问题是“MB和spring里面某个东西通过MQ互联失败”,那他们首先会尝试解决MB这边的问题,如果不行,那就不好意思了,“spring不是IBM的,同时也不是我熟悉的,你去找spring的厂商吧,或者还可以给你一个MQ工程师的联系方式”。其实很多这些问题都是要联调的各方一起解决的,只是,如果你真要这么做,先掏服务费吧,因为这种问题涉及到具体项目开发,IBM可不是慈善机构。
还有一种情况,就是IBM的工程师也不曾遇过的问题,比如某些产品的新特性连他们都没有被培训过,那就比较痛苦了,所以要找其他方法,总不能干等到他们学习完了再来指导你吧。
 
四、           MQSeries论坛
          http://www.mqseries.net/
这个论坛特别好!囊括了IBM MQSeries的所有产品,里面有专门的WMB区,很多高手在里面回答问题,我甚至觉得,真想深入研究MB,平时可以多去那里逛逛。上次关于webservice的一个问题,IBM的技术支持都不清楚(因为是6.1版本的新特性),最后还是这里的高手解答的。
这是国外的一个论坛,发帖看帖之余,还能练习英文,何乐而不为呢
 
五、           IBM 网上资源
这个的范围比较广了,从红皮书到developerWorks社区,里面有很多你想要的东西,只是dw社区的文章中英文混杂,找起来比较费力,个人还是把这里当成学习的地方而不是紧急时候的参考资料。闲暇之余在这里浏览那些IBM专家发的文章,不仅图文并茂、版面工整,文章质量高,水平也由浅及深,各种层面的都有,实在做得很不错,建议我们这些菜鸟或者技术狂去订阅dw的邮件吧,经常会发送“新手入门”之类的电子杂志。
 
小结
暂时用到想到的就这些了,MB的确不好学,不然IBM也不会把培训和服务费收这么贵了,可见IBM真是很狡猾,把软件做得难用又不肯出一些系统的基础教材,摆明是要宰你一笔,呵呵。如果你也对MB有研究,欢迎一起探讨,交流更多好用的资源(可以省钱)。
 
IBM MessageBroker笔记系列(六)
 
前面几篇笔记,都是讨论 MB 是什么、怎么配置、怎么 debug ,以及一些学习资源和心得,接下来的几篇会针对 MB 开发中一些常见的问题,分门别类进行归纳总结,包括数据库、 WebService ESQL 语法细节,等等。这些细节问题都是我本人在这两个月的开发过程中遇到的,相信对很多新人都有借鉴作用。

 

数据库操作

配置MB的用户数据库

 

前面已经讲了在创建MB运行时实例时,配置数据库的基本过程了,但那里所指的数据库是MB自己运行时需要的数据库,用来存放诸如broker、执行组、消息流等的信息,而现在开发的企业应用程序,几乎没有不用到数据库来存放业务数据的,所以这里主要讲述如何配置“用户数据库”,也即你的应用程序使用的数据库。

 

下面以MB 6.1 + Oracle 10g 为例,介绍配置过程

一、           ODBC数据源

MB是通过ODBC来操作数据库的,因此首先要配置好操作系统本身的ODBC数据源。Windows中配置ODBC很容易,在此不赘述细节。需要注意的是,选择Oracle数据源驱动时,一定要选择下图所示的MB自带的Oracle驱动

IBM MessageBroker笔记系列_第7张图片

 

我在创建ODBC时,一开始没有在本机安装Oracle,结果ODBC无法使用,报告“由于系统错误126,驱动程序无法加载”,问了IBM的技术支持也没有答案,后来干脆在本机安装了一个Oracle(不必运行),问题就解决了,估计MB自带的Oracle驱动还是要调用Oracle本身的一些库的。我对Oracle本身基本不懂,具体用到了哪些库也不清楚,就先这么用着了。

 

二、           数据库设置

这里顺手提一下Oracle本身的设置。当你新建了OracleODBC数据源后,会发现数据源设置里面,没有IP和端口设置。我在网上搜了一下,最简单的方法是直接修改Oracletnsnames.ora文件,这个文件位于: $oracle_root/product/ 10.1.0 /db_1/NETWORK/ADMIN/tnsnames.ora 路径下,可以用记事本打开编辑。里面本身已经有样例了,参照着改很容易

 

三、           消息流节点

MB中能和数据库打交道的节点有很多,包括filtercompute,和专门的数据库节点,如下图:

IBM MessageBroker笔记系列_第8张图片

基本上,凡是属性里面可以设置“数据源”的节点,都可以操作数据库。使用方法很简单,直接在“数据源”属性中填入操作系统的相应ODBC数据源名称即可。

 

四、           代理broker的设置

这是最后一处要设置的地方。前面的tns文件解决了ip和端口的问题,但是数据源本身的用户名和密码在消息流中并没有提及,其实这是通过MB的一个命令来设置的,格式如下:

mqsisetdbparms brokerName -n dataSourceName [-u dataSourceUserId] -p dataSourcePassword

具体用法可以输入 mqsisetdbparms /h 获得参考

 

配置完以上内容后,运行消息流应该不会有数据库连接的异常了。假如配置不正确,会在运行到使用了“数据源”的节点处抛出ODBC的一些异常

 

在WMBT中创建数据库项目

 

以上做的工作可以确保消息流能够正确操作用户数据库,但是当你在WMBT中编写SQL语句时,会出现很多警告,内容一般是“无法解析数据库表引用:某字段”。虽然不影响运行,但看着总是不太爽。

出现警告的原因很简单,你没有告诉WMBT你需要用到的数据库表的结构是什么,所以WMBT很尽职地告诉你可能有问题,我们只需引入数据库的定义,即可消除这些警告。

首先,打开“数据库资源管理器”视图,新建一个JDBC连接,和其他EclipseIDE类似,配置好相关参数即可。

IBM MessageBroker笔记系列_第9张图片

WMBT中新建一个“数据库定义”,向导会让你顺便创建一个“数据库设计项目”,你可以通过刚刚创建的JDBC连接,选择一个数据库,即可。

这时你会发现ESQL代码中那些烦人的提示已经消失了。

 

在ESQL中编写SQL语句

 

ESQL中使用SQL和一般的SQL语句基本一致,除了在指定哪个数据表的时候,要用类似下面的语法:

SELECT  FROM Database.SchemaName.TableName

其中的“Database”是关键字,一定要有的,表示从数据库中读取,这是因为ESQL中不单可以操作数据库,还可以对逻辑树、数组对象使用selectdeleteSQL语法,“Database”起到标识的作用。

 

给出这样一条语句:

set LocalEnvironment.temp[] = select * from Database.TEST.example

假设exampleidinfo两个字段,共三条记录,那么执行后的结果是LocalEnvironment 树下面产生三个temp元素,每个元素都包含一个idinfo子元素,对应数据库的记录。

select返回的都是数组类型,因此不能set LocalEnvironment.temp = select ….,那样会在打包时报错,一定要标明是数组

 

此外,像上面那样直接书写SQL语句并赋值给一个数组变量,MB会在编译和执行期间检查SQL语法是否合格,这个特性虽然很有用,但有时候也会适得其反,比如要在Oracle使用序列来实现主键自增时,insert语句要写成:

insert into example (id,info) VALUES ( SEQ_EXAMPLE.nextval , ‘xxxxx’)

这里 SEQ_EXAMPLE 是序列的名称。而在 MB 里面这样会保存,提示找不到 SEQ_EXAMPLE 这个对象的定义。解决方法是使用 ESQL PASSTHRU 函数,这个函数直接将 SQL 语句发送给数据库去解析执行,就可以绕开 MB 的检查。
 
IBM MessageBroker笔记系列(七)
 

这篇是针对WebService的一些使用技巧

入门

MBWebService的支持其实不是它的强项,它的长处在于MQMB就是基于MQ的,所谓“消息代理”,感觉就是在消息中间件基础上增加了“代理”功能。MB的前身是MQ Integrator,所以从字面意思上来看,也是“message -> integrator -> broker”,越来越复杂的功能。据说,Websphere ESB对于javawebservice的支持更加完善,不过我也没有用过。

 

扯了那么多,回到主题。在MB V6.0中,对WebService的支持还是比较弱的,以单纯的http节点,加上程序员在compute节点中手工操作消息树,包括对SOAP包进行封包(envelop)和解包(extract)都要自力更生,难度比较大,且不够直观简练,给人感觉是MBwebservice支持不够,不得已而为之。到了V6.1,情况终于有了较大的改观,MB提供专门的webservice节点了。

 

所以,如果你还在看《精通WMB》,那么webservice那一章可以先放下了,去WMBT的“样本库”,看看webservice的教程,会发现不仅仅有专门的SOAP节点,还对IBMWSRR也有专门的支持,甚至还提供异步的SOAP节点。因此在MB中使用webservice,第一步推荐先去学这些样例。特别留意使用httpsoap节点时,前后的compute节点的ESQL代码的差异,体会SOAP节点的方便。

IBM MessageBroker笔记系列_第10张图片

 

技巧

 

看完SOAP节点的样例之后,会发现里面的那个子流,其实也挺复杂的,好像不比http节点简单

 

http节点

 

IBM MessageBroker笔记系列_第11张图片

SOAP节点

IBM MessageBroker笔记系列_第12张图片

其实,EnvelopeExtract节点是MB6.1才有的,没有他们,http节点构造webservcie会变得很啰嗦;另外,以上的流程图,是可以通过向导的方式生成的,这一点非常方便。

 

首先在消息集项目中,“从WSDL文件”新建一个消息定义;然后将这个WSDL文件拖到某个消息流的编辑界面中,自动弹出一个向导,简单地一步步走,就能生成以上的消息流。

 

IBM MessageBroker笔记系列_第13张图片

 

IBM MessageBroker笔记系列_第14张图片

 

动态设置webservice地址

 

在以上生成的消息流中,HTTP节点和SOAP节点都有一个属性,用于指定webservice的请求地址,但这是写死在节点中的。如果要在运行过程中动态设置呢?比如根据消息内容,选择合适的URL地址进行webservice调用。

 

其实很简单,只需在SOAPHTTP节点之前的某个compute节点中,在LocalEnvironment中设置一个相应的值即可

  • HTTP 节点:

SET OutputLocalEnvironment.Destination.HTTP.RequestURL = ‘webservice地址

  • SOAP 节点:

set OutputLocalEnvironment.Destination.SOAP.Request.Transport.HTTP.WebServiceURL = ‘webservice地址

 

注意,切记把compute节点的“计算方式”设置为“消息和LocalEnvironment”,总之至少要包括LocalEnvironment,否则设置了等于没设置,compute节点不会将LocalEnvironment往下传

 

当然,以上步骤也可以在 Filter Database 这些节点做,那样就没有 Input Output LocalEnvironment 之分了
 
IBM MessageBroker笔记系列(八)
 

 

本来这一篇要写ESQL的一些语法细节的,但是过几天就要去客户那里部署系统了,上周也花了一个礼拜时间,一边学linux,一边学怎么在linux上部署MB。所以这一篇先讨论如何在linux上安装、配置WMB

 

准备

先说一下硬件和操作系统环境:

机器:IBM的某型号刀片机, 4G 内存

操作系统:RED HAT LINUX 64bit企业版

业务数据库:Oracle 10g

 

WMB6.1,安装在WMQ6之上,使用DB2 9作为代理数据库

以上软件都是安装在同一台刀片机上

 

另外,WMBT6.1安装在我自己的windows机器上,用于开发MB程序,并远程部署到服务器上

 

参考资料

按理说参考资料应该是放在最后面的,只是我的这些安装心得都是来自这些参考资料,为防止我的个人经验误导读者的安装过程,所以先列出以下资料。有空慢慢看的话,还是应该以这些官方资料为准

 

messagebroker_Configuration_Administration_and_Security

这本是权威了,除了对应的版本有些旧(WMB 6.0),整体内容还是很详细的,几乎所有平台上的MB安装、配置都有详细的介绍。只是内容多得让人看起来眼晕。

 

MB info center

内容和上面那本书差不多,比较精炼,但如果配置出了问题,未必能找到详细的解答

 

最后,强烈建议,如果是linux菜鸟(像我这种),赶紧补习一些linux的基本知识,比如环境变量怎么设置

 

安装

其实安装过程还是比较简单的,先安装MQ,再安装MBMQ比较麻烦一点,要用rpm,而MB则带有一个Eclipse的安装界面,和windows上和相似,跟着向导走就行了。安装好之后,会发现db2也随着MB一起装好了

默认安装路径(注意大小写):

MB/opt/ibm/mqsi

DB2/opt/ibm/db2

 

创建代理数据库

红皮书上已经有详细说明,我就偷个懒,copy并解释一下

 

1. Log  on  as  root.

2. Create  a  database  instance.  Use  the  commands  shown  here  for  guidance  for  the different  platforms.

a. On  AIX:

/usr/lpp/db2_08_01/instance/db2icrt  -u  fence_userID  username

b.      On  Linux,  Solaris,  or  HP-UX:

/opt/IBM/db2/V8.1/instance/db2icrt  -u  fence_userID  username

 

其实,fence_userID username我也不太清楚是什么,你可以参考红皮书,或者找个db2高手问问。反正我当时使用root创建是不行的,一定要选择其他帐号,比如你自己的用户名

 

3. Log  on  as  username

4. Create  a  database  (in  this  example  called  WBRKBKDB)  using  the  following commands  (on  some  platforms,  an  explicit  path  name  is  required). You  must  insert  a  space  between  the  starting  period  and  the  tilde  character  in  the  first  command  shown  here:

.  ~/sqllib/db2profile

db2start

db2  create  database  WBRKBKDB

db2  connect  to  WBRKBKDB

db2  bind  ~/sqllib/bnd/@db2cli.lst  grant  public  CLIPKG  5

 

重点说明的是:.  ~/sqllib/db2profile 这句命令,前面要有一个“.”和空格,否则没用。执行了这条命令后,如果你对db2命令不熟悉,可以直接敲入“db2cc”,启动db2的图形管理界面,在里面创建数据库,省去了敲命令的麻烦

 

最后一步,在某些平台上需要修改db2DBHEAP属性,至少900,才能满足MB运行的需要,否则会造成性能低下。

配置ODBC连接

由于在64位机器上跑MB,所以ODBC DSN是要32位还是64位是很头疼的问题,因为不同硬件平台、操作系统的组合都有不同的要求。比如,在windows上是肯定没有64bit支持的,而在某些操作系统(貌似是AIX),即使你全部用64bit的产品,也要配置32bitODBC。具体的可以参考红皮书,里面有详细的列表,在这里我只针对我使用的平台介绍配置过程,在此特别声明,未必适用于读者的环境

 

总体思路:linuxODBC是通过一个配置文件来描述的,在该配置文件中写入相应的信息,然后在环境变量中设置 ODBCINI=“配置文件的绝对路径”

 

编辑ODBC配置文件

1.      从你的MB安装目录下的ODBC64/V5.2 ,拷贝一份样例配置文件:odbc64.ini,到某个目录(比如mqm用户的根目录)

2.      修改该文件。在这里我只保留DB2ORACLEDSN,其他的统统删了

3.      修改你的odbc64.ini的权限:

Ensure that  the  odbc64.ini  file  has  file  ownership  of  mqm:mqbrkrs  and  has  the  same  permissions  as  the  supplied  sample  file.

4.      修改ODBCINI环境变量指向你的odbc64.ini

5.      修改linux的库路径:LD_LIBRARY_PATH,指向db2oracle32位和64odbc链接库的路径,比如我的配置如下:

LD_LIBRARY_PATH=$ORACLE_BASE/lib32:$DB2_BASE/lib32:$DB2_BASE/lib64:${LD_LIBRARY_PATH}

6.      如前所述,我对使用32还是64bitDSN也是有点混乱,干脆就把下面两个环境变量也加上,以防万一:

# for MB 64bit execution group

MQSI_LIBPATH64=/opt/ibm/db2/V9.1/lib64:${MQSI_LILPATH64}

 

# 32bit database lib may be needed

MQSI_LILPATH32=/opt/ibm/db2/V9.1/lib32:${MQSI_LILPATH32}

7.      最后是修改odbc64.ini文件的内容,具体的看书吧,下面是我的例子:

   

补充几点注意的地方:

1.      DB2driver是不用路径的,只写驱动名字即可

2.      DB2Database属性(即是数据库的名字),要和DSN的名字一样(即是方括号中的内容)

3.      没事不要打开trace,会很慢

 

创建MB的运行实例

准备工作

打开一个终端,运行命令之前,先输入:

. /opt/ibm/mqsi/6.1/bin/mqsiprofile

和前面的db2命令一样,开头要有“.”和“空格”

你可以把这句话加到linux用户根目录的“.bashrc”文件,那样每次打开终端都会自动执行这个脚本,以设置一些环境变量,否则你是无法使用MB命令的。

 

确保MQDB2都在运行

可以通过dspmq查看MQ组件的运行状态,如果队列管理器没有启动,则通过strmqm命令启动之。

按照前面介绍的方法,利用db2cc图形界面查看数据库是否运行,否则启动之;也可以用db2start命令,记得要切换用户到你创建db2时使用的帐号,比如:

su db2usr –c “db2start”

 

创建配置管理器

mqsicreateconfigmgr ConfigMgr -i root -a xxxxx -q QM

 

创建代理

mqsicreatebroker BRK1 -i root -a xxxxx -q QM -n BRK1_DB -u db2usr -p xxxxx

 

创建代理时,要指定代理数据库的DSN名称,同时指定连接ODBC的数据库用户名密码

如果一切ok,创建好代理后,在db2数据库中会看到多了很多表,那基本上就没问题了

如果出问题,通常都是数据库连接,对照红皮书检查你的ODBC配置(这个过程很痛苦),以及访问数据库的用户名、是否拥有足够权限。实在不行,找IBM的支持吧…..

 

以上是连接代理数据库,如果要连接用户的oracle数据库,请参考我之前写的第六篇笔记,利用这条命令:

mqsisetdbparms brokerName -n dataSourceName [-u dataSourceUserId] -p dataSourcePassword

 

最后用mqsistart启动一下,一切ok的话,就算完成万里长征第一步了。

 

WMBT远程开发、调试

单纯安装好MB还是不够的,你还要用WMBT开发、部署和调试消息流,有谁喜欢坐在风扇轰鸣、充满辐射的机房里coding呢?所以接下来讲述如何配置WMBWMBT,使得开发者可以远程连接MB并进行调试

在此之前,可以参考这篇文章,实现远程管理你的MQ

http://blog.csdn.net/Justin4wd/archive/ 2008/07/16 /2661131.aspx

 

首先在MQ中建立监听器和服务器连接通道,具体请参考我的第三篇笔记

http://blog.csdn.net/wangchengsi/archive/2008/07/08/2625598.aspx

 

如果MBWMBT是在同一台机器,这样做已经足够了,但如果是远程连接,直接连接会报告以下错误,则还需要在MB那里配置ACL(访问权限列表)

IBM MessageBroker笔记系列_第15张图片

从上图可以获得你的机器名和用户名

 

linux打开一个终端,输入以下命令

mqsicreateaclentry 配置管理器 -u 用户名 -m 机器名 -x F –p

-x F表示访问程度,F表示完全访问

-p表示访问Proxy,即ConfigManagerProxy,相当于可以访问所有资源,比如代理

 

再次从toolkit连接MB,就可以了

 

之后,开发、部署、调试的过程都和本地的机器一样,读者可以看我之前写的关于调试功能的配置

 

注意,6.0以前的MB需要安装RACRational Agent Controller)才能远程调试,6.1开始已经不用了

 

 

 

IBM MessageBroker笔记系列(九)

 

这篇是纯粹的“coding心得”,撇开MB那些啰嗦的配置不谈,专门讲学习ESQL的痛苦经历,有些内容可能前面的笔记有介绍过,这里做一个全面的汇总。虽然有些编程的tips已经忘记了,以后如果想起来还会继续补充。

概述

ESQL的语法和数据库的存储过程语句很像,虽然我从未写过存储过程,但是平心而论,ESQL的基本语法和概念还是很好理解的,毕竟,ESQL没有类、对象、多态这些OOP的东西,也没有指针、位移操作这些C的概念;没有C的函数指针、指针的指针、内存分配这种让新手头晕的术语,也不像Java那样各类框架满天飞,开足马力都学不过来。所以,ESQL还是很好入门的。但是,切记,只是“入门”而已。你看懂那些示例的ESQL很容易,无非是逻辑树的增删改;消息流也是那么一目了然,消息从一个节点出来,进入另一个节点,不知不觉一个“业务流”就完成了,so simple,naïve!我一开始也是这么觉得的,但真正动手的时候,才发觉ESQL代码中,危机四伏!下面一一列举

基本类型

数字

ESQL的基本类型很少,无非是数字、字符串、逻辑、时间,还有引用。数字类型包括int、float和decimal(就是double,高精度小数),一般很少会考虑三者的差别,把它们与java的等同起来,其实不然,如果随便乱用,会冒出很多无聊而又浪费时间的bug

  • 数据库查询

在使用oracle的时候,通常都会用Number类型作为主键id等数字类型字段,可是你知道用select语句取Number到ESQL中是什么吗?是decimal。由于ESQL里面,消息树中的字段类型是隐式的、可变的(类似PHP),也就是你可以随便赋任何值给某个消息节点。按理说这种脚本语言的特性可以方便编程,是好事。不过请先看完下面的描述。

  • 数据库插入

这个问题是最近才发现的,在64位的linux上,MB使用64位数据源访问oracle,在一条insert语句上屡屡失败,而这条insert语句之前在32位windows平台上却很正常的执行。抛出的异常提示:“oracle:String data, right truncated”,在网上搜了一下大部分人都说是数据太长,只有dw论坛上有人说可能是64bit数据源的关系,但具体原因也不清楚。请了IBM的支持来搞了半天也没任何结果,绝望之际我干脆用排除法,每次修改一两个字段为很简单的常数(那样总不会出问题了),在排除到最后一个字段时,才发现把一个decimal的数据插进去会有问题,如果换成float就ok了!这个问题前后浪费了我两天,当时忍不住说了几句脏话,一个简单的问题搞得这么恶心,错误提示也纯粹误导用户。天知道以后换成其他平台会不会又这样呢?

  • 函数调用

ESQL是弱类型的?是的,某种程度上是弱类型的,可是遇到函数调用的时候,它的类型强度简直胜过java——你不能把一个int作为参数传递给声明为double的参数,那样会抛出异常。问题是有时候你根本不知道某个消息树节点啥时变成了int或者是float或是double,就像上文说到的数据库查询结果。请打开debug,慢慢找吧,总会有柳暗花明的一刻

字符串类型

估计MB为了照顾比较“原始”的消息格式,即非XML、而是CWF或者TDS格式的消息,ESQL的字符串类型不仅仅有字符类型“char”,还有字节类型“BLOB”和比特类型“BIT”,的确是大大方便了比特流的处理。关于字符串,发现的问题不多,下面列出几点需要稍加注意之处。

  • 字符串连接“||”

使用“||”连接字符串时,记得每个被连接的变量都不能为null,否则连接后的结果就变成null了,可以用“变量 is not null”来判断

  • BLOB类型

BLOB类型在ESQL中的表示方式为 X'ABCD',实际上是一种BCD码,每个字符表示一个十六进制,即半个字节。注意这里要是偶数个长度,否则在打包或者部署时会报错

时间类型

和一般编程语言不同的是ESQL有时间类型的变量,这很大程度上是因为MB里面支持很多XML的特性,而时间类型也是标准XML中包含的,例如xsd:dateTime等等。我没学过高级的XML,自然对这些名目繁多的时间类型之间的差别不甚了解,所以简单地列出几点比较常用的特性:

  • 消息定义中的时间类型

消息定义文件里头也可以声明某个节点类型为timestamp(消息定义文件本质上就是XML SCHEMA文件,自然支持xsd:命名空间),不过在实践中发现从MQ读入的一个XML字符串,解析为timestamp类型时,经常有一些格式上的问题而导致解析失败,后来干脆把timestamp全部替换为string了,IBM的技术支持也是这么“推荐”的,估计是他们也找不出原因所在

  • 计算花费的时间

JAVA里面很常用的就是通过计算系统时间之差,来得到一段代码的运行时间毫秒数,然后用时间类可以进行格式转换,ESQL同样可以做到,而且更加简单。比如要计算一个消息流的运行时间,那么在消息流开头用 CURRENT_TIME得到起始时间,保存在环境树中的T1节点;然后在消息流结尾,再次用 CURRENT_TIME得到结束时间T2,两个时间值相减,再用下面这段代码将其转换成毫秒数

SET OutputRoot.MRM.process_time = CAST( (T2-Environment.Variables.T1) SECOND AS FLOAT) *1000;

很遗憾的,ESQL最小只支持“秒”的时间间隔(“时间间隔”INTERVAL也是一种时间类型),不过得到的float值通常是小数位很长的,包含了毫秒信息,譬如0.2352436,因此乘以1000也完全够用

全局变量

问过IBM的人好几次,自己也去查了不少资料,一直没有发现ESQL中有足够理想的全局变量或者全局常量。我们知道,ESQL的代码层次从高到低依次是:schema->module->function or procedure,越是局部的变量,优先级越高,这一点和普通编程语言一样。所以,没有变量的声明可以超越schema这一级,包括所谓的外部变量external,因此,在不同schema的消息流之间不能共享全局变量的,这个限制有时候很麻烦,比如所有消息流都要访问同一个数据源、或者Oracle的schema,或者是你自己定义的全局常量,那你就只能在每个schema中设置了,还好schema不会很多,或者你在消息流开始的时候,从文件、数据库等地方读取配置参数也是一种选择。

对于定义好的全局变量,可以用{ }进行变量值的替换,从而实现动态功能,比如 OutputBody.{myvar}.value,花括号的值会在运行期间指定。但是这样一来ESQL的编辑器就无法判断这个节点是否存在,会给出“无法解析该引用”的警告,这不影响使用。

全局函数

刚才说到的在schema作用域中定义的全局变量,在其他schema不能引用。但是在schema中定义的全局函数或者过程,则可以在其他schema中引用,只要在定义schema时使用PATH将其他schema导入即可,或者在调用函数时指定完整路径,如 CALL com.xxx.GLOBAL_FUNCTION。很多人一开始会对全局函数寄予厚望,因为可以减少代码的重复,增加复用度,实则符合圣人们的教诲。只可惜呢,全局函数中不能使用通常在节点中的Root、ExceptionList、Environment等逻辑树,所以我在定义全局函数时,第一个参数通常都是REFERENCE类型,用来把Environment等逻辑树传进去。

数组、ROW和LIST

ESQL里面有数组类型,但你不能DECLARE一个数组变量;有ROW类型,同时有个ROW函数专门用来产生一个ROW变量,还有个LIST函数用来产生数组。

先谈谈数组,数组是什么大家都知道了,在ESQL里面,由于不能声明一个数组,所以我习惯把数组保存在Environment或者LocalEnvironment中。因为消息树的每个节点都可以往下增加子结点,所以每个消息树的中间节点其实都是数组,我们说 set LocalEnvironment.Variables.temp = xxx ,实际上就是 set LocalEnvironment.Variables.temp[1] = xxx

至于ROW类型,《精通WMB》上说是个XML单行数据,执行这条ESQL语句:set LocalEnvironment.root = ROW('aa' AS a, 'bb' AS b),(注意root旁边没有方括号[ ])生成的XML片段如下:

aa

bb

然而,ROW其实是对应与数据库的一行数据,仅此而已。上面的root节点相当于一行,a和b则是该行数据的字段,就这么简单。所以,执行select语句时,返回的就是一个ROW的数组

LIST函数是产生数组用的,例如:set LocalEnvironment.Var.root[ ] =LIST( 'aa', 'bb'),(root旁边这次有方括号[])产生如下XML:


aa
bb


详细内容,请参考老陈的《精通WMB》后面的附录P321(我也是最近才无意中翻到ROW和LIST)

 

 MB与MQ简介

 

    今天听IBM的工程师介绍了MQ和MB的特性,以及他们的区别与联系,觉得很通俗易懂,特此记录,方便将来的初学者可以更快的把握这两者的特点。

 

    首先从概念上来说,MQ是消息中间件,MB是ESB产品

 

    MQ负责在两个系统之间传递消息,这两个系统可以是异构的,处于不同硬件、不同操作系统、用不同语言编写,只需要简单的调用几个MQ的API,就可以互相通讯,你不必考虑底层系统和网络的复杂性。MQ作为IBM的一个拳头产品,虽然功能看上去很简单,就是个消息队列,但他却是IBM中间件的核心,也是相比其他厂商(比如BEA)的一个优势。MQ不仅有很高的性能,而且对各种平台的支持非常好,几乎你能想到的硬件和操作系统平台以及编程语言,MQ都有专门的API支持。但MQ的功能仅限于消息队列,至于应用A发给应用B的消息格式是怎样的、能不能被应用B解析,MQ管不了,他只是尽力将消息发到目的地(MQ能够应付多种异常情况,例如网络阻塞、临时中断等等)。此外,如果应用的数目多了,那互相之间都要建立MQ连接,网络拓扑就成了蜘蛛网了(就好像是最初的电话系统)

 

    因此,我们将网络的星型拓扑引入系统架构中,把一对一的MQ换成一个中心节点,即ESB,MB即是IBM的ESB产品。MB处于系统的中心,起到一个总线的作用,所有应用都直接连接到MB,而不是应用之间直接互联,这样的好处不言而喻,可以极大的降低应用之间的耦合性。由此引出MB的两大核心功能:消息路由和数据转换
因为各个应用都插入到MB上,所以应用A只管把消息丢给MB,MB自动根据消息字段、以及业务逻辑,判断要把消息交给谁,这就像路由器一样,根据数据包的头把包路由到相应地址。MB内部的业务逻辑由开发人员设定,当然利用MB的Toolkit,编写业务逻辑也非常简单:拖一些节点,用箭头把它们连起来,就像是画流程图一样,非常形象简单。再用MB的脚本语言(类似sql的脚本)实现逻辑判断,通俗地说就是判断要走哪个逻辑分支(if...else.....)。

不过各个应用是怎样与MB连接的呢?MB提供了三种方式:MQ、文件和web service

 

    MQ方式即是利用MQ将MB与应用互联;文件方式则是指定某个目录,MB会自动监视那个文件目录,一旦文件有改变则认为是新的消息到来,MB自动读取指定文件的内容;而web service就不用解释了,直接利用web service进行通讯。MB支持这些互联方式也是为了最大化兼容性,特别是对于那些遗留系统或是不支持主流通讯方式的系统

最后说说一个比较偏门的ESB产品:websphere ESB。听过的人可能不多,因为IBM在中国推广的比较少,这个WESB很像是MB的精简版,只支持JMS、WS等少数几种J2EE的通讯方式,所以是为J2EE专门准备的。不像MB,支持数十种平台和通讯方式,例如FTP,甚至很多你根本没听说过的很古老的通信协议。这两者的性能相差不少,价格也有三四倍的差距。更要命的是,原先在WESB上开发的东西,是不能迁移到MB使用的,IBM似乎铁了心要狠狠宰我们,唯一的方法是再买一个MB,然后用MQ把WESB和MB连接起来,各跑各的

 

    漏了一个DataPower,这东西我只是略有了解,它的卖点在于硬件支持XML,所以性能比较好,此外还支持一下web service安全方面的东东。因此,WESB是最小功能集,而MB与datapower功能上有一定重叠,如XML 

 

摘自: http://blog.csdn.net/wangchengsi

 

你可能感兴趣的:(SOA,ESB)