前言
业务基础平台是业务逻辑应用和基础架构平台之间的一个中间层，解决 “应用软件的业务描述和操做系统平台、软件基础架构平台之间的交互与管理问题”。不少国内软件厂商，很难在操做系统平台和软件基础架构平台上有所做为，所以国内众多的软件厂商纷纷推出本身的业务基础平台，把业务基础平台看做本身的核心技术。当前比较流行的业务基础平台大多都是基于早期的技术架构，虽然通过了多年的发展，可是因为技术架构不是彻底基于 SOA 的组件化概念搭建，组件化支持并非很完全，如何在 SOA 下搭建组件化业务基础平台成为当前软件开发商所面临的新课题，本文将会基于组件化的概念，介绍一种搭建组件化业务基础平台的思路，首先咱们看一下什么是“业务基础平台”，以及组件化概念。数据库
业务基础平台
如前言所述，业务基础平台是业务逻辑应用和基础架构平台之间的一个中间层，解决 “应用软件的业务描述和操做系统平台、软件基础架构平台之间的交互与管理问题”。操做系统平台解决了“应用软件系统与硬件之间的交互与管理问题”，软件基础架构平台解决了“应用软件系统与操做系统平台之间的交互与管理问题”，而业务基础平台则是解决了“应用软件的业务描述与操做系统平台、软件基础架构平台之间的交互与管理问题”。以下图所示：设计模式
图 1. 业务基础平台在技术架构中的位置
通常业务基础平台都包含两个部分，运行环境和开发环境，开发环境主要用于解决如何更加快速的开发，也是业务基础平台的核心内容，本文主要介绍业务基础平台的运行环境架构，关于开发环境将不在进一步论述。服务器
业务组件和公共组件
业务组件（Business Component，BC）是一个能够独立运行的系统或者模块，业务组件的目的是以方便业务组件独立升级和减小没必要要的组件之间的交互为基本原则，经过必定程度的分离，实现软件重用（Software Reuse）。若是业务组件是共用的，是其它业务组件须要重用的，称之为公共业务组件（简称公共组件），全部的公共组件组成企业架构中技术架构的公共服务平台，好比主数据管理、系统管理、统一认证管理、通用报表等，这些都是公共组件。详见以前的文章《面向服务体系架构（SOA）和业务组件（BC）的思考》（如下简称 SOA 和 BC）关于业务组件和公共组件的说明。数据结构
组件化业务基础平台
基于组件化业务基础平台和传统的业务基础平台主要的差别在于组件化业务基础平台具备更多的灵活性、可扩展性，可以更加方便的进行组件升级和组件维护。特别是对于大型的行业软件来讲，易于升级、易于维护，可以灵活的扩展成为评测一个业务基础平台的一个重要标准，随着业务的不断发展，不少一体化行业软件代码数量已经超过 1G，如何对如此庞大规模的代码进行维护、升级成为软件开发者和运维管理者日益关注的一个课题，代码关系复杂、系统启动慢成为一个大型系统所面临的一个主要矛盾。组件化业务基础平台主要用于解决简化开发，快速系统维护的问题，如下经过对两种业务基础平台的对比，对组件化业务基础平台的组件实现、调用方式、所包含的公共组件及组件进行说明。架构
传统的业务基础平台
当前在 J2EE 框架下业务基础平台基本上是采用了“Spring Framework”、“Expresso Framework”、等开源软件为基础的框架，业务系统基于业务基础平台进行开发，在一个企业内部，很容易造成基于一个业务基础平台横向开发出多个业务模块，甚至是跨行业的业务组件，基于一个业务基础平台开发的系统，全部的业务组件能够基于一个数据库运行，搭建一体化的业务应用系统。当前常见的业务基础平台包括浪潮 Loushang 平台、SAP 的 Net Weaver、金蝶 Apusic、普元 EOS 等。其架构以下图所示：框架
图 2. 业务基础平台模型
可是这种模式存在几个重大的缺陷：运维
- 业务模块和业务基础平台紧耦合，业务模块过于依赖于业务基础平台，一旦业务基础平台升级，业务模块也不得不升级，不少业务系统须要重写；
- 随着业务的发展，业务模块不断增长，系统愈来愈庞大，系统难于管理，特别是随着系统代码的不断增长，性能愈来愈差；
- 业务模块升级困难，因为各个业务模块和业务基础平台紧密，各个业务组件很难独自升级，并且全部相关的升级不得不考虑业务基础平台的影响。
如何既能实现一体化，又能够解决以上问题是当前业务基础平台须要解决的问题。数据库设计
组件化业务基础平台
在《面向服务体系架构（SOA）和数据仓库（DW）的思考》（如下简称《 SOA 和 DW 》）一文中曾经提出一个原则：“软件的核心是重用，方法是分离，关键是标准”，组件化基础业务平台依然是遵循这个原则。随着 SOA 技术的逐步发展，SOA 已经成为像面向对象同样虽然不像“云计算”那样时髦，却成为一个重要的软件体系设计模式。因为不少软件都是基于业务基础平台进行开发的，业务基础平台的组件化成为组件化开发的一个基础的要求，若是业务基础平台没有实现组件化，组件化开发仍是停留在以前的遗留系统改造的概念中。如何实现业务基础平台的组件化，如何利用组件化对业务基础平台进行改形成为业务基础平台关注的一个焦点。
组件化开发，首先是业务基础平台自己的组件化，把业务基础平台当作是一个独立的组件，即《 SOA 和 BC 》所描述的基于企业集成平台（企业门户、应用集成、数据集成）的公共组件所描述的内容。
业务基础平台的组件化，并非全部的内容所有组件化，有些内容是没法分离出去的，所以首先要把业务基础平台的内核分离出来，创建一个业务基础平台的微内核，微内核是跟每个业务组件紧密相关的。而后把业务基础平台中能够分离出来的内容单独做为一个组件，即公共组件，从而实现业务组件和公共组件的分离。
业务组件和公共组件使用一个数据库，经过公共组件及相关的标准实现整合，若是还有已有的系统，则经过企业集成平台进行整合。以下图所示：
图 3. 组件化业务基础平台模型
业务基础平台主要业务组件
公共服务组件包含系统管理、流程管理、主数据管理、元数据管理等，在数据层面分别对应着系统数据、流程数据、主数据和元数据等数据。考虑到公共服务组件的独立性，特别是保证每个组件独立升级以后不会影响到其余的公共服务组件以及业务组件，所以须要对公共服务组件进行隔离。
图 4. 业务基础平台主要业务组件
系统管理主要包含：用户管理、功能管理、权限管理、认证管理等功能，其中须要特别注意的是实现不一样的业务组件的统一认证的问题，即实现不一样的业务组件部署在不一样的应用下（在 J2EE 环境下为 EAR 文件）的单点登陆。
主数据管理主要包含：主数据模型管理、主数据质量控制、主数据监控等功能，主要实现各个组件之间公用的基础数据的管理，须要考虑主数据在那个业务组件中进行维护的问题，不一样的主数据须要在不一样的业务组件中完成，而不是全部的主数据都在主数据管理组件完成。
流程管理主要包含：代办任务管理、流程自定义、流程引擎等功能，主要实现对代办任务的统一管理、流程的管理。流程管理主要实现流程和业务的分离，并实现办公用的灵活流程、业务用的固定流程，详见《基于 SOA 的工做流（WF）整合》的描述。
元数据的管理主要包含：元数据管理、数据质量监控等功能，主要实现技术元数据和业务元数据的管理。
业务基础平台组件接口调用方式
在实际开发应用中，性能是很重要的一个非功能性需求，特别是针对大型的应用系统，性能是决定项目成败的一个关键因素，业务基础平台的架构决对性能问题有着重大的影响。如何在实现松耦合的基础上，进一步提高性能问题（包括保证数据库事务处理），是大型应用软件的业务基础平台必需要解决的一个问题，不能仅仅是为了组件化而组件化，若是不能解决性能问题，组件化就不能在大型的应用系统中获得普遍应用，所以须要根据在实际开发过程当中碰到的不一样的场景，采用不一样的调用方式，除了组件化中提到的服务，还有要有其余的方式做为补充，即能实现松耦合，又能够保证性能，实现不一样层次的不一样调用。
实现组件化，首先要定义清晰、简单的业务组件界面，特别是业务组件和公共组件之间的界面，而后创建一个兼顾松耦合、性能的调用方式及不一样的调用方式的标准。在《 SOA 和 ROA 》描述了业务组件接口模型，除了人机交互界面（没有组件之间的调用关系），组件之间的调用关系主要有服务接口和数据接口两种。以下图所示：
图 5. 业务组件接口模型
在上述接口模型中，组件的接口是面向集成平台的，在组件化业务基础平台组件模型中，因为是基于一个统一业务基础平台，所以能够增长一个经过 API 调用的接口方式，提升调用效率和保证事务处理，同时为了进一步优化性能，服务接口能够分红重量级的 SOAP 和轻量级的 REST 两种，所以能够把组件之间的调用关系进一步分红四种（以下图所示）。在不一样的层级，从性能和耦合性两个角度，组件间能够选择不一样的调用方式， 具体采用那种调用关系主要是考虑性能、接口复杂度、耦合性等问题，不一样的业务组件，特别是不一样的厂商之间开发的组件采用基于 SOAP 的服务，同一个厂商开发的不一样组件之间经过 REST 服务进行调用或者直接采用数据接口进行调用。一个业务组件内部，业务组件和公共模块之间的调用，以及为了保证事务处理，直接经过在不一样的业务组件中内嵌模块的方式，实现 API 调用，以下图所示：
图 6. 组件化业务基础平台接口调用方式
- 基于 SOAP 的服务接口：经过 SOAP 的 Web 服务调用，适用于不一样的业务组件之间，特别是不一样厂商开发的业务组件、不一样平台的业务组件以及新建的业务组件和遗留系统之间的调用。SOAP 的服务接口有相关的标准支持，能够支持更多的平台和厂商。
- 基于 REST 的服务接口：同平台、同厂商开发的业务组件之间的调用，特别是同一个组件中界面和业务逻辑之间的调用，从而实现界面和业务逻辑分离。REST 服务是轻量级的服务调用，主要用于提升性能，简化开发。
业务组件之间于 SOAP 的 Web 服务调用或者 REST Web 服务调用，由于基于 SOAP 的 Web 服务拥有众多的标准，能够方便的实现跨平台调用，适用于不一样厂商之间的业务组件调用，同一个厂商之间的不一样组件调用能够直接经过可以提供很好性能的 REST Web 服务调用。
- 基于 API 的调用 ，业务组件内部不一样模块之间的；业务组件和基础平台的内核之间；不一样的业务组件之间须要紧密结合事务处理的调用，经过 API 调用实现，保证系统的事务处理和系统性能。
不一样的业务组件之间须要事物处理的调用，经过内嵌一个内核业务处理模块的方式进行，如库存处理相关业务，在订单模块和采购模块都须要调用，经过服务方式很难处理事物，能够将一个简化的库存模块（如 Jar 包，建议采用 OSGi 架构，WAS8 已经提供了很好的支持）直接内嵌到订单模块和采购模块，以下图“库存模块内嵌到订单和采购业务组件”所示；工做流引擎也能够采用这样的方式，详见《基于 SOA 的工做流（WF）整合》的说明。
- 基于数据接口调用：同平台、同厂商开发的业务组件，能够直接经过数据视图调用，简化接口关系，特别开发比较紧密的小组开发的组件之间调用、大数据量的数据调用。不一样的业务组件之间，纯粹的数据调用，能够直接经过数据接口方式进行调用。
图 7. 库存模块内嵌到订单和采购业务组件
界面组件和业务逻辑组件应该是能够彻底独立的，在彻底实现组件化业务基础平台中，界面组件应该是能够独立部署的，界面组件和业务逻辑组件之间经过 REST 的服务交互，详见《 SOA 和 ROA 》所描述的架构说明。业务逻辑组件能够没有任何界面，彻底独立于界面显示，实现界面和业务的分离。在 J2EE 环境中，彻底能够实现业务组件所有由 Jar 包组成，不含任何界面内容，界面组件则彻底采用 JSP 实现。
基于数据接口调详见《 SOA 和 DW 》关于共享库的描述，在实现全部的组件公用一个数据库的基础上，不一样业务组件须要肯定数据接口做为共享标准（以下图所示深蓝色部分流程、系统、主数据、业务1、业务2、···），其中有些数据是不须要在不一样的业务组件进行共享的，则属于组件内部的数据，（以下图所示淡蓝色部分流程、系统、主数据、业务1、业务2、···），对于业务基础平台所包含的业务组件流程、系统、主数据也采用这样的方式，能够保证业务基础平台向下兼容的进行独立升级，而不会影响到其余的业务组件。
图 8. 数据接口实现思路
内部服务总线能够不一样于当前商业 ESB，采用比较复杂的服务总线产品，内部服务总线为了提升性能，能够采用简化处理，仅仅实现服务路由的功能，甚至仅仅实现一个服务注册管理便可。简化处理主要是解决当前 ESB 所遇到的性能问题，若是没有服务动态变化的需求，能够不考虑服务编排的问题。
业务基础平台组件版本
为了保证业务组件的灵活的扩展，还有一个很重要的因素，就是版本的兼容，要实现以上不一样层次的接口调用的向下兼容，包含服务接口、API 接口、数据接口，即升级以后的应该和老版本能够兼容。特别是数据库接口，必须实现向下兼容，否则没法实现一体化数据库，形成升级困难。数据接口并不是是全部的数据模型，主要是针对核心对象模型创建的对象基本关系模型，关于基础对象模型的创建，能够参见《基于面向对象（OO）的数据库设计模式探讨 一、2 》所描述“对象关系模型”建模的思路，创建更加稳定的数据模型，保证数据接口的稳定。后续文章会进一步的描述关于创建通用数据模型的思路。
实现了四个层面的接口向下兼容的，组件就能够独立升而不会相互影响，保证不一样业务组件的版本兼容，对于一个业务组件内部，不一样的模块之间，须要保证版本一致，如业务基础平台的内核，须要跟业务组件的版本保持一致。保证一个和业务组件自己的版本兼容，不一样的业务组件之间能够版本不一样，可是数据结构要兼容。
图 9. 不一样版本的业务基础平台整合
业务基础平台和集成平台
经过以上分析能够看到，组件化业务基础平台和集成平台有所不一样，基于一个业务基础平台构建一体化系统有着诸多的限制，和集成平台相比组件化业务基础平台须要更多的标准（如 API、数据接口等），限制也更加严格，尤为是针对不一样的厂商，同时适应这些标准比较困难，所以更适合用于同一个厂商内部的不一样业务组件之间的一体化。不一样厂商的系统或者业务组件，遗留系统，则须要经过集成平台进行集成，来搭建一体化系统。经过集成平台，采用通用的标准，对系统进行简单的改造就能够实现集成。
为了使组件化业务基础平台具备更加普遍的应用，能够进一步完善，实现对跨数据库的管理，用于解决超大型的应用对性能的要求，业务数据能够分别部署在多台机器中，数据库有多个实例，分散数据库的压力。同时能够支持在遵循全部相关标准的基础上其余厂商的业务组件，若是实现多个厂商基于一个基础业务平台开发，须要其余的厂商的紧密配合。以下图所示：
图 10. 不一样厂商的组件经过集成平台进行整合
注：若是部署两个数据库，考虑到性能问题，须要考虑将公共组件的数据复制一份到独立部署的数据库中，特别是主数据、权限数据等，跟业务紧密相关，具体实现方式不在本文探讨的课题。
总结
相比传统的业务基础平台，组件化业务基础平台可以实现业务基础平台组件之间以及业务组件之间的松耦合，能够实现：
- 由于业务基础平台内核分离出来，业务基础平台能够独立升级，不会影响到业务组件运行和开发，这样保证了资产的复用，不至于业务基础平台升级后，业务组件也必须跟着升级，减小没必要要的重复开发。
- 每一个业务组件能够独立升级，不会影响其余的业务组件，基于松耦合的组件化开发，不一样的业务组件之间经过标准的接口调用，接口是标准的，不须要对全部的业务组件进行升级。
- 业务基础平台能够独立部署，独立部署以后，能够整合其余厂商基于开放标准开发的业务组件，从而实现企业级的集成平台（须要数据集成和应用集成平台支持）。
参考资料
学习
- 面向服务体系架构（SOA）和数据仓库（DW）的思考： 本文将围绕 SOA 和 DW 相结合的思路，基于 IBM 的产品，规划统一的数据库，搭建企业级的技术架构。
- 面向服务体系架构（SOA）和业务组件（BC）的思考： 在基于面向服务体系架构（SOA）中，“组件化”是一个很重要的概念，如何进行“组件化”开发是搭建企业级业务基础平台时须要考虑的一个重要课题，本文通 过创建业务组件（BC）接口模型及内部结构模型，提供了一个在新开发系统环境下基于 Web 服务和 OSGi 标准的组件化开发模型。
- 基于 SOA 的工做流（WF）整合：当前基于 BPLE 的业务流程管理（BPM）以及基于 XPDL 的工做流（WF）都有成熟的理论和相应的产品支持，特别是在国内，工做流（WF）的应用十分普遍。本文从流程入手，经过创建松偶合的工做流组件，将业务流程管理和工做流结合起来，搭建企业级的跨系统的工做流整合平台。
- 基于面向服务体系架构（SOA）和面向资源体系架构（ROA）的业务组件模型： 当前 IT 技术迅猛发展，SOA、Web2.0、3G、三网融合等正逐步成为主流，如何整合 PC、手机、电视、特有设备等各类终端，综合利用 Flex、JSP、HTML、ASP.NET 等多种客户端技术成为你们关注的问题。本文以 J2EE 做为服务器端，综合当前各类流行的客户端技术，以 Web 服务和 REST 架构构建可复用分层组件模型。
- 基于面向对象（OO）的数据库设计模式探讨（1）：面向对象（OO）和三范式（3NF）都是成熟的设计方法，本文基于面向对象设计思想和三范式数据库设计方法，提出一种实体对象分层建模的思路，其目的是设计简单明了、标准化的数据库结构，同时可以更好的支持模型驱动模型（MDA）的代码自动生成和代码复用，减小代码编写工做量。
- 基于面向对象（OO）的数据库设计模式探讨（2）：如今大型的管理系统有几千甚至上万张表，但几乎没有谁能搞清楚全部的数据结构，如何创建清晰明了的数据结构？如何让其余人对数据结构更加容易理解，本文以 “基于面向对象（OO）的数据库设计模式探讨（1）”为基础进一步对汇总表进行分析，经过创建指标矩阵模型，“模式”化数据库建模，创建清晰可读的汇总数据模型。
- WebSphere Application Server 专题：了解更多关于 WebSphere Application Server 的知识
- IBM developerWorks 中国 WebSphere 专区：为使用 WebSphere 产品的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库，包含 2000 多份技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。