IBM面向服务的体系架构和业务组件(BC)的思考

《IBM面向服务的体系架构和业务组件(BC)的思考》由会员分享，可在线阅读，更多相关《IBM面向服务的体系架构和业务组件(BC)的思考（10页珍藏版）》请在金锄头文库上搜索。

1、面向服务的体系架构（SOA）和业务组件（BC）的思考肖建国,IT咨询顾问，浪潮软件简介：在基于面向服务体系架构（SOA）中，“组件化”是一个很重要的概念， 如何进行“组件化”开发是搭建企业级业务基础平台时需要考虑的一个重要课题， 本文通过建立业务组件（BC）接口模型及内部结构模型，提供了一个在新开发系 统环境下基于 Web 服务和 OSGi 标准的组件化开发模型。什么是业务组件（BC）组件化、模块化是软件开发中一个很重要的概念，基于面向服务体系架构Service Oriented Architecture， SOA）下，如何实现组件化，有各种实现方 式，下面通过对各种组件概念的对比，从技术角度

2、提出业务组件（Business Component, BC）定义，并结合对总线模式的分析，给出企业服务总线和类总线 的实现方案。企业架构（EA）关于企业架构（Enterprise Architecture， EA）和面向服务体系架构（SOA）在面向服务体系架构（SOA）和数据仓库（DW）的思考（以下简称SOA和DW） 一文中做了介绍，企业架构包含企业战略、业务架构、IT战略、IT架构四个部 分， IT 架构如下图 IT 架构模型所示，包含数据架构、应用架构、技术架构和 治理架构等四个方面，其中技术架构包含集成平台、公共服务平台、基础平台（软 件和硬件、网络）和安全平台等， SOA 和 DW 着

3、重对如何构建数据架构特 别是数据存储做了详细的阐述，本文基于 SOA 和 DW 进一步对如何搭建 SOA 体系进行研究，将着重描述如何基于可扩展的、灵活的企业级的集成平台、公共 服务平台进行组件化开发。集成乎合:公共服务平台1门户，应用、雄1:J 工鬆 主咙-勰誓蒙專治理架构技术架构应用架构数据架构图 1. IT 架构模型全台 安乎芒右平含中间件、操作系麻 主鹉 存圖 岡络、扭房业务组件（BC） 当前，提到组件（Component）的有很多概念，比如分布式组件DCOM、J2EE、CORBA 等，IBM的业务组件模型（Componen t Business Model， CBM）， SOA中的服

4、务 组件架构（Service Component Architecture， SCA）等。本文提到的业务组件 （Business Component, BC）定义为一个可以独立运行的系统或者模块，业务组 件的目的是以方便业务组件独立升级和减少不必要的组件之间的交互为基本原 则，通过一定程度的分离，实现SOA和DW中提到的重用（Sof tWARe Reuse）。如果业务组件是共用的，是其它业务组件需要重用的，称之为公共业务组件（简 称公共组件），所有的公共组件组成企业架构中技术架构的公共服务平台，比如 主数据管理、系统管理、统一认证管理、通用报表等，这些都是公共组件。组件业务模型（ CBM）组件

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

6、基础。本文所提到的业务组件在粒度上基本对应着组件业务模型（CBM）的粒度，但是 本文中的业务组件（BC）更多从技术实现角度考虑，或大于，或小于业务组件模 型（CBM）提到的业务组件概念。服务组件框架（ SCA） 服务组件框架（Service Component Architecture, SCA）由 BEA、IBM、Oracle 等中间件厂商联合制定的一套符合SOA思想的规范。服务组件框架（SCA）提供 了一套可构建基于面向服务的应用系统的编程模型，它的核心概念是服务及其相 关实现。 SCA 组件组成程序集，程序集是服务级的应用程序，它是服务的集合， 这些服务被连接在一起，并进行了正确的配置。

7、在 SCA 标准下， SCA 由域（Domain）、组合构件（Composite）、构件（Component）三个级别组成，构件 对应着细粒度的 Web 服务，域对应着粗粒度的 Web 服务。 SCA 程序集运行在两 个级别：第一种情况，程序集是“大规模编程” （ProgrammingintheLarge 或 Megaprogramming）的一组松散连接的服务组件；另一种情况，程序集是“小规 模编程”（Programming in the Small）内的一组松散连接的组件。二者的区别 在于， “大规模编程”对应着应用，“小规模编程”对应着模块，一般来说， 服务组件对应着“小规模编程”，即模

8、块的概念。本文所提到的业务组件（BC），是比SCA组件更大范围的概念，这几个概念的 颗粒度从大到小的排列顺序如下：系统（每个企业只有一个系统）、应用、业务 组件（BC）、模块、SCA组件（粗粒度服务）。总线模式（Bus）和SOA、OSGi总线（Bus）： 般指通过分时复用的方式，将信息以一个或多个源部件传送到 一个或多个目的部件的一组传输线。基于总线模式的有很多应用，在微机的技术 中，有三种总线，地址总线Address Bus，数据总线Data Bus，控制总线Control Bus。在通信架构下，交换机也是一种总线，在SOA中，总线一般指企业服务总 线（Enterprise Service

