本文探索面向服务的体系结构(SOA)和面向服务的集成(SOI)的模式领域，并研究SOA背后的一些基本概念和一些在创建可靠而灵活的SOA的过程中可以做出的主要体系结构决策。作者讨论了与服务组合概念相关的体系结构决策，在设计服务组合时，可以通过使用服务来帮助实现灵活性。

　　引言

　　一种探索面向服务的体系结构(SOA)的价值的方法是如何给价值等式的业务和IT端提供足够的灵活性。当一组可组合的业务流程元素被定义为业务的主要功能时，就创造了业务价值。然后，可以将这些业务元素组合成流程来创建业务模型，从而得到灵活的IT基础结构（其中包含支持这些特定流程元素的服务）更为有效的支持。

　　了解灵活性的另一个方法是对将来的可扩展性进行评估。这是通过在企业体系结构中引入服务层来实现的。可以通过一组松散耦合的服务接口来协作实现业务目标，从而使用SOA对打包的应用程序和现有系统进行集成。因而，与软件包和应用程序的点到点集成相比，打包的应用程序能以更灵活的方式进行组合和匹配；它们通过实现企业服务模型（其中定义了一组服务）要求的功能来实现SOA的一致性。

　　SOA的这种灵活性是模式（即策略模式）的再现。在此模式中，服务用于将接口与其实现分离开来，通过使用远程服务策略，实现将无需绑定到分布式系统体系结构内的通信协议上。本文将介绍的另一个方面是David Parnas于1972年在标题为“On the Criteria To Be Used in Decomposing Systems Into Modules”的文章（请参阅参考资料部分）中提到的应用程序，它将人们引入了SOA中的服务世界。

　　在这篇开创性的文章中，Parnas描述了用于将大型复杂计算机应用程序划分为一系列组件或模块的标准，这些组件或模块可以进行互连，以形成满足系统的基本功能要求的网络。虽然经常将这篇文章作为提倡信息隐藏（这本来就是面向对象编程的前身）的内容引用，不过，实际上这篇文章远不只讨论信息隐藏技术的具体应用，而深入到了我称之为外化的技术。外化是关于封装更改的技术。外化的相关标准和技术可以在面向变化的分析（Variation-Oriented Anlaysis，VOA——请参阅参考资料）中找到。面向变化的分析和设计（Variation-Oriented Analysis and Design，VOAD）指出，用于驱动系统功能及其非功能性需求的规范的需求基础结构不仅依赖于一组公共组件（或支持应用程序功能的组件集），而且更重要的是，依赖于结构中的变化如何执行其功能。这是除了作为驱动应用程序的要求之外的其他用途——这些结构中的变化和行为可以看作业务意图驱动的功能的基础主题中的变化。

　　面向变化的分析和设计

　　在VOAD中，如果有必要，可以将应用程序中变化比较频繁的元素从功能更稳定且存在时间更长的部分中分离出来。可以将这些“更改类型”视为集中于应用程序以及体系结构内的三种基本元素。这三种基本元素包括：

　　·用于驱动应用程序的策略和业务规则（用于处理白金客户透支的规则）
　　·应用程序流逐个通过各个控制点以引导应用程序的执行或应用程序流的过程，其方法通常是在流的每个关键点（处理白金客户的借贷）针对相关功能调用服务
　　·类型层次结构，业务中各种类型的元素通过类型层次结构彼此关联（客户类型包含白金客户、金卡客户和银卡客户）。

　　实际上，推动采用Web服务和SOA的因素是其可以提供的灵活性。这种灵活性在许多方面都表现得非常明显。关键因素是请求调用功能的能力，这些功能现在可能由特定业务线向组织内部提供，不过同样保留以后选择备用服务提供者的权利。此新的服务提供者可以在组织内的其他位置（另一个业务线），也可以是组织的生态系统内的业务合作伙伴（请参阅本系列的第1部分，以了解如何构建服务生态系统——请参阅参考资料）或以IT功能的形式提供服务的第三方供应商。

　　很多企业非常感兴趣的是，能够保留基于一组可能更改的业务协议和需求来选择实现的权利。此灵活性可以提供并支持巨大的业务灵活性。

