MB学习资料

今天听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

最后声明，我不是在给IBM打广告

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wangchengsi/archive/2008/02/25/2120316.aspx

【王程斯】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网上查查资料，我之前也写了一篇简介

http://blog.csdn.net/wangchengsi/archive/2008/02/25/2120316.aspx

作为一个菜鸟我没法全面评论当前的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 db2admin–a db2admin –q TESTQM

指定用户名、密码和队列管理器，用户名密码是你登陆本地机器时输入的，必须要有足够的权限

（具体权限就不清楚了，我直接用管理员帐号，深入讨论请参考MB的红皮书）

你会发现这里没有指定数据库的名称，因为配置管理器在创建时会自动新建一个derby数据库，

而且只能用derby数据库，用户无法改动

配置管理器的名称也没有指定，在windows下是会创建默认名称的：ConfigMgr

然后是创建代理，名为TESTBROKER

mqsicreatebroker TESTBROKER –i db2admin–a db2admin–q TESTQM –n TESTDB 大部分都和创建配置管理器一样，只是多了一个选项，用于指定数据库，再次提醒，必须是derby

或DB2，二选一。

最后，使用“mqsistart组件名” 来启动配置管理器和代理

配置MB toolkit

WMBT本身的安装没什么特殊要求，这里就不啰嗦了

接下来的关键是在WMBT里面连接到刚才创建的配置管理器，其作用就好像你在Eclipse中要配置好应用服务器的实例，才能把你的J2EE项目直接以图形界面的方式部署，而不必自己敲命令

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

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

这里只需填入队列管理器的名称、域名、端口，注意是队列管理器而不是配置管理器（其实你在

创建配置管理器时也没有指定端口，因为它用的就是所在的队列管理器的端口）

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

这里输入该通道的名字

一切正常的话，就能看到左下角的“域”窗口中，多了一个新的域连接，里面以树形结构显示了你刚才创建的代理（前提是你的代理基于derby数据库，如果基于DB2，则需要在域连接那里显式增加“代理引用”），现在你可以右键单击TESTBROKER，然后创建执行组。等你开发好MB项目后，打个包，拖到执行组里面，就可以部署了。

【王程斯】IBM Message Broker笔记系列（四）

前面讲了那么多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的所在。