引言

　　软件构件共生于软件复用。早于1968年，在北大西洋公约组织（NATO）软件工程会议上就提出了软件复用的概念，后来还为此制定了一整套软件复用的指导性标准，其中包含了利用标准构件实现软件复用的基本思路。

　　生产标准软件零部件，从而组装成软件的设想受到业界的广泛关注，但各个发展历史时期，人们对其认识却不尽相同。

　　20世纪70~80年代，复用技术主要停留在对程序代码片段的复用，这一时期软件生产主要考虑如何充分利用已有的源代码、子程序库和类库来提高软件开发效率。

　　20世纪90年代，虽然面向对象技术促进了软件重用，但是只实现了类和类继承的重用。在整个系统和类之间还存在很大的缺口。为填补这个缺口，人们曾想了许多方法，如系统体系结构、框架、设计模式等。

　　自从构件出现以来，软件的重用才得到了根本改变。基于构件软件开发实现了分析、设计、类等多层次上的重用。SCA则是构件技术阶段的产物和成果，是创建SOA解决方案的基础性构件技术。

　　相关技术

　　SCA概述

　　SOA的本质特性在于可以通过组合新创建的或已有的服务来创建崭新的应用服务，而这些 组成崭新服务的原子服务可以由不同的技术来开发。SCA（Service Component Architecture），服务构件架构，它定义了一个简化的基于服务的模型。该模型涉及服务网络的缔造、装配和部署，并且这些服务都是语言中立（语言 无关）的。

　　SCA的编程模型是高度可扩展性并且是语言中立的。SCA易于扩展：1、多样的语言实 现，包括Java, C++, BPEL, PHP, Spring等；2、多种捆绑机制，包括Webservice, JMS, EJB, JSON RPC等；3、多种运行环境，包括Tomcat, Jetty, Geronimo, OSGI等。
SCA将基础设施功能从业务领域中分离出来，以便让开发者可以将精力集中在业务逻辑上。它通过声明式的应用策略和服务质量为服务调用提供可靠性、安全性和事务性。

　　什么是应用程序？一种结论认为它是由一组在一起协同工作的软件构件集合构成。所有的这些软件组件可以 用相同的技术当然也可以由不同的技术创建。它们可以运行在同一机器的同一进程中也可以在不同的进程中，当然也可以跨越多个机器。然而应用程序要正常工作， 需要两样东西：一、有一个创建构件的方式；二、有一个描述这些构件如何交互工作的机制。

　　SCA就定义了这么一套通用的解决方案。SCA起先是由一组开发厂商（包括BEA、IBM、Oracle、SAP等）创建的，现在归OASIS 所有。SCA规范给出了如何创建构件和如何将这些构件装配成一个完整的应用程序的定义。SCA应用程序中的构件可以由java或其它语言开发，也可以使用 其它技术，如BPEL或Spring框架技术。不管采用何种构件开发技术，SCA都定义了一套通用装配机制来说明这些构件是如何组装成应用程序的。

　　SOA概述

　　SOA（Service-Oriented Architecture）在新一代的架构理念因为其先进性站到了技术的前沿，是各大技术厂商紧跟的开发方式。当然同时也因为其先进性，使得其成为本世纪最为模糊的概念。个人都有自己的理解，使得 SOA在 很大程度上给人的感觉是可以听得见，却摸不着的“神秘技术”。这里很难给SOA下一个确切的定义。概略来说，SOA是一种架构设计的风格。Service 是其设计的核心单元；Service具备良好设计的接口；Service是可重用的。SOA不是技术，而是一种设计的思想，是为了使IT更好的支持商业运 营的模式，是一种文化。SOA的目标是要促进企业IT能力与业务目标的配合与协调，提供一种机动的IT基础设施，能快捷地根据业务需求变化而进行重新配 置，实现业务敏捷性。

　　任何一种技术的出现，其实都是对开发内容进行相关分类和归类，以便减少代码冗余，增加代码复用的机会。所以我们在做面向服务的分析与设计工作时，也应该做相应的分层归类工作。如下图所示：

　　图1 SOA层次图

　　图中给出了三个高层抽象层，我们的关注点应该在服务接口层，需要继续细分该层。此层分为服务编排层、业务服务层和应用服务层。

　　通过这个比较粗略的分层，可以看出各个服务层有了上下关系和归类条件。具体就是：应 用服务层归入一些公共的、与解决方案无关的工具服务，比如负载均衡服务、或者是专门用于向员工发送短信息的服务（它会被多处服务所调用）等。业务服务层则 放入一些有业务含义的原子性业务服务。所谓原子性业务服务就是不可再分解的业务服务，其中的分析建模技术包括“按业务实体进行分析和建模”和“按特定任务 进行分析和建模”的两种方式。一般来说“按业务实体进行分析和建模”比“按特定任务进行分析和建模”方式使得服务的复用机会更多些，毕竟“按特定任务进行 分析和建模”的方式得到的服务自然是满足特定任务的大的子流程，含有了业务流程，其实业务服务层如果严格来说只能包含业务实体，而不应该包含业务流程，因 为业务流程将在编排服务层里进行归类。

