大型主机报文模拟器插件的设计与开发

大型主机报文模拟器插件的设计与开发2010-10-28基于规则的大型主机报文格式转换

大型主机最早广泛应用的行业是银行业，世界上绝大多数的银行后端系统是运行在大型主机上，因为相对于其他类型的计算机，大型主机在 I/O 能力、非数值计算能力、稳定性、安全性上面有着其它类型的计算机系统无可比拟的优势。近年来，随着企业在数据集中、应用整合、IT 基础架构迁移和海量数据处理等方面的强烈需求，加之虚拟化技术的迅猛发展和大型机整体成本相对低廉的特点，使得其在除银行业之外的制造业、保险、航空、运输、政府、大型零售企业等行业都获得了大量成功的应用。然而，对于一个专业的 J2EE 应用开发者而言，主机相关的内容比较陌生且不直观，比如，对于像“Tx01#010 20319#01223@michale@19@china beijing#2009.07.04#”这样的交易报文就会给这样一些只熟悉上层应用的开发者造成一定的麻烦，当然这个示例较为简单，而实际应用中的那些较长的毫无可读性而言的主机报文，对于一个想弄清其含义的开发者来说就是一个噩梦。而且，大型主机基本上都应用于较复杂的系统，里面的报文格式千差万别，虽然一般会有一些规则文件去描述这些格式，但庞大的报文格式数量和低级的容错性还是会令开发者望而生畏（笔者就曾经见到过一个不大的项目中的报文格式的描述文档，打印出来有足足一厚本）。因此，本文根据一些实际项目应用的经验总结，提出一种基于 Eclipse 的大型主机报文模拟工具的设计架构并给出一些的实现思路。这个工具主要是用于辅助开发人员进行报文格式规则的设计和校验，帮助开发人员快速的理解报文中的内容，实际证明：这样的辅助工具在项目实施中能够大大提高主机报文相关内容的开发效率，降低开发难度。

在开始介绍这个报文模拟工具之前，我们先简单描述一下基于规则的大型主机报文格式转换的架构。一般来说，这种应用中的报文格式转换要实现两个需求，一是将一个 java 对象中的内容转化成一条主机报文，二是将一条主机报文中的内容转换到某一个 java 对象中去。同时，还要求这种转换规则可以用某种方式进行描述，并外化出来，比如用 XML 来描述这些规则并保存到文件中。由此可见，报文格式转换包含两部分关键内容，一个转换引擎，负责转换和反转换，一些存在文件中或是存在数据库中的规则，如下图所收。

图 1. 基于规则的报文格式转换功能

举个例子，现有一个名为 Customer 的 Java Bean，里面包含了 id 和 name 两个属性。清单 1. Customer 的定义

public class Customer {
private String id;
private String name;
public String getName（） {
return name;
}
public void setName（String name） {
this.name = name;
}
public String getId（） {
return id;
}
public void setId（String id） {
this.id = id;
}
}

为这个 Java Bean 定义 XML 格式的转换规则，一方面依赖于这个转换引擎支持的规则建模元语，另一方面也依赖于具体应用的业务需求。不同应用采用的转换引擎可能来自于不同的产品，但其存在的共性使得后面的报文转换模拟器的架构设计会具有足够的通用性，为了能更好的说明这种共性，我们用 IBM Websphere Multi-channel Bank Transform Toolkit（简称 WMBTT）这个产品中的 Formatter 作为例子。WMBTT 是 IBM 公司的一个为银行提供电子平台多渠道解决方案的产品，它广泛的应用于世界不同国家地区的网上银行、柜员系统、手机银行等。Formatter 是 WMBTT 的核心组成部分，用作格式转换的引擎。为上面的 Java Bean 定义一个 Formatter 的 XML 的转换规则，如下所示：清单 2. 为 Customer 定义的转换规则

<fmtDef id="customerFmt">
<record>
<constant value="TX01"/>
<fString dataName="id"/>
<delim delimChar="#"/>
<fString dataName="name"/>
<delim delimChar="#"/>
</record>
</fmtDef>

那么对于一个 id 为“001”，name 为“ShaoYu”的 Customer 对象，最终的转换结果就是“TX01001#ShaoYu#”，这里面的“TX01”是交易码，表示这个报文发到大机后将启动哪个交易服务。而且，Java Bean 与 XML 规则之间并不是一一对应，一个 Java Bean 可能会适用于多个转换规则，同样一个转换规则可能会用于不同的 Java Bean，这种关系来源于业务需求的多样性。

观察清单 2 中的 XML 转换规则，可以发现其描述的是转换器的结构。每个这样的转换器都会由转换引擎根据 XML 规则描述进行构建，并且遵循 Composite 的设计模式，这正是转换引擎的共性：以 XML 或其他格式的描述来生成 Composite 模式的转换器，并由这些转换器完成最终的转换和逆转换工作。下图是 WMBTT 中的 Formatter 的 Composite 模式的结构。

图 2. WMBTT 中的 Formatter 的 Composite 设计模式

从上面的图中可以看到 WMBTT 中的 Formatter 遵循了 Composite 的设计模式，这种转换器的设计模式具有足够的通用性，以至于许多项目应用中的转换器设计基本都采取这样的结构。基于此，我们提出了一种报文模拟器的设计。这种设计思路具有足够的通用性，而基于这种设计实现出来的工具能够帮助项目工程人员提高为转换引擎定义 XML 规则的效率。