组件

参考：

1. 组件（基本组件、业务组件...）

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

3. 面向服务的体系架构（SOA）和业务组件（BC）的思考

UI组件

1. UI组件可以实现拖放式编程、快速的属性处理

2. UI组件开发者应该掌握的三项主要内容是：属性、事件和方法。

3. 常见的有：表格控件、报表控件、用户界面控件等

业务组件

业务组件是一系列不可分割的业务活动，是构建专业化企业的功能模块。业务组件的优势在很大程度上来源于其具备两个相关但截然不同的特性：首先，组件之间通过松散耦合方式进行链接，具备灵活、响应快、适用能力强的特点；其次，组件内各活动的凝聚力强，可对外提供效率高、质量好的服务。

将业务活动归类为组件时需要考虑的因素有： 　 
● 相似的业务活动 　 
● 使用类似的数据 　 
● 具有通用的处理流程 　 
● 通用的业务目标 　 
● 是密切联系的组织单元 　通过组件共享，企业可以显著地改善运营效率并提高差异化竞争优势。

企业应用下的业务组件

1. 基于应用的部署导致了三个隔离问题：交互（界面）隔离、程序访问隔离和数据隔离（请注意这三个问题分别对应了企业应用业务组件的三个技术内容）。交互隔离导致了企业用户必须访问不同界面，代码访问隔离导致了点对点的集成以及诸如性能、事务和异步处理等各种非功能性问题，而数据隔离导致了数据有效性、一致性等等问题。

2. 组件容器完全使用现有的中间件技术，并加上一些新的内容，包括如下： 
* 组件框架，识别组件，以及组件（文件）结构和各个技术工件。 
* 技术框架，提供业务无关的技术支持，以便于技术的平稳升级切换。 
* 运行容器，采用现有中间件技术，包括Tomcat、应用服务器和数据库服务等； 
* 工具，包括打包以及部署工具等。

3. 三种不同技术工件（即三个隔离问题）呈现不同特点，如下

* UI资源（交互隔离问题），依赖是指UI资源的嵌入、引用和替换，联动是指UI资源的新增。

* 应用程序（程序访问隔离），依赖是指API/模型依赖，联动是指消息（传统消息和JMS消息）以及SPI实现。其中，无论是依赖或者联动都涉及到相应的非功能性需求，包括：异步、事务控制和服务时限等。

* 数据库资源（数据隔离），依赖是指外键关联和级联操作，无明显的联动关系。

组件框架

1. 只有实实在在的组件框架才能组件化开发真正落地的（如同OSGi框架那样）：我们需要一个类似于Equinox的界面扩展框架来支持UI资源的依赖和联动；我们需要一个集成框架来支持应用程序的依赖和联动，解决所面临的种种问题（业务不匹配、SPI集成以及各种非功能性需求）；我们需要一个打包部署工具（类似spring DM）提供部署UI资源、应用程序和数据库定义资源（Spring DM提供了基于Web资源的部署能力）。

业务基础平台

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

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

一般业务基础平台都包含两个部分，运行环境和开发环境，开发环境主要用于解决如何更加快速的开发，也是业务基础平台的核心内容，本文主要介绍业务基础平台的运行环境架构，关于开发环境将不在进一步论述。

业务组件和公共组件

业务组件（Business Component，BC）是一个可以独立运行的系统或者模块，业务组件的目的是以方便业务组件独立升级和减少不必要的组件之间的交互为基本原则，通过一定程度的分离，实现软件重用（Software Reuse）。如果业务组件是共用的，是其它业务组件需要重用的，称之为公共业务组件（简称公共组件），所有的公共组件组成企业架构中技术架构的公共服务平台，比如主数据管理、系统管理、统一认证管理、通用报表等，这些都是公共组件。详见之前的文章《面向服务体系架构（SOA）和业务组件（BC）的思考》（以下简称 SOA 和 BC）关于业务组件和公共组件的说明。

什么是业务组件（BC）

组件化、模块化是软件开发中一个很重要的概念，基于面向服务体系架构（Service Oriented Architecture，SOA）下，如何实现组件化，有各种实现方式，下面通过对各种组件概念的对比，从技术角度提出业务组件（Business Component，BC）定义，并结合对总线模式的分析，给出企业服务总线和类总线的实现方案。

企业架构（EA）

关于企业架构（Enterprise Architecture，EA）和面向服务体系架构（SOA）在《面向服务体系架构（SOA）和数据仓库（DW）的思考》（以下简称《 SOA 和 DW 》）一文中做了介绍，企业架构包含企业战略、业务架构、IT 战略、IT 架构四个部分，IT 架构如下图 IT 架构模型所示，包含数据架构、应用架构、技术架构和治理架构等四个方面，其中技术架构包含集成平台、公共服务平台、基础平台（软件和硬件、网络）和安全平台等，《 SOA 和 DW 》着重对如何构建数据架构特别是数据存储做了详细的阐述，本文基于《 SOA 和 DW 》进一步对如何搭建 SOA 体系进行研究，将着重描述如何基于可扩展的、灵活的企业级的集成平台、公共服务平台进行组件化开发。