　　这里自然有个难点，就是我们做纯粹的面向服务分析时，是要求自顶向下分解，而要求实现SOA承 诺的服务可复用性是核心，必须保证分解出来的大部分服务要有机会复用，而我们知道原子性服务的复用性机会自然更大，然后才可以随着需求的变更来组合现有的 原子性服务来实现企业业务敏捷性。这种自顶向下分析，自下向上复用的现状几乎把我们搞糊涂了，所以将服务接口层细分为更为具体的三层意义重大，否则业务流 程与业务逻辑单元都揉在一块，自然难以提高复用率。

　　SCA在SOA架构中担当的角色

　　上述已经粗略地谈到了面向服务的分析设计，那么与SCA有什么关系？SOA分析设计的目标就是要实现跨应用的服务复用，而应该将服务设计成何种粒度大小一直是架构师与设计师考虑得最多的问题，SCA为不同粒度的服务定义，为后续的服务复用与组装提供了条件，自然贯穿于SOA的分析设计阶段。如下图所示：
 
　　图2 SCA component示意图

　　SCA中的composite与component是核心概念，具体可以说component是可以设计为原子性服务的载体，而利用composite来做组合性服务的载体，来复用底层component的服务功能。同时SCA认为粗粒度的流程服务也可以用来作为基石来组合出其它的component与composite，所以BPEL也是component的一种实现方式。如下图所示：

　　图 3 包容component的composite示意图

　　图4 递归包容的composite示意图

　　SCA从不同的粒度复用方面提供的益处得归因于它的递归复用模式，这也与面向服务的分析设计方式有一定的映射，便于自顶向下或自下而上的分析设计工作。除了在分析设计阶段的映射外，SCA在实现编码阶段做的工作则是统一了各种不同语言或运行时环境（如Spring框架）实现的规范。

　　在分布式环境中，构件不能完全自治，只能相对自治，必然涉及到构件间通讯的方式。Service（服 务）和reference（引用）用于构件通讯。通过设计，构件根本不需清楚通讯是怎么进行的。这就是绑定所做的工作。为了证明绑定为什么如此有用，我们 来考虑应用程序如何在Java EE5和J2EE的前代技术中是怎么使用不同协议的。如下图6所示，每个协议都由不同的技术提供，所以每个协议都有自己的应用编程接口（API）。比如， 使用基于HTTP协议的SOAP，就意味着是建立在JAX-WS或J2EE 1.4里的JAX-RPC，当使用队列消息协议就要求用JMS（Java Message Service）。这就强制要求开发者去学习不同的API，使用完全不同的编程模型，使用不同的协议。这也将通讯的代码混杂在业务逻辑中，加重了开发者的 负担。
      
　　图5 应用应对复杂的通讯API

　　SCA提供了简单的编程环境。比起用不同的API将不同的协议封装进不同的技术，SCA允许每个远程服务和每个引用都利用绑定来指定它所支持的协议。就应用的编程模型看来，并不关心所用的协议，如下图：

　　图6  统一的绑定机制

　　例如，想通过SOAP协议来访问，SCA服务可以使用Web Services绑定，而想通过队列消息队列协议则使用JMS绑定。同样地，EJB的会话Bean绑定允许使用IIOP（Internet Inter-ORB Protocol）协议来访问会话Bean。每个SCA运行时还允许提供SCA绑定。

　　除了在编码方面解脱开发人员，SCA同时利用现阶段比较优秀的IOC（控制反转），DI（依赖注入）原则来管理服务之间的引用关系，最大程度地支持面向服务开发模式中对服务的测试，当然也便于服务功能复用，利于服务功能的相对自治性设计。

　　综观前期软件开发模式，不难看出，SOA技术能够如此火暴，都是因为一个关键的因素， 就是此架构思路完全颠覆了以前的开发方式，以前人们开发大多是从功能角度思考问题，将很多错综复杂的要素都捆绑在一起。用汽车行业的“福特模式”比喻的 话，犹如作坊式制作汽车，所有的零件都由自我产出，装配形式没有形成标准，必然导致软件生产率和复用率低下。而SOA思想相当于软件行业的“福特革命”， 将各个阶层开发者的任务划分清晰，有服务开发者、服务装配者、应用部署者以及管理员，并有了明确的标准（大家都是靠service联系在一起）。既然是 “福特模式”就要求有基础设施，汽车行业的基础设施是专业的流水线设备，软件行业的流水线标准则由SCA规范给出。可见，如果说SOA思想是软件行业的 “福特思想”，那么SCA规范则当之无愧地成为其流水线标准，因为没有流水线的“福特模式”是无法成功的，SCA规范成为决定SOA成败的关键。

　　结束语

　　SCA是创建SOA解决方案的基础性构件技术，同时反作用于面向服务解决方案的需求收集、分析、设计、编码、部署、测试等多个方面，为创建优质的SOA架构体系的实现提供了必要条件。对于统一化编程模型、促进软件复用、正确导向软件工程学发展起到积极的推动作用。

　　原文出处：http://gocom.primeton.com/blog11169_19935.htm