随着企业业务的增长，企业的系统也在不断增长中。这些系统有的是提供给内部用户使用，有的是为外部客户使用，通过多种渠道访问企业的业务，形成了如下架构图中的多渠道的企业架构。如银行的多渠道架构，客户可以通过浏览器的网上银行，手机银行，高柜，低柜台，电话银行，ATM 服务等等来进行银行业务办理。
在企业的业务系统增长中，由于不同的业务系统构建时间不一样，业务目标侧重点也不一样，更重要的是企业没有站在企业架构的层次来统一的考虑供多渠道的企业的统一数据字典，使得企业的各个业务系统中数字字典混乱，甚至互相冲突。这造成了诸多的弊端，如：
- 不同业务系统重复定义数字字典，不便于重用，并增加开发部门的开发工作量
- 没有统一的数据字典，不便于后期统一维护（修改，更新，删除）。
- 没有统一的数据字典，不便于数据集成。如客户在银行网点已经填写了一系列的客户信息，当过几天去申请信用卡的时候，用户被同样的要求输入几天前刚提供的信息。给终端用户也造成了诸多不便。
- 没有统一的数据字典，造成不同的业务系统的数据规范不同意，如向同一个用户在不同的业务系统中要相同的数据。如客户在某银行申请了储蓄卡账号，被要求输入了一系列的客户信息，其中包括职业一项。当该用户信用卡申请表单中也被要求输入一些列信息，也包括职业一栏目。但是这两项的填写选项，输入格式完全不一样。造成了同样的信息在不同的业务系统中规范完全不统一的问题。
企业需要一个通用的数据字典在企业架构层次被所有的业务系统所重用。本文介绍的基于 XML 的数字字典方案—— Context 数字字典可以为企业的多渠道系统提供统一的数据字典，包括类型定义，数据结构定义，校验规则，转换规则等。基于 XML 的统一数据字典，解决了上面的所有缺点。另外还提供了下面这些优点：
- 基于 XML 语言，支持多平台、多渠道，容易被各个业务系统所重用。
- 学习曲线快，不懂技术的业务人员也可以编辑企业数字字典。对高级技能程序员的依赖减少。本案在土耳其有个客户，利用 Context 数据字典工具，聘请了一些高中生就可以使用工具进行开发。
- 缩短开发周期。XML 简单易读，可以手工编辑或者借助一些 XML 编辑工具快速编辑。
- 便于格式转换，容易与第三方或合作伙伴企业之间进行通讯和业务调用。
根据上面的分析，我们知道企业多渠道 统一数据字典能够解决企业当前碰到的一些问题，具备商业可行性。接下来的篇幅将介绍 Context 数据字典的架构、设计、以及应用实例。
企业统一的基于 XML 的 Context 数据模型是构建在上下文 (Context) 基础上的。Context 是针对某一上下文操作定义的包含企业数据和服务的对象。不同的 Context 可以通过父子链接组成一个 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 数据字典的数据项和类型都支持被用户扩展， 平且用户可以设定自定义的数据校验器和转换器。
企业数据类型可包含 Type 类型和 Generic 类型。Type 数据元素代表业务对象，如日期（Date）、帐户列表（AccountList）、金额（Money）。它与非 Type 数据元素的主要区别是：Type 数据包含业务类型和业务规则信息，其中业务规则信息可包括数据显示格式、数据值域等等。Type 包含一个或者多个 Property Descriptors 来存储业务规则信息，而非 Type 类型则没有。一个典型的 Type 定义如下：
<type id="Money" implClass="com.ibm.btt.base.DataField"> <Descriptor id="typeDefault" implClass="com.ibm.btt.base.types.ext.FloatDescriptor"> <Converter convTypes="default" implClass="com.ibm.btt.base.types.ext.FloatConverter"/> <Validator implClass="com.ibm.btt.base.types.ext.FloatValidator" lowerLimit="0"/> </Descriptor > </type> |
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。
<type id="String" implClass="com.ibm.btt.base.DataField">
<descriptor id="typeDefault"
implClass="com.ibm.btt.base.types.ext.StringPropertyDescriptor">
<Converter convTypes="default，host"
implClass="com.ibm.btt.base.types.ext.StringConverter"/>
<Validator implClass="com.ibm.btt.base.types.ext.StringValidator"/>
</descriptor>
</type>
<type id="PersonInfo" implClass="com.ibm.btt.base.KeyedCollection">
<descriptor id="typeDefault"
implClass="com.ibm.btt.base.types.KCollPropertyDescriptor"/>
<dataDescriptor id="name" refType="String"/>
<dataDescriptor id="address" refType="String"/>
<dataDescriptor id="asset" refType="Money"/>
</type>
|
用户可以通过如下方法使用 PersonInfo 数据类型：
KeyedCollection info = (KeyedCollection)DSEType.readObject("PersonInfo");
info.setValueAt("name"， "Tom");
info.setValueAt("address"， "ZhongShan Road， Xian");
info.setValueAt("asset"， new Float(5000));
|
统一企业数据模型中使用 XML 描述数据字典，XML 的层次结构与现实世界数据对象结构天衣无缝的映射。用户无需做概念抽象，可以非常简单实现从设计到代码的转换。为了适应现实中的层次数据结构，统一数据模型引入组合设计模式（Composite Pattern）描述数据对象关系。如图所示：
数据模型的最顶端为抽象类 Data Element，它定义了数据元素或者集合类的共有信息 ID 和描述信息。一个数据元素可以是单值或者是集合，这在最大程度上实现了代码重用。DataField 是统一数据模型中唯一可赋值的单元数据，在内存中每个 Field 包含一个值（Value）实例用来存储数据值。DataField 定义示例如下：
<field id="field1" description="This is an example"/> Keyed Collection 是一个有序的数据集合，使用数据名称来访问其中的数据元素， 所以出现在同一个 Keyed Collection 的数据名称必须唯一。可以简单的把 Keyed Collection 想象为字典（Dictionary），内部的数据元素被组织为键值对（Key-value pairs），如下所示： <kColl id="coll1"> <field id="field1"/> <field id="field2"/> </kColl> Indexed Collection 类似数组，使用位置（Position）访问其内部元素， 所有内部元素为同一种类型。如图所示。如需访问 customer 中的街道信息， 可以使用组合键： customerListData.2.address.street。 |
图 4. 复杂数据类型实例
若很多个数据元素均包含一些相同数据元素，为了避免重复代码，使用引用标签代替这些重复定义。
<kColl id="coll1"> <field id="field1"/> <field id="field2"/> </kColl> <iColl id="icoll1" size="2"> <refData refId="coll1"/> </iColl> |
Context 定义了一个操作或者业务实体的资源集合（数据和服务）。Context 作为基本资源模型将应用系统中各 Operation 松散的耦合在一起，Operation 交互只需要将 Context 中数据格式化后双向传递。
Context 被组织成为树状结构，顶层是通用资源，底层为专用资源。Context 树在系统中有且只有一个，因此所有的用户操作可以共享 Context 树中的资源。例如，一个用户 Context 包含用户级信息，同时它含有几个子 Context，分别包含一些操作信息。Context 采用职责链模式，当 Operation 请求一些数据或者服务时，但在当前的 Operation Context 中无法找到这些资源信息，会自动从 Parent context 中查找，直到找到资源为止。一个典型的 Context 定义如下所示：
<context id="myWorkstation" type="workstation" parent="myBranch"> <refKColl refId="myWorkstationData" /> <refService refId="msreService" type="service" alias="msre"/> </context> |
如前所述，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 内部资源时，由底至上找到第一个同名的资源即可。
在这里介绍使用 Context 数据模型实现多渠道银行应用的一个实例。此银行实现柜员桌面富客户端和网上银行的多渠道整合，并重用服务端的业务逻辑如账户查询、转账等。在这里假设富客户端通过 Java Client 渠道，网上银行通过 HTML Client 渠道接入服务端。在服务端我们定义 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，它包含共享的银行数据和服务资源，如下所示：
<context id="branchServer" parent="nil" type="branch"> <refKColl refId="branchData"/> <refService alias="CSServer" refId="realCSServer" type="cs"/> <refService refId="CommunicationsPool" alias="pool" type="pool"/> </context> <kColl id="branchData"> <refData refId="BranchId"/> </kColl> // 然后定义渠道上下文 Channel Context， 它是父 Context 是 branchServer Context。 <context id="javaChannelCtx" parent="branchServer" type="op"> <refKColl refId="javaChannelData"/> </context> <kColl id="javaChannelData"> <refData refId="clientType"/> </kColl> // 接下来定义的是渠道会话 Context，它包含用户登录后的会话上下文操作所用到的数据如用户 ID、 客户信息、账户信息等。Session Context 在用户登录后会被创建并链接为 Channel Context 的子 Context。为了简洁起见，下面只列出了 Java 渠道的 Session Context 定义。 <context id="javaSessionCtx" type="op"> <refKColl refId="javaSessionData"/> </context> // 在上面会话上下文包含的是一个集合数据 javaSessionData， 它被定义为一个 KeyedCollection 如下： <kColl id="javaSessionData"> <refData refId="TID"/> <refData refId="UserId"/> <refData refId="CustomerId"/> <refData refId="CustomerName"/> <refData refId="AccountList "/> <refData refId="HostBuff"/> <refData refId="sessionID"/> </kColl> // 在其中包含的账户信息被定义为一个账户类型数据的数组 (Indexed Collection)。 <iColl id="AccountList"> <refData refId="account "/> </iColl> <data id="account" refType="Account"/> // 账户类型定义如下： <type id="Account" implClass="com.ibm.dse.base.KeyedCollection"> <descriptor id="typeDefault" implClass="com.ibm.dse.base.types.KCollPropertyDescriptor"/> <dataDescriptor id="Name" refType="String"/> <dataDescriptor id="Type" refType="String"/> <dataDescriptor id="AccountNumber" refType="String"/> <dataDescriptor id="Balance" refType="Amount"/> </type> // 最后我们需要针对交易操作定义 Operation Context， 如针对转账交易定义 transferOperationCtx。转账交易 Context 是 Session Context 的子 Context， 能共享上层链路上所有 Context 的数据。 <context id="transferOperationCtx" type="oper"> <refKColl refId="accountTransferData"/> </context> <kColl id="accountTransferData"> <data id="acctFrom" refType="String"> <param id="isMandatory" value="true" /> </data> <data id="acctTo" refType="String"> <param id="isMandatory" value="true" /> </data> <data id="amount" refType="String"> <param id="isMandatory" value="true" /> </data> < data id="AccountBalance" refType="Money"/> <field id="outcome" /> <field id="TrxReplyCode" /> <field id="TrxErrorMessage" /> </kColl> |
通过以上的 Context 数据模型定义实例，可以看到对于企业复杂数据结构和类型的支持非常充分，并且各个层次的数据定义在逻辑上很清晰，能很好的支持数据共享，减少数据冗余，并且支持不同业务渠道的数据整合。
随着企业应用复杂度增加，使用基于 XML 中间语言的统一数据模型能够降低企业数据字典的建立、维护的复杂性，为企业带来技术价值和业务价值。
文章作者根据在行业应用框架中间件的工作经验，抽象和介绍了基于 XML 中间语言的统一数据模型 Context 的架构、组件、设计原理、以及使用实例。
原文：http://www.ibm.com/developerworks/cn/xml/x-1009chenxm/index.html?ca=drs-
2056
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
