企业基于 XML 的一致数据模型

企业基于 XML 的统一数据模型

在企业的业务系统增长中，由于不同的业务系统构建时间不一样，业务目标侧重点也不一样，更重要的是企业没有站在企业架构的层次来统一的考虑供多渠道的企业的统一数据字典，使得企业的各个业务系统中数字字典混乱，甚至互相冲突。这造成了诸多的弊端，如：

不同业务系统重复定义数字字典，不便于重用，并增加开发部门的开发工作量没有统一的数据字典，不便于后期统一维护（修改，更新，删除）。没有统一的数据字典，不便于数据集成。如客户在银行网点已经填写了一系列的客户信息，当过几天去申请信用卡的时候，用户被同样的要求输入几天前刚提供的信息。给终端用户也造成了诸多不便。没有统一的数据字典，造成不同的业务系统的数据规范不同意，如向同一个用户在不同的业务系统中要相同的数据。如客户在某银行申请了储蓄卡账号，被要求输入了一系列的客户信息，其中包括职业一项。当该用户信用卡申请表单中也被要求输入一些列信息，也包括职业一栏目。但是这两项的填写选项，输入格式完全不一样。造成了同样的信息在不同的业务系统中规范完全不统一的问题。

企业需要一个通用的数据字典在企业架构层次被所有的业务系统所重用。本文介绍的基于 XML 的数字字典方案—— Context 数字字典可以为企业的多渠道系统提供统一的数据字典，包括类型定义，数据结构定义，校验规则，转换规则等。基于 XML 的统一数据字典，解决了上面的所有缺点。另外还提供了下面这些优点：

基于 XML 语言，支持多平台、多渠道，容易被各个业务系统所重用。学习曲线快，不懂技术的业务人员也可以编辑企业数字字典。对高级技能程序员的依赖减少。本案在土耳其有个客户，利用 Context 数据字典工具，聘请了一些高中生就可以使用工具进行开发。缩短开发周期。XML 简单易读，可以手工编辑或者借助一些 XML 编辑工具快速编辑。便于格式转换，容易与第三方或合作伙伴企业之间进行通讯和业务调用。

根据上面的分析，我们知道企业多渠道 统一数据字典能够解决企业当前碰到的一些问题，具备商业可行性。接下来的篇幅将介绍 Context 数据字典的架构、设计、以及应用实例。

?

?

基于 XML 的 Context 统一数据模型在架构设计上具有以下特性：

支持数据的层次化存取

Context 数据模型最为独特的特性就是通过 Context 树支持数据的层次化。在 Context 树里不同层次的 Context 存放着不同层次和级别的数据和服务。每个子 Context 可以访问它的父 Context 和祖先 Context 的数据和服务。同时通过根上下文（Root Context）可以对整个 Context 树进行遍历和管理。

完全基于 XML 的统一定义和工具支持

在 Context 数据字典里，Context 树的定义，包括 Context 里包含的数据和服务的定义，以及数据类型的定义，都是完全基于 XML 的。 同时有一系列工具支持数据字典的创建和编辑。这一切都大大提高了数据字典的开发和维护效率。

支持企业业务数据共享

通过 Context tree， 父 Context 的数据可以被子 Context 所共享。比如，对于企业服务端的多渠道应用，一些跨渠道的共享数据可以放在 root context 中被各渠道不同交易的 Context 所共享。再比如，对于网上银行的应用，每个登录用户的用户信息可以放到每个用户单独的 session context 中，此 session context 被此用户执行的不同交易的 context 共享。

统一的数据访问接口

Context 数据字典提供了对外的统一的访问接口，不同的数据类型和持久化模式的数据都可以通过统一的接口进行操作。

支持数据持久化

Context 数据模型按是否支持持久化可以分为 Local Context 和 remote context。Local Context 不能被持久化且只能在同一个 JVM 里被访问和共享。Remote Context 可以被持久化到数据库中，并可以被跨 JVM 访问。

多平台、可扩展

Context 数据字典的底层实现是基于 java 的，因此也具有跨平台的可移植性。同时 Context 数据字典的数据项和类型都支持被用户扩展， 平且用户可以设定自定义的数据校验器和转换器。