图 1. IT 架构模型

业务组件（BC）

当前，提到组件（Component）的有很多概念，比如分布式组件 DCOM、J2EE、CORBA 等，IBM 的业务组件模型（Component Business Model，CBM），SOA 中的服务组件架构（Service Component Architecture，SCA）等。本文提到的业务组件（Business Component，BC）定义为一个可以独立运行的系统或者模块，业务组件的目的是以方便业务组件独立升级和减少不必要的组件之间的交互为基本原则，通过一定程度的分离，实现《 SOA 和 DW 》中提到的重用（SoftWARe Reuse）。

如果业务组件是共用的，是其它业务组件需要重用的，称之为公共业务组件（简称公共组件），所有的公共组件组成企业架构中技术架构的公共服务平台，比如主数据管理、系统管理、统一认证管理、通用报表等，这些都是公共组件。

组件业务模型（CBM）

组件业务建模（Component Business Modeling，CBM）是 IBM SOA 构建的一个方法论，通过将组织活动重新分组到数量可管理的离散、模块化和可重用的业务组件中，从而确定改进和创新机会，把业务从领导，控制和执行三个方面进行模块化分析，从而有效的实现业务的有组织的提供服务的能力。CBM 的价值是提供一个可以推广的框架，用来创造顺应组织战略的可以运营的指导方向，同时 CBM 也用来按照业务和资源的优先级别和相互关联的程度来构建和顺应战略的发展方向，其中包括建立一个沟通的机制来理解整个业务发展的方向。通过 CBM 建立了 SOA 的规划的方向，为实施 SOA 奠定基础。

本文所提到的业务组件在粒度上基本对应着组件业务模型（CBM）的粒度，但是本文中的业务组件（BC）更多从技术实现角度考虑，或大于，或小于业务组件模型（CBM）提到的业务组件概念。

服务组件框架（SCA）

服务组件框架（Service Component Architecture，SCA）由 BEA、IBM、Oracle 等中间件厂商联合制定的一套符合 SOA 思想的规范。服务组件框架（SCA）提供了一套可构建基于面向服务的应用系统的编程模型，它的核心概念是服务及其相关实现。SCA 组件组成程序集，程序集是服务级的应用程序，它是服务的集合，这些服务被连接在一起，并进行了正确的配置。在 SCA 标准下，SCA 由域（Domain）、组合构件（Composite）、构件（Component）三个级别组成，构件对应着细粒度的 Web 服务，域对应着粗粒度的 Web 服务。SCA 程序集运行在两个级别：第一种情况，程序集是“大规模编程”（Programming in the Large 或 Megaprogramming）的一组松散连接的服务组件；另一种情况，程序集是“小规模编程”（Programming in the Small）内的一组松散连接的组件。二者的区别在于， “大规模编程”对应着应用，“小规模编程”对应着模块，一般来说，服务组件对应着“小规模编程”，即模块的概念。

本文所提到的业务组件（BC），是比 SCA 组件更大范围的概念，这几个概念的颗粒度从大到小的排列顺序如下：系统（每个企业只有一个系统）、应用、业务组件（BC）、模块、SCA 组件（粗粒度服务）。

总线模式（Bus）和 SOA、OSGi

总线（Bus）：一般指通过分时复用的方式，将信息以一个或多个源部件传送到一个或多个目的部件的一组传输线。基于总线模式的有很多应用，在微机的技术中，有三种总线，地址总线 Address Bus，数据总线 Data Bus，控制总线 Control Bus。在通信架构下，交换机也是一种总线，在 SOA 中，总线一般指企业服务总线（Enterprise Service Bus，ESB），企业服务总线可以连接所有协议的各种接口，但是最理想的是基于 XML 的 Web 服务标准。

OSGi —— Open Service Gateway Initiative，1999 年 OSGi 联盟成立，旨在建立一个开放的服务规范，为通过网络向设备提供服务建立开放的标准，是开放业务网关的发起者。OSGi 是一个 Java 框架，该框架能装载以 Bundle 为单位的资源。Bundle 能提供服务或响应处理请求，而他们之间的依赖都是被管理起来的，正如一个 Bundle 能从容器中获得它所需要的管理。每个 Bundle 都可以有它自己的内部类路径，所以它可以作为独立的服务单元。所有的这些符合 OSGi 规范的 Bundle 理论上都可以安装在任何符合 OSGi 规范的容器中。OSGi 具有可动态改变系统行为，热插拔的插件体系结构，高可复用性，高效性等等。在 J2EE 环境下，基于总线（Bus）模式的思考，可以进一步推广到 Java Class，基于 OSGi 的微内核，建立一个类总线（Java Class Bus，JCB）。