　　IT中的这种灵活性可以提供并支持业务角度的灵活性，它是通过将接口与实现以及实现与通信协议绑定分离的组合策略模式来实现的。该策略模式通常使用单个编程语言在单个地址空间内实现。但是，当涉及不绑定到相同的地址空间（而表现为分布式系统调用或远程过程调用）的绑定类型时，为了实现在编译时或运行时动态绑定到服务提供者的目标，将此模式称为远程服务策略或分布式策略。

　　分布式系统要求能够接入分布在不同地址空间的组件之间的基本通信协议的资源，但要求尽可能以最无缝和透明的方式接入。Web服务标准在提供支持此类基础通信以启用分布式系统调用的开放标准方面尤其成功，特别在作为构成World Wide Web的基础的高速电信网络方面更是如此。

　　服务组合和灵活性

　　为了更好地理解如何使用SOA实现灵活性，让我们了解一下通过服务组合这一概念所带来的灵活性的程度。

　　但在此之前，让我们谈谈计算、组合和协作三者之间的重要区别，我个人认为对其进行区分很有必要。计算是通过使用通用编程语言（如Java?或C#）执行的细粒度活动，通用编程语言一般包括数学计算、Boolean计算和基于这些计算的函数执行。组合语言（如Piccola）的目的在于提供少量语法来实现组件装配的目标。另一方面，协作是由流定义的（如Business Process &#101xecution Language for Web Services (BPEL4WS)或DAML-S），这可能是工作流或其他形式的有目的的组件集成行为，旨在实现协作目标（例如，支持某个业务）。其他人已经强调了为了进行此组合而对集成服务的要求。我将在下面有关组合的部分中对此进行更详细的讨论。

　　在SOA的世界中，服务无处不在（也就是说基础结构是服务，其可以组合成应用程序）。服务质量(QoS)和灵活性是使用这种体系结构样式开发的应用程序的两个最受欢迎的特征。实现业务灵活性的一种方式是借助构建为SOA且运行良好的灵活IT基础结构，总的说来，这种方式安全可靠，能够满足业务的QoS要求。SOA主要通过其三个一流的构造来提供灵活性的：服务、组件（实现服务）和流（或流程）。

　　这三个主要SOA构造均提供不同类型的灵活性。例如，从服务的角度来看，灵活性（及其“姊妹概念”重用）是通过将接口与实现及具体协议绑定分离来实现的。其中有一种特殊的组件类型，称为企业组件（请参阅参考资料），此类组件可以提供服务的实现。它们可以确保QoS。

　　随着组织（以及整个行业）通过实现SOA承诺不断成熟，应用程序将越来越多地以服务为基础进行构建，而不是以组件为基础采用硬编码方式连接而成。当服务通过某种流（流程）机制组合成一个整体时，就取得了这样的发展。协调和编排是类似的组合：松散耦合且基于标准(BPEL)。但是，早期的采用者可以创建具有较多的组件硬编码连接类型的服务组合，其中的某些服务（业务功能的松散耦合单元）与组件进行组合，以产生实际良好运行的组合。不过，与通过服务编排完成的组合相比，这种组合的灵活性要略逊一筹。这样，您可以将SOA体系结构设计看作是通向可动态重新配置(DRC)的体系结构样式的一种途径，如图1中所示。

　　图1. 随着组织内SOA应用越来越成熟而从SOA获得的价值增长
 
　　因此，在完全成熟的SOA中，每个可调用功能单元都是服务，这些服务通过编排组合在一起，从而以服务组合为基础创建应用程序。

　　而组合 就是通过装配较小（通常也同样灵活）的构建块来构建较大的结构的过程。组合常常对其服务的状态进行管理，与BPEL引擎处理其所组合的服务的方式相似。

　　但在当今的现实世界中（与想象的或在不远的将来的情况相对），您并不能总是仅从服务的松散耦合编排创建组合。在很多情况下，您必须在灵活性和QoS之间进行权衡，以便最终得到的服务、组合服务和它们组成或支持的应用程序能够良好执行，并且可以扩展。

　　让我们继续讨论在进行与这些权衡相关的决策时遇到的一些常见场景。

　　组合和可组合性

　　让我们首先提出一些相关概念并对其进行定义，从而确定一些基本原则。图2演示了组合。

　　图2. 服务组合
 
