基于企业架构EA的企业信息化建设模型6V09.docx
《基于企业架构EA的企业信息化建设模型6V09.docx》由会员分享，可在线阅读，更多相关《基于企业架构EA的企业信息化建设模型6V09.docx（61页珍藏版）》请在冰豆网上搜索。
基于企业架构EA的企业信息化建设模型6V09
基于企业架构（EA）的
企业信息化建设模型
目录
一、面向服务体系架构（SOA）和数据仓库（DW）的思考1
二、面向服务体系架构（SOA）和业务组件（BC）的思考10
三、基于SOA的业务流程管理（BPM）和工作流（WF）22
四、基于面向对象（OO）的数据库设计模式探讨35
五、基于SOA和ROA的业务组件（BC）模型（草稿）49
肖建国
2010年
前言
企业信息化的建设不是有一个需求就建设一个项目，而是需要一个整体架构模型，架构模型设计信息化的方方面面，以下分别从不同的角度论述了信息化建设中需要关注的几个方面。
一、面向服务体系架构（SOA）和数据仓库（DW）的思考
最初由IBMdeveloperWorks中国网站发表，网址
本文
博客：
肖建国
2009-10-19
摘要
当前业界对面向服务体系架构（SOA）和数据仓库（DataWarehouse，DW）都介绍的很多，提出了很多优秀的解决方案，但是一般是把SOA和DW单独考虑，SOA和DW有着共同的目标—系统整合，由于基于不同的技术思路，提出了不同的方案。
本文将围绕SOA和DW相结合的思路，基于IBM的产品，规划统一的数据库，搭建企业级的技术架构。
SOA和DW概念
随着IT技术的发展，SOA和企业架构（EnterpriseArchitechture，EA）逐步融合，形成了新的架构理论，但是与DW之间还没有很好的集成。
下面首先来看看EA、SOA及DW概念。
企业架构的概念
企业架构（EnterpriseArchitecture，EA）的概念产生于1987年，在IBM的一个内部刊物上发表的一篇文章"AFrameworkforInformationSystemsArchitecture"byJ.A.Zachman（扎克曼）中提出。
概念的提出是为了应对日益复杂的IT系统，以及高投资、低回报的问题。
他认为使用一个逻辑的企业构造蓝图（即一个架构）来定义和控制企业系统及其组件的集成是非常有用的。
为此，Zachman开发了信息、流程、网络、人员、时间、基本原理等6个视角来分析企业，也提供了与这些视角相对应的6个模型，包括语义、概念、逻辑、物理、组件和功能等模型。
随着EA的发展，产生了很多的流派，当前主要的EA架构包含：
通用框架Zachman、TOGAF（TheOpenGroupArchitectureFramework）、以及适用于政府和军方的美国联邦政府的标准架构FEA、美国国防部的DoDAF等。
这些模型主要分成两派，如今正在逐步的融合在一起。
随着企业架构的不断进化，企业架构理论越来越与战略和业务相融合，逐步形成了企业战略、业务架构、IT战略、IT架构等四个层次的IT规划方法论。
IT架构包含数据架构、应用架构、技术架构和IT治理等四个方面的内容，其中技术架构包含集成平台、公共服务平台、基础平台（软件和硬件）和安全平台等，如下图所示：
图1.企业架构（EA）示例
本文以下主要从技术架构中的集成平台角度来看如何搭建应用集成平台和数据集成平台。
面向服务的体系架构
面向服务的体系架构（ServiceOrientedArchitecture，SOA）是一种架构IT系统的方法，它将应用和IT功能划分为单独的业务功能和模块，即所谓的服务。
用户可以构建、部署和整合这些服务，且无需依赖应用程序及其技术平台，从而提高应用的灵活性。
这种业务灵活性可使企业和机构加快发展速度，降低总体拥有成本，及时、准确地获取信息，同时有助于实现更多的资产重用。
而建设SOA体系架构就需要建立一个一致的架构框架，在这种框架中，可以快速地进行开发、集成和重用应用系统。
而对于原有的应用系统来说，可以采用合适的技术手段进行平滑的优化与过渡。
数据仓库
数据仓库（DataWarehouse，DW）是一个面向主题、集成、时变、非易失的数据集合，是支持管理部门的决策过程（W．H．Inmon）。
数据仓库具备以下四个关键特征：
面向主题（SubjectOriented）的数据集合；集成（Integrated）的数据集合；时变（TimeVariant）的数据集合；非易失（Nonvolatile）的数据集合。
根据数据仓库所管理的数据类型和它们所解决的企业问题范围，一般可将数据仓库分为下列３种类型：
操作型数据库（ODS）、数据仓库（DW）和数据集市（DM）。
●操作型数据库（ODS）既可以被用来针对工作数据做决策支持，又可用做将数据加载到数据仓库时的过渡区域。
与DW相比较，ODS有下列特点：
ODS是面向主题和面向综合的；ODS是易变的；ODS仅仅含有目前的、详细的数据，不含有累计的、历史性的数据。
●数据仓库（DW）为通用数据仓库，它既含有大量详细的数据，也含有大量累赘的或聚集的数据，这些数据具有不易改变性和面向历史性。
此种数据仓库被用来进行涵盖多种企业领域上的战略或战术上的决策。
●数据集市（DM）是数据仓库的一种具体化，它可以包含轻度累计、历史的部门数据，适合特定企业中某个部门的需要。
主数据
主数据（MasterData，MD）指系统间共享数据（例如，客户、供应商、账户和组织部门相关数据）。
与记录业务活动，变动较大的交易数据相比，主数据（也称基准数据）变化缓慢，一般每年的变化在20％左右。
在正规的关系数据模型中，交易记录（例如，订单）可通过关键字（例如，订单或发票编号和产品代码）调出主数据。
根据主数据管理实施的复杂程度，参照JillDyche,EvanLevy的观点大体可以把主数据管理可以分为五个层次，其中Level3（通过集中的总线处理，类似于翻译器）可以实现企业内任意两个系统交换数据。
Level3是将数据转换逻辑集中化和标准化，它支持主参照数据的分布式存在（即分布的主数据存储，集中而标准的主数据转换），Level3打破了各个独立应用的组织边界，使用各个系统都能接受的数据标准统一建立和维护主数据（MDM）。
而最高级别Level5（企业数据集中），当主数据记录的详细资料被修改后，所有应用的相关数据元素都将被更新，本级别可以通过SOA的架构平台实现。
通过对以上几个概念的简单分析，可以发现，SOA虽然解决了系统之间的数据实时交互的问题，但是数据的集中，大数据量的数据同步以及主数据管理等问题还没有解决，即使建立了SOA的应用架构，仍然需要进一步进行数据仓库的建设和主数据的管理等。
于是有了建立统一的应用集成平台和数据（信息）集成平台的概念。
SOA和DW结合的企业架构
把数据和服务作为企业的资产
通常，软件重用（SoftwareReuse）是利用事先建立好的软产品创建新软件系统的过程，早在1968年的NATO软件工程会议上就已经提出可复用库的思想。
重用在形式上可以分为二进制、源代码、设计、分析等四个层面的重用，其中基于二进制代码的重用最为重要，从当前来看，基于二进制和源代码实现重用的方式主要有函数库（面向过程）、对象（面向对象）、服务（SOA）等方式。
基于设计和分析实现重用的方式主要是通过模板进行定制，当前主要采用MDA的方式，由设计文档直接生产代码。
要实现基于二进制代码的重用，最重要的一个方法就是实现分离，通过分离，将共用的或者相关性不紧密的功能分离出来，如操作系统、数据库、应用中间件、公共组件等，都是在软件发展历史过程中逐步从一个完整的一体化的系统中分离出来的。
这也符合社会分工的要求，每个企业有多个开发商，即使同一个开发商，由于需要多人的分工合作，这时分工不同部分之间的标准就显得尤为重要。
因此，可以说软件的核心是重用，方法是分离，关键是标准。
围绕这个思路，在本架构中将企业的所有数据独立出来，基于数据架构，建设数据集成平台；将企业的所有应用组件分离出来，基于服务总线，建设应用集成平台。
数据集成平台和应用集成平台共同组成企业的业务基础平台。
未来的企业只有一个数据库，一个应用，所有的用户登陆一个系统可以完成所有的工作，系统的开发则可以基于一个业务基础平台，由多个厂商共同完成，形成一个企业的“云”，其中数据和Web服务是最核心的两个资产。
应用集成平台由企业服务总线（ESB）和公共的业务组件组成。
ESB将不同的组件互相衔接起来，在两个或更多的组件或系统之间实现无缝集成，使整个信息系统就像一个整体一样。
通过统一购买、开发或者封装已有的组件和系统建设公共服务组件，形成企业共享的公用服务平台，避免重复开发、重复购买、标准不一致等问题。
其中公共服务组件包括了门户组件、统一认证组件、工作流组件、GPS组件、GIS组件、BI组件、通用报表组件等。
关于企业服务总线（ESB）和业务组件，相关的介绍很多，本文不做过多的描述，以下重点对数据存储层进行规划设计。
数据集成平台
对于一个企业来说，最理想的状况只有一个数据库，一个应用，但是需要考虑不同业务系统间的相互影响，例如：
一个业务系统的性能问题会影响到其它系统，业务的新增、变更都会对其它系统有一定的影响，争抢已有系统的I/O、CPU资源等，因此，一个数据库是逻辑上一个库，可以物理上分开部署，包括采用数据库分区和数据库集群等技术；应用可以通过集群的方式解决性能问题，应用集群运行所有的业务组件，组件之间通过数据共享或者Web服务调用的方式实现互联。
如果是遗留系统或者是产品化的系统，则通过主数据管理、SOA集成以及数据仓库的ETL等实现集成，关于数据集成平台，如下图所示：
图2.SOA的DW架构
数据存储层规划
为了保证业务系统的性能同时实现数据的共享、数据分析的需要，将数据存储层的数据分为三个层次：
私有数据层、共享数据层和分析数据层。
共享数据层主要的目的是为了数据共享，考虑到性能问题，应避免直接基于共享数据层进行业务操作。
〔三个层次准确的命名应该是私有操作数据层、共享数据层、私有分析数据层〕
1、私有数据层：
由一组业务专用数据库组成，这一层的数据集主要用于支撑企业的运营，是典型的操作型数据环境。
包括经营、财务、人力资源、资产管理等已有系统的数据库，其主要职能在于支撑企业日常的经营和管理活动的运营需要。
未来新的业务组件基于共享数据层进行开发，不在共享数据层的数据也在私有数据层，特别是新的业务组件自己内部处理过程中产生的数据。
私有层的数据，其他的系统或者业务组件除了通过web服务调用之外不能直接访问。
2、共享数据层：
该部分整合所有企业内外数据源，基于企业完整的数据架构进行建设，是所有已有系统和业务组件共享的数据库。
共享层的数据结构清晰，基于业务对象，易于理解，和Web服务一样，是企业的资产，私有数据层的数据通过实时或者准实时的方式同步到共享层或者基于联邦技术直接基于共享层进行开发。
共享层基于主题建模的明细数据和部分汇总数据，是新的系统的业务数据库和数据计算、企业报表的数据源，是对外数据的统一接口。
共享数据层包含业务共享数据、主数据、系统数据、流程数据和元数据。
其中业务共享数据主要包括基于主题的数据模型，是交易类的数据，特点是数据变化快，数据量大；主数据是基础数据，数据变化慢，数据量小，但是查询量大；系统数据主要包含用户数据、功能数据、用户权限数据等，和门户系统结合；流程数据是跨系统的流程数据，是未来工作流处理、流程监控，和审批平台的公共流程数据。
业务共享数据库定位为运营数据存储和业务支持，负责收集企业各系统中的数据，统一存储在业务共享数据库中，作为企业的共享数据。
业务共享数据库采集了企业各系统的业务数据，对源系统的数据质量进行审计监控，同时按照企业统一的主题域数据模型对数据进行整合转换，并为其它业务应用系统提供跨域的数据共享。
由业务共享数据库统一向各业务系统提供数据共享服务，同时业务共享数据库也可以作为新的系统开发的业务数据库。
考虑到业务共享数据库是比较中立的数据，在基于业务共享数据库进行新的系统开发的时候，建议跟业务无关的数据单独建表，并和业务共享数据库的数据区分开，作为新系统自己的数据，存放在私有数据层。
对于现有的系统，在升级改造的时候将现在的通过ETL抽取的方式改为由原系统直接集成的方式，将数据存放到业务共享数据库中。
业务共享数据库也作为DW的理论上唯一数据源，为DW提供高质量的数据；DW中的挖掘和分析结果也要回写到业务共享数据库中。
3、分析数据层：
该层的数据集主要用于支撑企业的管理和决策需要，是典型的分析型数据环境。
它从数据仓库中提取数据并整合管理决策所需要的数据集。
通过数据仓库的建设，对现有各类分布数据源进行数据集中，经过进一步对数据的清洗、过滤、转换后加载至数据仓库中，为数据的集中存储管理和分析利用提供数据支撑环境。
以上通过基于软件重用的思想，描述了需要构建数据集成平台的概念，并对数据平台的功能和数据存储做了说明，通过分层的数据管理，建立企业统一的数据集成平台。
基于IBM产品体系的实现
技术架构概述
根据前文提到的业务基础平台，基于IBM的产品体系，在实际搭建的时候，需要的服务器包含数据库服务器（产品：
DB2）、应用服务器（产品：
WAS）、流程整合服务器（产品：
WPS，实现服务总线和流程编排）和信息集成服务器（产品：
WII，实现数据的SQL复制或者Q复制），如下图所示（本方案是建议方案的一种，如ESB可以选择WESB、DataPower或WebSphereMessageBroker等，需要根据不同企业特点进行选择）：
图3.网络拓扑图
产品实现
数据库服务器（IBMDB2EnterpriseServer，DB2），DB2在本方案中主要实现数据存储层的建立，包含私有层数据库、共享层数据库和分析层数据库。
如前文所述，考虑到遗留系统、产品化软件，特别是性能问题，在实际部署的时候需要考虑私有层数据库可以单独在一个表空间甚至是一个独立的磁盘中进行存储，保证业务组件能够不受其他业务组件的影响，数据存储层能够灵活的扩展，适应大数据量、多系统的处理。
DB2提供多平台支持，因此能够在各种系统平台上发挥该产品的功能。
DB2能够管理多种数据类型，并能联合各类IBM系列数据库上的关系型数据。
DB2允许数据库管理员把数据库划分成若干称作表空间（tablespaces）的部分，表空间可以单独管理，这就大大增强了管理特大型数据库的能力，它能包含上兆兆字节数据。
DB2在SMP（对称多处理器）或MPP（并行节点机）环境下，都可充分发挥其并行处理能力，特别是当数据量累计到一定程度，通过Cluster（集群），作为并行关系数据库它允许把单个数据库映象散布到多个系统上，从而能利用所有系统的处理能力以满足用户对数据的需求。
DB2可以在并行处理的多个节点上同时运行某一查询，从而提高查询性能，必要时它可以重新编写查询以优化性能，从而保证了可以实现一个数据库的设计理念。
通过多种数据类型、多平台、表空间、集群处理、并行处理等技术，可以实现数据存储层的统一管理。
信息集成服务器（IBMWebSphereInformationIntegrator，WII）信息集成服务器实现信息总线功能，主要包含数据联邦和数据复制功能，通过数据联邦和数据复制实现私有层数据和共享层数据的同步。
联邦技术能够统一地访问以任何格式（结构化的和非结构化的）存储的任何数字信息。
WII支持多种数据源，包括DB2/390，DB2/400，DB2UDB、Informix、Oracle、Sybase、SQLServer等关系型数据库，也包括非关系型的文本文件和Excel文件。
通过对各种数据源的支持，可以在逻辑上实现不同数据库的统一视图。
数据复制，在多个厂商的数据库产品之间实现复制，WII使用基于SQL的复制架构，该架构可在管理计划、转换和分发拓扑结构中最大限度地提高灵活性和效率。
在SQL复制中，WII使用基于日志或基于触发器的机制捕获变更，并将其插入到关系分级表中。
然后应用过程异步处理目标系统的更新。
WII可以广泛应用于填充仓库或集市、在不同应用程序之间维护数据一致性或者在总部和分支机构或零售商之间高效管理分发和合并。
该技术采用经典的数据库复制体系结构实现，IBM的基于队列的新复制架构（简称Q复制技术），是一种高吞吐量、低延迟的复制方法，它使用WebSphereMQ的消息队列在源数据库与目标数据库之间，或者在源子系统与目标子系统之间传递事务。
QCapture程序通过读取DB2的恢复日志来获取你所指定的复制源表的变化情况；继而，QCapture程序将事务作为消息，通过队列发送；最后，QApply程序从队列中读取这些消息，并将其应用于目标表。
通过WII，将分散的数据库以数据联邦或者数据复制的技术集成起来，实现数据层面的集成。
应用服务器（IBMWebSphereApplicationServer，WAS），WAS所有业务组件的运行的容器，实现统一的应用集成平台。
应用集成平台需要主要考虑应用集群技术。
WAS完全提供了独立于硬件系统的集群功能。
在WebSphere应用服务器中，提供了两种方式的Cluster：
垂直的方式和水平的方式。
它们分别是为了适应不同的应用环境而设置的，垂直的Cluster允许在一台机器上实现动态负载均衡；而水平的Cluster允许在多台机器上实现动态的负载均衡。
二者可以有机的协调工作，为复杂环境的应用实现负载均衡提供了强有力的保证。
WebSphere使用的是一种Nanny--AdministrationServer--ApplicationServer的体系结构，使用该结构，所有的ApplicationServer（应用服务器）将由一个AdminisrationServer（管理服务器）来监视管理，一旦由于一个特殊的原因（例如进程被杀掉）导致应用服务器停止，管理服务器将自动重新启动该应用服务器；同样，AdministrationServer（管理服务器）由一个“Nanny（保姆）”进程管理，该“保姆”进程一旦检测到管理服务器停止也将自动重新启动它。
这样WebSphere从体系结构上就最大限度地保证服务器程序的可靠稳定运行。
通过WAS的独立硬件的集群功能，实现垂直或者水平的两种方式，从而保证业务组件统一管理。
流程整合服务器（IBMWebSphereProcessServer，WPS）服务总线和流程编排，实现基于Web服务的数据同步，业务组件之间的服务调用等。
WPS是一个基于WAS的全面的面向服务的体系结构的集成平台。
面向服务的体系结构提供了动态开发和修改集成应用程序的功能。
通过面向服务的体系结构，可以将现有应用程序与更新的应用程序相集成，以便它们透明地协同工作。
WebSphereAdapters包括特定于应用程序的适配器（例如：
用于Siebel、SAP或者PeopleSoft的适配器），以及技术适配器（例如：
用于关系数据库或者平面文件的适配器）。
WebSphereAdapter完全符合JCA1.5的架构，可以方便地在WPS中使用。
通过IBM提供的丰富的WebSphereAdapter产品，可以轻松地操作已有业务系统中的数据，从而实现对现有IT资产的重用。
WebSphereProcessServer中的唯一体系结构允许将业务功能封装到各个模块，然后单独进行更新。
例如，可以使用包含用于实际审批的人工任务的审批模块，随后使用包含业务规则的另一个审批模块替换它。
这一更改对于该模块的使用者是完全透明的。
此外，封装的概念确保了数据和接口定义在使用它们的位置封装。
例如，可以隐藏如何在模块内的后端系统中表示使用者的细节，而模块本身将具有一般业务对象的通用接口作为数据公开。
这一规范的数据表示还启用了任何给定集成应用程序中的高度重用。
通过WPS，搭建企业服务总线，实现基于Web服务数据同步和组件之间的整合。
以上通过对技术架构总体概述以及采用对应的IBM相关产品的具体实现，根据IBM产品所具有的产品特性，论证了SOA和DW结合的企业架构实现的可能性。
总结
本文基于企业架构（EA）、面向服务体系架构（SOA）、数据仓库（DW）、主数据（MD）等概念，构建了数据集成平台和业务集成平台共同组成的企业级业务基础平台，重点描述了基于SOA的数据集成平台中数据存储层的建设方案，提出了将数据和服务作为企业资产管理的思想，方案实现了数据和应用一体化设计，并在最后给出了基于IBM产品体系建设的建议方案和产品的定位。
二、面向服务体系架构（SOA）和业务组件（BC）的思考
最初由IBMdeveloperWorks中国网站发表，网址
本文
博客：
肖建国
2010-03-08
摘要
在基于面向服务体系架构（SOA）中，“组件化”是一个很重要的概念，如何进行“组件化”开发是搭建企业级业务基础平台时需要考虑的一个重要课题，本文通过建立业务组件（BC）接口模型及内部结构模型，提供了一个在新开发系统环境下基于Web服务和OSGi标准的组件化开发模型。
什么是业务组件（BC）
组件化、模块化是软件开发中一个很重要的概念，基于面向服务体系架构（ServiceOrientedArchitecture，SOA）下，如何实现组件化，有各种实现方式，下面通过对各种组件概念的对比，从技术角度提出业务组件（BusinessComponent，BC）定义，并结合对总线模式的分析，给出企业服务总线和类总线的实现方案。
企业架构（EA）
关于企业架构（EnterpriseArchitecture，EA）和面向服务体系架构（SOA）在《面向服务体系架构（SOA）和数据仓库（DW）的思考》（以下简称《SOA和DW》）一文中做了介绍，企业架构包含企业战略、业务架构、IT战略、IT架构四个部分，IT架构如下图IT架构模型所示，包含数据架构、应用架构、技术架构和治理架构等四个方面，其中技术架构包含集成平台、公共服务平台、基础平台（软件和硬件、网络）和安全平台等，《SOA和DW》着重对如何构建数据架构特别是数据存储做了详细的阐述，本文基于《SOA和DW》进一步对如何搭建SOA体系进行研究，将着重描述如何基于可扩展的、灵活的企业级的集成平台、公共服务平台进行组件化开发。
图1.IT架构模型
业务组件（BC）
当前，提到组件（Component）的有很多概念，比如分布式组件DCOM、J2EE、CORBA等，IBM的业务组件模型（ComponentBusinessModel，CBM），SOA中的服务组件架构（ServiceComponentArchitecture，SCA）等。
本文提到的业务组件（BusinessComponent，BC）定义为一个可以独立运行的系统或者模块，业务组件的目的是以方便业务组件独立升级和减少不必要的组件之间的交互为基本原则，通过一定程度的分离，实现《SOA和DW》中提到的重用（SoftWAReReuse）。
如果业务组件是共用的，是其它业务组件需要重用的，称之为公共业务组件（简称公共组件），所有的公共组件组成企业架构中技术架构的公共服务平台，比如主数据管理、系统管理、统一认证管理、通用报表等，这些都是公共组件。
组件业务模
升级会员 