通过以上概念的分析，我们可以看到，本文提到的业务组件（BC），是指具体的一个软件实现，业务组件（BC）跟 IBM 的业务组件模型（CBM）中提到的业务组件有一定的对应关系，但是一般来说，业务组件（BC）可能包含 CBM 中的多个业务组件或者一个 CBM 的业务组件封装成多个业务组件（BC）。另外 CBM 更多的是从业务角度来考虑，是业务上的概念，业务组件（BC）则是从技术实现角度考虑。服务组件框架（SCA）定义的粒度和业务组件（BC）相比来说，SCA 划分的还是很细，业务组件（BC）是更粗粒度的一个软件实现概念。

回页首

业务组件（BC）模型

根据业务组件的作用不同，可以将业务组件分成公共业务组件和普通业务组件，公共业务组件包含统一用户组件、统一认证组件、门户组件、流程组件、报表组件、BI 组件、GIS 组件等，这些组件的共同特点是多个业务组件或者系统会用到这个业务组件。

组件的粒度和对外接口设计决定了组件的可复用和松耦合（Loose Coupling）特性。粒度过大，灵活性小，难以实现复用，粒度过小，管理成本提升，使得复用性也很难改善；接口和实现的分离 , 保证各项业务组件在提供标准化的服务接口的前提下可以替换各种可选的实现 , 而不会影响系统其它部分的实现，接口设计不当，对于组件的耦合会有很大的影响。

业务组件的粒度

业务组件的粒度根据需要可以不同，既可能是独立运行的子系统 , 也可能是程序模块。业务组件是提高应用系统灵活性和复用的重要基础。业务组件粒度太小，造成组件数量多，组件之间交互多，管理困难，性能低下；业务组件粒度粗，功能复杂，功能之间关系紧密，升级困难（可以独立升级往往会作为确定一个业务组件范围的重要因素），很难实现重用。因此找到一个合适的业务组件粒度是很重要的事情。

根据前文所定义的业务组件定义，我们把整个企业的所有软件称之为系统，即一个企业只有一个系统；系统下面划分成若干应用，每个应用完成一个相对独立的业务功能，比如财务管理、人力资源管理等，一般来说是一个厂商独立完成（后文还会提到，如果是基于一个业务基础平台，多个厂商可以在一个应用中）；应用下面划分成若干业务组件，业务组件是相对独立的功能，其可以进一步划分成若干模块，从而形成了系统－应用－业务组件－模块这样四个层次的模型。根据 SCA 的定义，模块下面可以进一步划分成程序集为更小的粒度。从软件复用角度来看，业务组件是独立部署的最小颗粒，模块是复用的最小颗粒。

除了业务组件需要粒度控制外，Web 服务的粒度控制也是一项十分重要的设计任务。通常来说 , 对于将暴露在整个系统外部的服务推荐使用粗粒度的接口 , 而相对较细粒度的服务接口通常用于企业和机构系统架构的内部。从技术上讲 , 粗粒度的服务接口可能是一个特定服务的完整执行 , 而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。虽然细粒度的接口能为服务请求者提供了更加细化和更多的灵活性 , 但同时也意味着引入较难控制的交互模式易变性 , 也就是说服务的交互模式可能随着不同的服务请求者而不同。如果暴露这些易于变化的服务接口给系统的外部用户 , 就可能造成外部服务请求者难于支持不断变化的服务提供者所暴露的细粒度服务接口。而粗粒度服务接口保证了服务请求者将以一致的方式使用系统中所暴露出的服务。

业务组件的松耦合设计

耦合性（Coupling）是程序结构中各个模块之间相互关联的度量，它取决于各个模块之间接口的复杂程度、调用模块的方式以及哪些信息通过接口。耦合性由松到紧可以分成七种：非直接耦合（Nondirect Coupling）、数据耦合（Date Coupling）、标记耦合（Stamp Coupling）、控制耦合（Control Coupling）、外部耦合（External Coupling）、公共耦合（Common Coupling）、内容耦合（CONTENT COUPLING）。非直接耦合是指两个模块之间没有直接关系，这种耦合的模块独立性最强。数据耦合，彼此之间是通过数据参数 ( 不是控制参数、公共数据结构或外部变量 ) 来交换输入、输出信息的，模块之间的独立性比较强。标记耦合是指一组模块通过参数表传递记录信息，就是标记耦合，这要求这些模块都必须 清楚该记录的结构，并按结构要求对此记录进行操作，应尽量避免这种耦合，它使在数据结构上的操作复杂化了。在业务组件设计模型中业务组件之间尽量实现非直接耦合（总线模式，推荐使用）和数据耦合（共享库模式，控制使用），通过定义清晰的 Web 服务进行交互，业务组件内部的模块之间可以通过标准化的 Web 服务或者数据表来进行共享。