基于 SOA 的组件化业务基础平台

业务基础平台是业务逻辑应用和基础架构平台之间的一个中间层，解决 “应用软件的业务描述和操作系统平台、软件基础架构平台之间的交互与管理问题”。操作系统平台解决了“应用软件系统与硬件之间的交互与管理问题”，软件基础架构平台解决了“应用软件系统与操作系统平台之间的交互与管理问题”，而业务基础平台则是解决了“应用软件的业务描述与操作系统平台、软件基础架构平台之间的交互与管理问题”。如下图所示：

图 1. 业务基础平台在技术架构中的位置

业务基础平台的组件化，并不是所有的内容全部组件化，有些内容是无法分离出去的，因此首先要把业务基础平台的内核分离出来，建立一个业务基础平台的微内核，微内核是跟每一个业务组件紧密相关的。然后把业务基础平台中可以分离出来的内容单独作为一个组件，即公共组件，从而实现业务组件和公共组件的分离。

1、业务基础平台主要业务组件

公共服务组件包含系统管理、流程管理、主数据管理、元数据管理等，在数据层面分别对应着系统数据、流程数据、主数据和元数据等数据。考虑到公共服务组件的独立性，特别是保证每一个组件独立升级之后不会影响到其他的公共服务组件以及业务组件，因此需要对公共服务组件进行隔离。

图 4. 业务基础平台主要业务组件

>系统管理主要包含：

用户管理、功能管理、权限管理、认证管理等功能，其中需要特别注意的是实现不同的业务组件的统一认证的问题，即实现不同的业务组件部署在不同的应用下（在 J2EE 环境下为 EAR 文件）的单点登录。

>主数据管理主要包含：

主数据模型管理、主数据质量控制、主数据监控等功能，主要实现各个组件之间公用的基础数据的管理，需要考虑主数据在那个业务组件中进行维护的问题，不同的主数据需要在不同的业务组件中完成，而不是所有的主数据都在主数据管理组件完成。

>流程管理主要包含：

代办任务管理、流程自定义、流程引擎等功能，主要实现对代办任务的统一管理、流程的管理。流程管理主要实现流程和业务的分离，并实现办公用的灵活流程、业务用的固定流程，详见《基于 SOA 的工作流（WF）整合》的描述。

>元数据的管理主要包含：

元数据管理、数据质量监控等功能，主要实现技术元数据和业务元数据的管理。

2、业务基础平台组件接口调用方式

不能仅仅是为了组件化而组件化，如果不能解决性能问题，组件化就不能在大型的应用系统中得到广泛应用，因此需要根据在实际开发过程中碰到的不同的场景，采用不同的调用方式，除了组件化中提到的服务，还有要有其他的方式作为补充，即能实现松耦合，又可以保证性能，实现不同层次的不同调用。

组件之间的调用关系主要有服务接口和数据接口两种。如下图所示：

图 5. 业务组件接口模型

在不同的层级，从性能和耦合性两个角度，组件间可以选择不同的调用方式， 具体采用那种调用关系主要是考虑性能、接口复杂度、耦合性等问题。

图 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 》关于共享库的描述，在实现所有的组件公用一个数据库的基础上，不同业务组件需要确定数据接口作为共享标准（如下图所示深蓝色部分流程、系统、主数据、业务一、业务二、···），其中有些数据是不需要在不同的业务组件进行共享的，则属于组件内部的数据，（如下图所示淡蓝色部分流程、系统、主数据、业务一、业务二、···），对于业务基础平台所包含的业务组件流程、系统、主数据也采用这样的方式，可以保证业务基础平台向下兼容的进行独立升级，而不会影响到其他的业务组件。

图 8. 数据接口实现思路

总结

相比传统的业务基础平台，组件化业务基础平台能够实现业务基础平台组件之间以及业务组件之间的松耦合，可以实现：

1. 因为业务基础平台内核分离出来，业务基础平台可以独立升级，不会影响到业务组件运行和开发，这样保证了资产的复用，不至于业务基础平台升级后，业务组件也必须跟着升级，减少不必要的重复开发。
2. 每个业务组件可以独立升级，不会影响其他的业务组件，基于松耦合的组件化开发，不同的业务组件之间通过标准的接口调用，接口是标准的，不需要对所有的业务组件进行升级。
3. 业务基础平台可以独立部署，独立部署之后，可以整合其他厂商基于开放标准开发的业务组件，从而实现企业级的集成平台（需要数据集成和应用集成平台支持）。