　　服务组合可以包含提供部分功能的组件，并且可以将服务和组件的功能进行聚合以满足业务流程的需要。它可以通过在松散耦合的服务之间创建松散耦合的流来完成此工作。但对于组件，由于存在硬耦合，因此服务质量依赖于最弱的链接：提供最低服务质量的服务或组件。因此，对于要求很高性能或者存在其他约束（如依赖此组件上的其他业务线）的组合（服务或组件）的这些元素，应该习惯于在组合内对其调用进行硬编码。随着工具和平台的不断成熟，或许您可以对组件进行外化，为其创建一个接口，然后将其作为固有的服务进行调用，同时享有由此带来的所有灵活性。

　　让我们接下来看看基于银行示例的各种场景，我将通过这些场景指导您完成面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA——请参阅参考资料）的实现阶段。这里我将重点讨论服务实现。

　　服务实现决策

　　我经常听到我的客户问的一个问题是：“我是应该将一个特定的功能作为服务公开（灵活），还是应该将其作为对现有组件的直接调用公开（紧密耦合或QoS可能更佳）？”让我们看看下面的图3，以了解如何完成此工作。

　　让我们通过一个相当常见的场景来仔细了解此问题：对于每个业务线（如政府贷款、个人贷款和商业贷款），银行都具有相应的批处理、遗留系统、多个数据库和多个应用程序。

　　图3. 场景：以容易被破坏的方式共存的新系统和旧系统
 
　　对常见可组合性的描述

　　图4通过一些示例演示了各种类型的可组合性。首先，让我们了解一下这些椭圆和线条的含义。椭圆表示服务（取自UML用例图标），而线条则是控制和消息的流（同上）。每个服务均提供独特的功能部分，并且具有可通过控制该服务或为其分配的策略访问的相关服务质量。

　　图4. 组合服务
 
　　让我们对各种可组合性进行更仔细的了解：

　　替换。在这种类型中，业务干系人可以在需要该服务的功能和服务水平协议的所有流程内使用该服务。每个S(x) 都表示一个服务（功能和服务质量）。

　　图5. 替换可组合性
 
　　合并或单一访问点。在这种类型中，可以将服务作为重复使用的业务功能的单一访问点进行重用，如针对不同类型的客户的贷款服务或支付处理服务。

　　在简单的情况下，合并或单一访问点和替换或多或少有些相同。同时请注意，所有这些都是可组合性的不同说法，体现了针对以下问题的不同设计决策：给定的服务是否为“良好服务”——换句话说，我是否应建议为该业务提供资金以及应该如何决定实现此服务？这个服务的“优劣”问题可由称为Service Litmus Test的技术加以解决，我将在本系列后面的部分中对其进行讨论。

　　为该银行构造的VOA表明一些贷款处理系统的基础功能有重叠，该重叠部分就是要在这些贷款处理系统之外进行重构的公共部分。在此情况下，单个贷款处理服务就可以有效地处理与合作伙伴、客户及组织间的所有贷款处理请求。

　　这将为异构贷款处理系统提供单一访问点，现在可以采用虚拟化的方式对这些异构系统进行合并，并逐步退役，以减少维护冗余功能的成本。这种虚拟化可提供通过引入服务层实现的增量功能。服务层以单一访问点的形式提供服务，并且可以帮助逐步对服务的实现者进行物理合并。此合并是由预算可用性和技术优先级（如成本削减、易于维护和复杂性降低）驱动的。这常常通过引入服务集成器模式来实现（本系列的第1部分——同时请参阅参考资料）。

　　服务集成器模式由其他更细粒度的模式（即服务路由器(SR)组成。此模式可以与网关（根据情况不同，可能为Web服务网关或ESB网关）一起用于跟踪和将请求映射到恰当的目标服务；决定将请求发送到哪个系统。下面的图6显示了此过程。它将随后对结果进行处理，并将其操作的结果提供给服务使用者。服务路由器(SR)连接到后端系统或其他服务。SR可以直接通过其基础服务实现者（也就是实现其功能的服务组件）来访问遗留系统。只有在不可能通过服务适配器包装每个遗留系统来进行访问的情况下，才建议从基础服务组件进行直接访问。在这两种情况下，服务路由器都支持服务集成器，服务集成器现在是业务功能或流程的单一访问点。

　　图6. 服务路由器1（服务路由器）和2（以硬编码方式连接的路由器）
 