Money 使用 Validator 确保了它的最小值为 0，Converter 将数据元素转化为字符串（String）类型。

现实世界中的数据分为两类：简单型和复合型。姓名（Name）属于一个简单型，而个人信息 { 姓名，住址，资产 } 则属于复合型。 同理 Type 也分为 Simple 型和 Compound 型，Simple Type 仅包含一个 Property Descriptor，或者说该 Type 仅由一个 Property Descriptor 描述。Compound Type 含有多个 Property Descriptor：一个默认的 Property Descriptor，多个指向其他子 Type 的 Property Descriptor。

清单 2. 带有校验的类型定义实例

用户可以通过如下方法使用 PersonInfo 数据类型：

清单 3. 使用 PersonInfo 数据类型实例

数据模型的最顶端为抽象类 Data Element，它定义了数据元素或者集合类的共有信息 ID 和描述信息。一个数据元素可以是单值或者是集合，这在最大程度上实现了代码重用。DataField 是统一数据模型中唯一可赋值的单元数据，在内存中每个 Field 包含一个值（Value）实例用来存储数据值。DataField 定义示例如下：

若很多个数据元素均包含一些相同数据元素，为了避免重复代码，使用引用标签代替这些重复定义。

清单 4. 引用标签实例

如前所述，Context 为所有 Operation 所共享，当位于多个线程中 Operation 同时访问同一个资源时，系统会自动将访问所有 Context Tree 上的请求串行化，这样可以确保资源（数据）访问的有效性和正确性。

程序是由算法和数据构成，算法在执行的过程中会用到其他辅助的服务资源，例如记录日志，访问数据库，连接服务器等服务资源。在统一企业数据模型中，将算法定义为 Operation，

数据和资源均被定义在 Context 中，而 Context 中包含数据（Data）和辅助资源（Service）。如前所述，Context 采用职责链模式，设计 Context 层次结构时需按照物理意义指明每个 Context 的责任。例如，在银行柜员（Teller）系统中，如果某个数据是被在同一支行（Branch）服务器所管辖的所有工作占共享，那么将该数据定义在支行层次（branch-level）的 Context 中。若工作站 Context （Workstation Context）是 Branch Context 的孩子，那么 Branch Context 的资源对于 WorkStation Context 是可见的。在 Context 内部每个资源都有一个名字，但在 Context 树中可以存在相同名字的资源，访问 Context 内部资源时，由底至上找到第一个同名的资源即可。

这里 BranchServerCtx 被定义为 Root Context， 它包含跨渠道的数据和服务， 如后端连接，日志服务等。Java Channel Context 和 Html Channel Context 被定义为 BranchServerCtx 的子 Context， 它们包含渠道连接特性的数据如客户端类型数据。在各自渠道 Context 下，分别下挂 Session Context。它们包含的是和用户会话相关的共用数据，如客户信息，账户信息等。在通过各渠道执行交易的时候，系统在运行时动态创建交易操作的 Operation Context， 并链接到 Session Context 上。各交易的 Operation Context 如 AccountQueryCtx 和 TransferCtx 都能共享 Session Context 的数据。并通过 Session Context 共享 Channel Context 和 BranchServerCtx 的数据。

首先定义的是 branchServer Context，它是 Root Context，它包含共享的银行数据和服务资源，如下所示：

清单 6. 企业数据字典定义实例

通过以上的 Context 数据模型定义实例，可以看到对于企业复杂数据结构和类型的支持非常充分，并且各个层次的数据定义在逻辑上很清晰，能很好的支持数据共享，减少数据冗余，并且支持不同业务渠道的数据整合。

总结

随着企业应用复杂度增加，使用基于 XML 中间语言的统一数据模型能够降低企业数据字典的建立、维护的复杂性，为企业带来技术价值和业务价值。

文章作者根据在行业应用框架中间件的工作经验，抽象和介绍了基于 XML 中间语言的统一数据模型 Context 的架构、组件、设计原理、以及使用实例。

原文：http://www.ibm.com/developerworks/cn/xml/x-1009chenxm/index.html?ca=drs-