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的总体架构，我粗略的描述一下。

可以看到，MB里面有两大块内容，一个是toolkit，也就是开发环境，后面我们会讲到；还有一个是broker domain，即代理域。代理域里面有两个核心部件，一个是配置管理器configuration manager，一个是代理broker。

配置管理器其实很像MQ的队列管理器，或者是WAS的deployment manager，都是起到一个管理作用，在MB里当然是管理众多的broker了。我们平时对broker的管理、维护操作，其实都是通过配置管理器完成的。

代理broker是真正体现MB设计思想的地方，上面的图片中有像流程图一样的东西，即message flow，是消息的流程图（从什么地方流进来，再从什么地方流出去）；还有message set，即消息集，说白了是描述消息长什么样子，它的结构、内容是怎样的。其实，message flow对应了上文所说的“消息路由”，而message set则对应“消息格式转换”，你肯定要清楚两种消息的格式，才能定义互相转换的规则。

MB的外围是各种类型的应用程序，他们接入MB的方式可以多种多样，可以是Webservice，也可以是数据库、文件、HTTP连接，等等，不一定局限于MQ

圆柱体代表的则是数据库了，这是尽IT人皆知的。因为MB的很多信息，包括配置信息、以及broker的运行时信息都要通过数据库保存。broker本身也可以操作数据库，你可以在流程的某个节点上增删查改某个数据库

 

下图是WMBT（websphere mb toolkit）的界面

可以看到，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项目直接以图形界面的方式部署，而不必自己敲命令

 

如图，文件->新建->域连接

 

在弹出的窗口中，填入相关参数

这里只需填入队列管理器的名称、域名、端口，注意是队列管理器而不是配置管理器（其实你在创建配置管理器时也没有指定端口，因为它用的就是所在的队列管理器的端口）

此外对于SVRCONN通道名，SYSTEM.BKR.CONFIG是在你创建配置管理器时自动生成的，可以在“MQ 资源管理器”中，通过“显示系统对象”来查看，你也可以自己建一个服务器连接通道，然后在这里输入该通道的名字

 

一切正常的话，就能看到左下角的“域”窗口中，多了一个新的域连接，里面以树形结构显示了你刚才创建的代理（前提是你的代理基于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调试端口”则必须与执行组的一致，你也可以“选择执行组….”，系统会根据你选择的执行组，自动设置端口

 

然后，在“源”选项卡中，添加你要调试的项目。确定之后，就可以运行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驱动

 

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

 

二、           数据库设置

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

 

三、           消息流节点

MB中能和数据库打交道的节点有很多，包括filter、compute，和专门的数据库节点，如下图：

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

 

四、           代理broker的设置

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

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

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

 

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

 

在WMBT中创建数据库项目

 

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

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

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

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

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

 

在ESQL中编写SQL语句

 

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

SELECT  FROM Database.SchemaName.TableName

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

 

给出这样一条语句：

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

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

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的一些使用技巧

入门

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

 

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

 

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

 

技巧

 

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

 

http节点

 

SOAP节点

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

 

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

 

 

 

动态设置webservice地址

 

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

 

其实很简单，只需在SOAP或HTTP节点之前的某个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，再安装MB。MQ比较麻烦一点，要用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的图形管理界面，在里面创建数据库，省去了敲命令的麻烦

 

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

配置ODBC连接

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

 

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

 

编辑ODBC配置文件

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

2.      修改该文件。在这里我只保留DB2和ORACLE的DSN，其他的统统删了

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，指向db2和oracle的32位和64位odbc链接库的路径，比如我的配置如下：

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

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

# 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.      DB2的driver是不用路径的，只写驱动名字即可

2.      DB2的Database属性（即是数据库的名字），要和DSN的名字一样（即是方括号中的内容）

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

 

创建MB的运行实例

准备工作

打开一个终端，运行命令之前，先输入：

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

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

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

 

确保MQ和DB2都在运行

可以通过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呢？所以接下来讲述如何配置WMB和WMBT，使得开发者可以远程连接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

 

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

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

 

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

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

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

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

 

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

 

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

 

注意，6.0以前的MB需要安装RAC（Rational 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