基于SOA架构的企业内容管理方案的数据建模
 

2010-03-05 来源:网络

 

本文从数据建模角度,探讨在金融业,基于 SOA 架构如何设计一个平台级的数据模型,以满足其企业内容管理(Enterprise Content Management, ECM)方案的构建。

概述

ECM (Enterprise Content Management)是企业内容管理方案的英文简称,该类解决方案在各行业中正逐渐被广泛的采用。本文将探讨在金融业,基于 SOA 架构如何设计一个平台级的数据模型,以满足其 ECM 方案的构建。

ECM 在金融业中的采用方式普遍表现为,将各种原始单证扫描成图像后存入 ECM 系统,然后在其上建立业务流程,例如贷款审批业务,只需要审批人在原图像上加盖同意的数字章即可转入下一步流程,从而节省了纸张,提高了效率,流程更加透明,查询更加便利。另外,由于金融业分支机构众多,且现有应用众多,所以基于 SOA 的架构来实现 ECM,是一个好的选择。

在这种基于 SOA 的 ECM 架构中,要适应金融业的发展状况,平台级的数据模型设计就显得尤为关键,在本文中,详细论述了该类方案的数据建模要点和过程。

业务与架构

下图是 IBM 在信息管理方面的 SOA 参考架构。本文将要介绍的针对金融业 ECM 进行数据建模的内容对应于图中的 Content Management 区域。下面将首先从业务和架构展开详细描述。

图 1. IBM 信息管理的 SOA 参考架构

IBM 信息管理的 SOA 参考架构

金融业在使用 ECM 方案处理各种单证文件信息时,主要表现为以下方面 :

  • 信息的传输: 各网点将原始单证扫描后按业务分类,分批次传入后台的内容管理服务平台,平台可以部署在营业网点,当然这要视网点业务的规模而定,也可以部署在分中心,分中心还会再和总中心的内容管理平台打交道。这需要借助于 IBM 的企业服务总线 (ESB) 来实现。
  • 流程的处理: 将内容管理平台纳入流程管理,后续业务操作将会基于已扫描的单证信息产生工作流,工作流的基本处理元素存储在 ECM 中。这些需要 IBM 流程服务器来构建。

针对上述业务特征,从 IT 角度来说,ECM 平台需要处理的主要元素包括 :

  • 操作信息
  • 业务信息
  • 文档信息
  • 文档页信息

以及上述各种信息之间的关系

另外,从操作性方面来考虑,还会涉及 :

  • 事务控制
  • 并发控制
  • 权限控制
  • 统计信息,包括运行状态,错误与异常。

由于上述所需处理的元素之间存在相当多的关系,而目前市场上多数的内容管理产品的强项在于内容本身的存储管理,对于内容间的复杂关系的管理,则显得是有点力不从心,例如多层引用关系就会导致内容管理性能的下降,所以使用单纯的内容管理产品往往无法满足金融业的 ECM 应用,需要借助成熟的数据库技术来实现,其架构如图 2 所示,其中元数据,即各种内容的描述信息及其业务关系信息交由数据库来处理,媒体(即内容)信息则交给内容管理产品来负责。

图 2. 内容管理平台架构

   内容管理平台架构

由此产生了数据建模的需要,数据模型需要满足以下要求:

  • 模型通用化,与业务松耦合。
  • 具有很好的扩展性,支持新业务的添加扩展。

下面进入我们富有创意的数据建模工作。  

数据库模型设计概述

在开始我们的数据建模之前,首先让我们简单地回顾一下数据库模型设计的基本步骤,数据建模主要由逻辑模型设计和物理模型设计构成,其中逻辑模型设计主要完成以下三个任务:

  • 标识逻辑实体
  • 标识逻辑实体间关系
  • 标识逻辑实体的属性

物理模型是由逻辑模型转化而来的,要根据具体的数据库产品,为已经设计好的逻辑模型实体选择合适的数据类型和长度(字符串,整形)或精度(浮点数,金额型),将其转化为物理数据库模型,为物理数据库模型设计表空间,bufferpool,表,索引,外键,序列等等,最后得到数据库建库脚本。

有了逻辑模型后,物理模型就是水到渠成的事情了,所以本文重点在逻辑建模内容,物理模型不做赘述。

标识逻辑实体

逻辑模型设计的实体标识阶段,是要根据业务的分析结果,将业务对象抽象出来。

从前面描述的业务和 IT 要素中,我们可以分析得到逻辑实体有 :

  • 参与人——业务人员
  • 事件——扫描,传输,获取
  • 事物——金融单证的图像,也可以叫做资源
  • 时间——隐含在事件要素中
  • 地点——各业务部门

图 3. 组成世界的逻辑对象

   组成世界的逻辑对象

其实上述的五大要素构成了现实世界,所以从中我们可以抽象出所需要的逻辑实体:

  • Event
  • Business Info
  • Resource Item
  • Resource Item Component
  • Party

通过上述思路,可以有效的从具体业务中抽象出逻辑实体,这样即使将来增加其他的内容存储业务,也可以很好的对应进来,不过还需要类型配置来表明是何种业务何种数据,即再增加一个数据字典实体:

  • Classification

这样,我们就标识出了逻辑模型的基础实体。下面再标识实体的属性以及实体间的关系。

标识逻辑实体的属性和关系

EVENT

EVENT 代表了业务事件,其基本要素要求有时间,人员,事件类型,可以得出逻辑实体的属性如下图:

图 4. EVENT

EVENT

Resource Item

Resource Item 代表了资源项,主要内容包括资源项类型,对应的事件,序号等信息,其实体属性如下图:

图 5. Resource Item

Resource Item

Resource Item Component