　　务必注意，如果QoS问题让您有所顾忌，恰当的体系结构决策通常可能是对这些方法进行组合。遗留系统、性能和其他QoS特性可能会阻碍使用最优的访问机制：不管是纯服务、硬编码连接或混合方法。

　　混合服务路由器（用于贷款流程3）的一部分连接是硬编码连接（由于遗留约束），而其他部分则支持通过SOA中的服务灵活调用。对于打包应用程序的访问通常都是这样。

　　该混合路由器方法的结果之一是，您现在可能无法像对待实际作为Web服务实现的服务一样方便而灵活地重新组合贷款流程3。

　　重新组合或上下文更改。业务干系人可以建议重新组合服务，并在其他业务或应用程序中对其进行重用，以满足新的业务目标和支持对业务流程的新更改。

　　图7. 重新组合或上下文更改
 
　　自包含。在这种情况下，体系结构决策是围绕此问题进行的：尽管服务可能在运行时与其他服务协作执行业务流程，它是否可以独立部署以满足业务目标？
　
　　服务之间没有隐式的依赖关系，所有的依赖关系都是可替换的或自包含的。

　　图8. 自包含
 
　　如果我公开的服务依赖于某个组件，而此组件本身又依赖于数据库和批处理遗留系统，则该服务将会保留这些依赖关系。这将最终帮助提高可维护性和服务质量，并帮助避免重新组合此服务。事实上，在通常情况下最好将此服务的可见性范围隐藏在服务路由器之后，这样在遗留或独立服务供应商（Independent Service Vendor，ISV）软件包被替换后，服务的接口和使用服务（如贷款流程1）组合而成的应用程序就不需要进行大幅度的更改（如果确实需要更改）。

　　业务原子性。服务是否是业务流程中的单个步骤的软件封装？如果您已经完成了流程分解，并根据使用相关技术（如面向服务的建模和体系结构）进行的以业务为中心的分析来选择服务，则答案为“是”。可以在图9中看到这一过程。

　　图9. 流程分解
 
　　可组合性的概念

　　图10引入了一个简单的概念。我发现这个概念在描述体系结构和关于在SOA内耦合服务和组件的实现决策方面非常有帮助。块关系图经常与更正式的概念（如UML）一起使用，以促进技术社区和非技术社区之间以及干系人之间的理解和沟通；当每个关系图都考虑了有关耦合的决策时，就达到了此目的。

　　图10. 内部编排和外部依赖类型
 
　　在图10中，您可以看到Service C到Component C具有松散耦合的实现连接；Service B具有到Component B的紧密耦合连接。

　　可重新配置性

　　运行时和动态可重新配置表现为，基础软件体系结构有能力快速响应和动态更改组件和服务的功能以及它们之间的相互连接来应对某个问题。然后，它们可以重新配置必要的操作方面（也称为非功能方面）来保持QoS和服务水平协议。

　　性能、安全和互操作性的实际考虑使得这些模型目前难于实现，不过这些领域的Web服务标准的发展和研究（如面向语法的对象设计——Grammar-Oriented Object Design，GOOD——请参阅参考资料）有望缓解其中的很多问题。

　　上述特征已经在硬件相关的系统中广泛地研究和实现了若干年。我们希望将此功能扩展到软件系统和体系结构中。为了进行此工作，我们不能直接从硬件领域借用关系图；除了常见的（错误）概念之外，软件组件和服务并不能与构建模块完美地适应；软件组件和服务更像身体中的器官，它们是更小的组件的聚合体，在一定的上下文中提供独特的功能和目标。它们也对其功能和操作能力的更改具有一定的适应能力。

　　因此，软件服务和组件的可重新配置性是实现最大IT灵活性因而实现业务灵活性的关键成功因素。您可以利用Web服务标准和通过一些组合方法和技术应用创新方法（如GOOD）来实现这一目标。

　　关于作者

　　Ali Arsanjani博士是一位高级技术人员，担任IBM Global Services的SOA and Web Services Center of Excellence的首席架构师。他具有21年的IT从业经验，参与过很多大型系统的分布式软件体系结构的设计和交付工作。他的研究兴趣和写作领域包括软件设计模式、软件体系结构、基于组件和面向服务的体系结构，以及面向语法的对象设计。他专长于构建可重新动态配置的软件系统。您可以通过arsanjan@us.ibm.com与他联系。