大型主机报文模拟器插件的设计与开发.docx
《大型主机报文模拟器插件的设计与开发.docx》由会员分享，可在线阅读，更多相关《大型主机报文模拟器插件的设计与开发.docx（10页珍藏版）》请在冰点文库上搜索。
大型主机报文模拟器插件的设计与开发
在开始介绍这个报文模拟工具之前，我们先简单描述一下基于规则的大型主机报文格式转换的架构。
一般来说，这种应用中的报文格式转换要实现两个需求，一是将一个java对象中的内容转化成一条主机报文，二是将一条主机报文中的内容转换到某一个java对象中去。
同时，还要求这种转换规则可以用某种方式进行描述，并外化出来，比如用XML来描述这些规则并保存到文件中。
由此可见，报文格式转换包含两部分关键内容，一个转换引擎，负责转换和反转换，一些存在文件中或是存在数据库中的规则，如下图所收。
图1.基于规则的报文格式转换功能
查看原图（大图）
举个例子，现有一个名为Customer的JavaBean，里面包含了id和name两个属性。
清单1.Customer的定义publicclassCustomer{
privateStringid;
privateStringname;
publicStringgetName（）{
returnname;
}
publicvoidsetName（Stringname）{
this.name=name;
}
publicStringgetId（）{
returnid;
}
publicvoidsetId（Stringid）{
this.id=id;
}
}
为这个JavaBean定义XML格式的转换规则，一方面依赖于这个转换引擎支持的规则建模元语，另一方面也依赖于具体应用的业务需求。
不同应用采用的转换引擎可能来自于不同的产品，但其存在的共性使得后面的报文转换模拟器的架构设计会具有足够的通用性，为了能更好的说明这种共性，我们用IBMWebsphereMulti-channelBankTransformToolkit（简称WMBTT）这个产品中的Formatter作为例子。
WMBTT是IBM公司的一个为银行提供电子平台多渠道解决方案的产品，它广泛的应用于世界不同国家地区的网上银行、柜员系统、手机银行等。
Formatter是WMBTT的核心组成部分，用作格式转换的引擎。
为上面的JavaBean定义一个Formatter的XML的转换规则，如下所示：
清单2.为Customer定义的转换规则
那么对于一个id为“001”，name为“ShaoYu”的Customer对象，最终的转换结果就是“TX01001#ShaoYu#”，这里面的“TX01”是交易码，表示这个报文发到大机后将启动哪个交易服务。
而且，JavaBean与XML规则之间并不是一一对应，一个JavaBean可能会适用于多个转换规则，同样一个转换规则可能会用于不同的JavaBean，这种关系来源于业务需求的多样性。
观察清单2中的XML转换规则，可以发现其描述的是转换器的结构。
每个这样的转换器都会由转换引擎根据XML规则描述进行构建，并且遵循Composite的设计模式，这正是转换引擎的共性：
以XML或其他格式的描述来生成Composite模式的转换器，并由这些转换器完成最终的转换和逆转换工作。
下图是WMBTT中的Formatter的Composite模式的结构。
图2.WMBTT中的Formatter的Composite设计模式
查看原图（大图）
从上面的图中可以看到WMBTT中的Formatter遵循了Composite的设计模式，这种转换器的设计模式具有足够的通用性，以至于许多项目应用中的转换器设计基本都采取这样的结构。
基于此，我们提出了一种报文模拟器的设计。
这种设计思路具有足够的通用性，而基于这种设计实现出来的工具能够帮助项目工程人员提高为转换引擎定义XML规则的效率。
报文模拟器的架构设计
在上一节中，我们介绍了大型主机格式转换的相关的知识，并对转换器的架构和设计模式进行了深入的探索，在这一节中我们将在给出报文转换器的设计架构。
在开始设计报文模拟器之前，首先为报文格式的转换功能做些补充。
从功能的完整性上考虑，报文格式装换部分除了转换引擎外，一般还应为项目的开发者提供编辑报文转换规则所需的工具，如下图所示。
图3.加入规则编辑工具支持的报文格式转换功能
查看原图（大图）
XML规则编辑器的设计并不复杂，且一般功能比较完整的产品都会提供，此处不做深入讨论，从上图中我们很容易看到我们需要补充的报文模拟器会在哪一个位置，如下图所示。
图4.完整的报文格式转换功能
查看原图（大图）
我们已经知道了报文模拟器的在整个格式转换功能中的位置，接下来明确一下报文模拟器所提供的功能。
在一般的项目中，项目开发人员了解了服务器和后端的大型主机之间的通讯协议，并且拿到了通讯报文的样本，需要设计报文转换规则来保证这些样本能够被逆转换到Java对象中，并且这里的Java对象并不是事先定义好的而是根据转换规则生成的（注意：
这点很重要，它可以极大地提高报文转换规则的开发的效率，但同时它也提高了报文模拟器的设计和开发的难度）。
这就是报文模拟器的基本需求，后面的报文模拟器的设计和实现将围绕着这些需求进行。
Eclipse提供了设计良好的易于扩展的插件结构，是一个优秀的工具开发和工具集成平台。
报文模拟器基于Eclipse平台，用户界面包含在一个用户视图中，这不但为报文模拟器本身预留了扩展性也便于与其他的一些相关工具集成（如上图中的基于Eclipse的XML规则编辑器），所以报文模拟器将被开发成Eclipse插件并适当的提供一些配置和扩展。
报文模拟器的运行结果通过树状视图的形式展现出来，需要相应的数据模型支持，这些数据模型一方面为最终的树形视图提供内容，另一方面也记录了最终结果和原样本报文之间的关联。
为了与转换器对应，数据模型同样遵循Composite的设计模式。
以WMBTT中的Formatter为例，定义FormatElementResultData、KCollFormatResultData、ICollFormatResultData和FieldFormatResultData分别对应BTTFormatter结构中的FormatElement、KeyedCollectionFormat、IndexedCollectoinFormat和FieldFormat（另外两种Formatter是为转换报文添加操作指令和分隔符，不对应任何业务数据），如下图所示。
图5.用于展现的数据模型的Composite设计模式
查看原图（大图）
上图中FormatElementResultData中的startPositionInHostString和lengthInReult是用来记录逆转换的结果数据与原报文之间的关联，分别对应在原报文中的起始位置和在原报文中的数据长度。
定义了用于展现的数据模型后，需要在适当的时机向这些模型填充数据。
这个适当的时机就是在转换引擎进行逆转换的过程中，当其中的每一个转换单元完成逆转换的那一时刻，对应到我们刚提及的WMBTT的Formatter的例子，就是每一个FormatElement执行完unformat方法的时刻。
一般情况下，在设计报文模拟器的时候不太可能为其去修改转换引擎的源代码，有些情况下也得不到源代码。
于是，就需要某种技术能够在不侵入式的修改转换引擎的情况下，拦截其中某些方法的执行并插入一定的执行逻辑。
面向切面编程（AspectOrientedProgramming，简称AOP）是一种编程思想意在将主要业务逻辑与支撑性的附加逻辑相分离，现在有多种框架实现了AOP的编程模式，如AspectJ，SpringAOP等。
所以，报文模拟器可以基于AOP的技术来拦截方法和插入逻辑。
我们采用AOP的方式来拦截每个转换单元逆转换的方法，拦截后向上述定义的数据模型的对象中装填内容。
为了得到这些逆转换的数据内容，还需保证逆转换的过程能够顺利的执行。
逆转换过程需要读取报文转换规则同时传入业务数据对象。
传入的业务数据对象用来存放从主机报文逆转换出来的结果。
但是，报文模拟器的目的是帮助检验报文转换规则，而不是校验业务数据对象的正确性，而且，在开发报文转换规则的过程中不断的修改业务数据对象会对开发效率造成很大的影响。
因此，报文模拟器会根据报文转换规则的内容为转换引擎提供所需的业务数据对象来保证引擎的正常运行。
综上，报文模拟器首先需要从定义出的报文转换规则获得转换引擎运行所需的业务数据对象，将业务数据对象、报文转换规则和测试报文输入到转换引擎，利用AOP的技术拦截转换引擎中每个转换单元的逆转换过程并将中间结果和它与测试报文的对应关系填入用于展现的数据模型，最终将这些数据数据模型通过树型结构展现出来，整个运行过程基于Eclipse环境。
报文模拟器的架构如下图所示，其中蓝色箭头标注的是报文模拟器需要实现的几个主要功能。
图6.报文模拟器的架构图
查看原图（大图）
报文模拟器的实现
在上一节中，我们讨论了报文模拟器的架构设计，但对于一些关键点没有给出具体的实现方案，在本节中我们将讨论一些具体的实现相关的问题而使得这种报文模拟器最终能够被开发出来
首先是如何实现从报文转换规则生成转换引擎所需的JavaBean。
一般情况下，从一段配置描述文件生成运行时可使用的JavaBean对象有三种方式。
第一种方式是由编辑工具生成JavaBean定义：
在描述文件被编辑完后，通过编辑工具直接生成定义里所需的JavaBean的Java文件，再将Java文件编译成为Java字节码（Class文件），最终在运行时由类加载器加载并实例化。
第二种方式是运行时生成JavaBean定义：
在运行时根据描述文件中的内容生成包含JavaBean定义的Java文件，再在运行时调用Java编译器将刚生成的Java文件转换成为Java字节码，最终由类加载器加载并实例化。
这种方式比较第一种方式的优点在于所有的工作都在运行时完成，整个过程对于用户是透明的。
第三种方式是在运行时直接创建JavaBean的class字节码：
在运行时根据描述文件借助字节码工具直接生成class字节码再由类加载器加载。
第三种方式与前两种方式最大的不同在于它是直接生成class字节码而无需再经过Java编译器的编译，但是这种方式需要对JavaClass的结构、JVM指令和Java字节码工具都有一定的了解。
上面讨论了三种从描述文件生成JavaBean对象方式，结合报文模拟器的上下文，第一种方式的整个过程对用户不透明，第三种方式的复杂度较高，实现难度较大，所以在报文模拟器中我们选用第二种方式。
第二是采用哪种AOP的实现来拦截转换引擎中某些方法的执行。
在AOP的编程模型中，将核心关注点（业务逻辑）和横切关注点（支撑逻辑）混合的机制称为织入。
AOP的织入按照发生时间可以分为三类，分别为编译时织入、载入时织入和运行时织入。
编译时织入是在编译时对源代码或是字节码进行操作，将方面的代码或字节码直接插到功能代码和或字节码的核心位置处。
如果转换引擎的版本比较稳定，如来自某正式发布的产品，则可以使用这种织入方法，否则转换引擎版本若发生多次变更，就需要多次执行织入过程，这不利于项目过程中的版本维护。
第二种是载入时织入，织入发生在字节码载入的时候。
这种方式不需要对转换引擎进行预先编译，若是转换引擎版本发生更替，只要报文模拟器所涉及到的转换引擎中的接口没有发生变化，报文模拟器就不需要再次编译，所以这种实现方式适用于转换引擎多次发生变化的情况。
第三种是运行时织入，是在运行时实现织入的机制，这种方式的织入实际上是在方法执行的时候进行拦截，比较常见的实现方式是动态代理。
它需要对转换引擎的部分代码进行修改，对其中的一些对象的生成进行包装使其中的某些方法的执行能够被拦截到，所以它可用于开发人员能得到转换引擎代码的情况。
综上，对于转换引擎的不同的情况，载入时织入是都可以适用的，但在真正实现的过程中还要考虑实际的情况，比如倘若报文转换器不是在项目中开发而是随着转换引擎一起在产品中发布，那么采用动态代理是一个较好的选择，因为以动态代理来实现AOP的最为简单轻巧。
当前比较流行的AOP框架AspectJ支持编译时织入和载入时织入，而SpringAOP则采用动态代理的方式。
在项目过程中，当确定了所选用的AOP的载入方式后就可以使用某种的AOP框架或是工具来实现所需功能。
第三是如何将数据模型转化到报文模拟器的界面上的树形控件上。
这可以基于JFace的TreeViewer类来实现。
另外，在使用数据模型构建树形控件的过程中，要将树上的节点与原输入的报文通过数据模型中记录的关联信息关联起来，如当用户点击树上的某个节点时，输入的报文的相关部分就会被高亮，以帮助用户验证逆转换结果的正确与否。
现在报文转换器的几个关键部分的实现问题都已被解决，还需要补充一点的是，在实现过程中为了结构更清晰和版本更便于维护，可以将报文模拟器的核心部分和界面部分实现到两个不同的插件中。
下图给出了报文模拟器的实现结构图，其中AOP采用的AspectJ的载入时织入（LDW）。
图7.报文模拟器的实现结构图
查看原图（大图）
报文模拟器的实际应用
报文模拟器用于检验开发的报文转换规则是否满足需求。
在项目中，一般会先用规则编辑器开发出转换规则，大部分情况是遵照XML格式。
然后，将预先准备好的测试报文和转换规则的访问地址输入报文模拟器，运行后就可得到逆转换的结果，并以树状结构展现出来。
而且，在输入的报文和转换结果的树之间还会有关联，例如，点击树上的某个节点，输入的报文上的对应的部分就会被标注出来；点击报文上的某个部分，其对应的转换结果的树节点也会被突出出来。
在前文所提到的WMBTT的产品中不仅包含了一个名为Formatter的报文转换引擎，也提供了与其相对应的报文模拟器，如下图所示。
此报文模拟器已经被用于某些实际的网银和柜员系统的开发项目，显著提高了转换规则的开发效率。
图8.WMBTT中的报文模拟器
查看原图（大图）
报文模拟器的增强和扩展
在功能上，报文模拟器可进一步的增强并提供一些扩展。
比如在上面的报文模拟器的设计和实现中，业务对象即上文提到的JavaBean是通过报文转换规则生成的，但在实际项目中，有时项目开发人员希望直接使用真实的业务对象去运行报文模拟器，所以需要报文模拟器能够提供相应的配置项，能够允许加载已定义的业务对象并和具体的转换规则进行绑定。
另外，可以为报文模拟器中的切面预留扩展点，利用这些扩展点去开发新的插件就可以实现更多的功能，如将转换引擎逆转换过程中的每一步都记录下来，以供调试和发现问题。
总结
本文从通用的设计角度介绍了大型主机报文模拟器插件的应用背景、架构设计、实现方法、实际应用和增强扩展，并不依赖于某具体的转换引擎的产品或实现。
虽然在本文的论述中我们使用了WMBTT中的Formatter的组件作为案例来阐述某些设计思路，但对于其它的转换引擎这些设计思想和实现方式同样适用。
在实际应用中，为某转换引擎开发报文模拟器需要占用一些资源，但这种付出能够换取后面开发效率的显著提高和项目管理难度的减小，是非常值得的。
升级会员 