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片段如下：

<root>

<a>aa</a>

<b>bb</b>

</root>

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

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

<Var>

<root>aa</root>
<root>bb</root>

</Var>

详细内容，请参考老陈的《精通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