9、Bus， ESB），企业服务总线可以连接所有协议的各种 接口，但是最理想的是基于 XML 的 Web 服务标准。OSGi OpenServiceGatewayInitiative， 1999 年 OSGi 联盟成立，旨在 建立一个开放的服务规范，为通过网络向设备提供服务建立开放的标准，是开放 业务网关的发起者。 OSGi 是一个 Java 框架，该框架能装载以 Bundle 为单位 的资源。 Bundle 能提供服务或响应处理请求，而他们之间的依赖都是被管理起 来的，正如一个 Bundle 能从容器中获得它所需要的管理。每个 Bundle 都可以 有它自己的内部类路径，所以它可以作为独立的服务

10、单元。所有的这些符合 OSGi 规范的 Bundle 理论上都可以安装在任何符合 OSGi 规范的容器中。 OSGi 具有 可动态改变系统行为，热插拔的插件体系结构，高可复用性，高效性等等。在 J2EE 环境下，基于总线（Bus）模式的思考，可以进一步推广到Java Class，基于OSGi 的微内核，建立一个类总线（Java Class Bus，JCB）。通过以上概念的分析，我们可以看到，本文提到的业务组件（BC），是指具体的 一个软件实现，业务组件（BC）跟IBM的业务组件模型（CBM）中提到的业务组 件有一定的对应关系，但是一般来说，业务组件（BC）可能包含CBM中的多个 业务组件或者一

11、个CBM的业务组件封装成多个业务组件（BC）。另外CBM更多 的是从业务角度来考虑，是业务上的概念，业务组件（BC）则是从技术实现角度 考虑。服务组件框架（SCA）定义的粒度和业务组件（BC）相比来说，SCA划分 的还是很细，业务组件（BC）是更粗粒度的一个软件实现概念。业务组件（BC）模型 根据业务组件的作用不同，可以将业务组件分成公共业务组件和普通业务组件， 公共业务组件包含统一用户组件、统一认证组件、门户组件、流程组件、报表组 件、BI组件、GIS组件等，这些组件的共同特点是多个业务组件或者系统会用 到这个业务组件。组件的粒度和对外接口设计决定了组件的可复用和松耦合（ Loose Cou

12、pling ）特 性。粒度过大，灵活性小，难以实现复用，粒度过小，管理成本提升，使得复用 性也很难改善；接口和实现的分离 , 保证各项业务组件在提供标准化的服务接 口的前提下可以替换各种可选的实现 , 而不会影响系统其它部分的实现，接口 设计不当，对于组件的耦合会有很大的影响。业务组件的粒度业务组件的粒度根据需要可以不同，既可能是独立运行的子系统 , 也可能是程 序模块。业务组件是提高应用系统灵活性和复用的重要基础。业务组件粒度太小， 造成组件数量多，组件之间交互多，管理困难，性能低下；业务组件粒度粗，功 能复杂，功能之间关系紧密，升级困难（可以独立升级往往会作为确定一个业务 组件范围的重要因

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

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

15、能造成外部服务请求者难 于支持不断变化的服务提供者所暴露的细粒度服务接口。而粗粒度服务接口保证 了服务请求者将以一致的方式使用系统中所暴露出的服务。业务组件的松耦合设计 耦合性(Coupling)是程序结构中各个模块之间相互关联的度量，它取决于各个 模块之间接口的复杂程度、调用模块的方式以及哪些信息通过接口。耦合性由松 到紧可以分成七种：非直接耦合(Nondirect Coupling)、数据耦合(Date Coupling)、标记耦合(Stamp Coupling)、控制耦合(Control Coupling)、 外部耦合(External Coupling)、公共耦合(Common Cou

16、pling)、内容耦合(CONTENT COUPLING)。非直接耦合是指两个模块之间没有直接关系，这种耦合的模块独立 性最强。数据耦合，彼此之间是通过数据参数 ( 不是控制参数、公共数据结构 或外部变量 ) 来交换输入、输出信息的，模块之间的独立性比较强。标记耦合 是指一组模块通过参数表传递记录信息，就是标记耦合，这要求这些模块都必须 清楚该记录的结构，并按结构要求对此记录进行操作，应尽量避免这种耦合，它 使在数据结构上的操作复杂化了。在业务组件设计模型中业务组件之间尽量实现 非直接耦合(总线模式，推荐使用)和数据耦合(共享库模式，控制使用)，通 过定义清晰的 Web 服务进行交互，业务组件内部的模块之间可以通过标准化的 Web 服务或者数据表来进行共享。J2EE架构下业务组件(BC)实现业务组件松耦合设计一OSGI业务组件以 Web 服务的方式提供接口，通过企业服