Resource Item Component 代表了资源项的组件,主要内容包括资源项组件的类型,对应的事件,组件在资源项中的序号,对之进行改动的人员及时间,其实体属性如下图:

图 6. Resource Item Component

Resource Item Component

Business Info

Business Info 代表了业务信息,由于金融业务信息千差万别,这里无法做到用模型概括,所以这里的 Business Info 只是定义了非常通用的业务属性,即业务类型属性。具体的业务可以继承 Business Info 的属性,在其基础之上进行扩展和自定义。详细扩展方式参见模型的可扩展 -BusinessInfo 的继承。

将以上各个实体的属性丰满起来之后,再标识实体间关系,如一对多,一对一,多对多等关系。从而得出实体关系如图 7:

图 7. 实体关系图

 实体关系图

上图 7 中黄色部分是基础实体,代表了我们的业务对象,绿色部分是主要实体间关系衍生而来的关系型实体,灰色部分是分类的定义,其中灰色部分的实体全部继承自 Classification 实体,其继承关系如下图 8 所示:

图 8. 分类继承关系图

   分类继承关系图

上图 8 中的灰色实体全部为逻辑化实体,在逻辑模型转为物理模型时将其内容合并上升到 Classification 实体中。

模型的可扩展性 - Business Info 的继承

模型为新业务提供了扩展点,Business Info 实体是所有业务的父亲,新增添的业务可以在它基础上加以继承,如图 9:

图 9. Business Info 扩展

Business Info 扩展

上图中 XXX Business Info 为新增的某业务示例,它的 ID 继承自 Business Info 实体,其它部分为 XXX 业务特定的业务信息,是扩展时根据具体业务需要自行定义的。

这样就提供了一个扩展框架,可以在此框架之上任意添加新的业务实体。在添加新的业务时,应用程序主程序几乎不需要变动,只需要添加一个新的业务处理类,主程序从 Business Info 中可以得到新业务的 ID 和业务类型 Business Type,然后将 ID 和 Business Type 交给业务处理单元处理,业务处理单元根据业务类型 Business Type 调用相应的业务处理类就可以了,如此扩展带来的成本很低,效率却很高。

模型的松耦合性 - Classification 的使用

模型不仅提供了良好的扩展性,还具备了与业务无关的松耦合性,这个特性是通过 Classification 实体来实现的。在 Classification 实体中,可以定义任意的业务含义,这些业务含义和那些抽象实体(如 Event,Resource Item,Resource Item Component)相结合,就可以处理各种业务情况。

可以把 Classification 理解为字典数据,只不过这个字典数据是需要系统自定义的,而且可以定义成任何含义,从而达到脱离具体的业务用语,实现模型与业务的松散耦合。

事务控制

在基于 SOA 架构的 ECM 应用中,数据交换的内容包括两部分:

  • XML 格式的元数据
  • 媒体文件

两者可以作为一个包传输,也可以分开传输,由于两者在内容,用途和大小上差异很大,分开并行传输是一个好的选择,这就引出了同步和事务控制的问题,这在数据模型中也是需要考虑的,但因为它已经和业务无关了,是纯粹的 IT 技术问题,所以在这里不做深入探讨,下面只是简单介绍思路和要点,有兴趣的读者可以自己尝试完成。

在模型中建立 APP 的主题域,在该域中下定义两个实体:sync list 和 transaction control。

sync list 用于同步元数据和媒体数据,当两者成对收到后即可进行下一步处理。

transaction control 用于控制 DBM 与 CM 存储时多阶段提交的事务完整性,逻辑表示如下图:

图 10. 事务控制时序图

 事务控制时序图

从图 10 中可以看到,事务的每一步执行都预先登记在 Transaction Control 中,即时任何一刻失败了,例如遇到宕机,应用崩溃等,将系统重启后,应用重新扫描 Transaction Control,即可从上次失败处继续处理,从而实现了事务的逻辑完整性。

另外,当客户端提交数据后,由于传输中包括了媒体信息,所以后台的异步传输是需要一些时间的,用户可能在这个时间段内要求查询处理状况,从上面的设计可以看到,可以从以下地方查询到处理情况:

  • 数据在 Sync List 中,说明还在传输途中。
  • 数据在 Transaction control 中,说明还在保存中。

数据不在上述两项中,但在数据库中可以查到对应的记录,说明处理已完成。

结束语

本文针对金融业的 ECM 方案,从数据建模的角度论述了如何设计数据模型,可以实现与业务的松耦合,保持良好的扩展,从而做到平台级别的设计。文中包含了典型的数据模型设计方法,和已经验证多年的成熟的设计技巧,希望能给数据建模人员带来帮助。

从数据建模的角度,文章到这里就可以结束了,但从 ECM 数据平台的角度,则还有很多工作要做,比如如果能在数据库之上设计一层数据存取层,提供标准的 API,从而屏蔽掉数据库和 CM 产品的差异,则就是一个强有力的中间层产品了,这就需要更多的设计与开发工作了。



专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS


面向应用的架构设计实践
单元测试+重构+设计模式
软件架构师—高级实践
软件架构设计方法、案例与实践
嵌入式软件架构设计—高级实践
SOA体系结构实践

相关咨询服务
应用架构设计与构建


锐安科技 软件架构设计方法
成都 嵌入式软件架构设计
上海汽车 嵌入式软件架构设计
北京 软件架构设计
上海 软件架构设计案例与实践
北京 架构设计方法案例与实践
深圳 架构设计方法案例与实践
嵌入式软件架构设计—高级实践
更多...   
 
 
实录 C语言面向对象
主讲:宋宝华
《Linux设备驱动开发详解》的作者
 
实录 基于Tensorflow进行深度学习
主讲:钱兴会
曾任联想集团大数据平台架构师
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号