面向服务体系结构

面向服务的体系结构

今天，Web 服务——特指用 Web 服务描述语言（Web Services Description Language，WSDL）描述的、通过 HTTP 发送的、处理 XML 编码的 SOAP 消息的分布式服务——正得到广泛的部署。Web 服务可用在各种各样的应用程序集成环境中：从简单的（特别是防火墙后面的）数据共享到大规模的 Internet 零售和货币交易。 Web 提供了软件组件之间的互操作性，这些软件组件可以在不同的企业之间进行通信，并且可以驻留在不同的基础架构中。这解决了顾客、软件开发人员和合作伙伴所面临一个最重要的问题。HTTP 和 SOAP 提供了通信和消息的互操作性。WSDL 提供了消息的描述，以支持开发工具之间的互操作性；它凭借交换接口定义的能力来完成通信互操作性。一组基本的 Web 服务规范使顾客和软件厂商能够解决一些重要的问题。在这些规范成功的基础上，许多开发人员和公司准备解决 Web 服务方面更难的问题。Web 服务的巨大成功使开发人员想要从 Web 服务获得更多的能力。由于重要的工具和通信互操作已经成功了，所以开发人员现在期望增强互操作的功能。除了基本的消息互操作性和接口交换之外，开发人员越来越需要更高级别的应用程序服务互操作。许多商业应用程序运行在这样一种环境中（“中间件”或“操作系统”），这种环境为一些功能（比如安全性和事务处理）提供支持。 IBM、Microsoft 和业界其他一些公司常常需要使 Web 更安全、更可靠且更好地支持事务处理。另外，我们在提供这些能力的同时，还需要保持现在 Web 服务中必不可少的简单性和互操作性。

面向服务体系结构（SOA）定义

SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。从这个定义中我希望表达的前提有下面两点：

1) 软件系统架构：SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的应用场景，用来满足不同的特定需求。

2) SOA的使用范围：需求决定同时也限制功能。SOA并不是包治百病的万灵丹，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。在下面我们会详细讨论Internet的各种特点如何决定SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于Intranet环境的几个特点：

a) 大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；

b) 大量、频繁的数据传输仍然速度缓慢并且不稳定；

c) 版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。

基于上面的前提，下面就让我们一起看一下SOA的基本特征。

SOA三大基本特征

1 独立的功能实体

在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

2 大数据量低频率访问

对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA 系统推荐采用大数据量的方式一次性进行信息交换。

3 基于文本的消息传递

由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet 上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。

HTTP协议：一个典型的SOA实现

每一项新技术都是在一些旧的技术基础上发展出来的。正如XML根本思想来自于在60年代就已经出现的早期标记性语言一样，SOA虽然这两年才出现，但是它所表达的观念应该说在网络这种分布式系统结构出现不久就已经广泛应用了。例如我们最熟悉的HTTP协议就是一个非常典型的SOA架构设计。HTTP协议的工作过程简单叙述如下：

1) 客户端，通常是通过浏览器，向服务器端以文本的方式发送一个请求，索取一个Web页面；

2) 服务器端接收到这个请求之后，根据请求的内容进行处理并且返回一个符合HTML语法的文本；

3) 客户端接收到服务器端的响应文本后调用本地的程序，通常还是浏览器，把返回的HTML文本的内容展现出来。

下面来看一下HTTP协议如何满足了SOA的特点：

* 独立的功能实体：作为服务器端的Web服务器是绝对不会因为客户端的状况变化而改变的，它总是非常稳定地按照自己的内在逻辑运行，响应外部的请求，管理自己的资源和数据。这里一个非常好的例子就是Web服务器对缓存(Cache)的处理，很多Web服务器为了提高性能都或多或少的对数据进行缓存，但是缓存数据、刷新数据这些于客户端完全无关的操作完全由服务器端独立完成，完全不受客户端的影响。

* 大数据量低频率访问：对于一个HTTP请求来说，客户端与服务器之间访问的边界非常简单：就是一个请求，一个响应，没有任何其它的信息往返。无论客户端申请的网页上除了文字之外还有什么信息，对于客户端来说，它发出的请求只是简单的告诉Web服务器它所需要的网页的位置；至于为了生成这个网页，服务器端是否需要访问数据库，执行Servlet或者其它的CGI程序对客户端而言，都是完全透明的。

* 基于文本的消息传递：迄今为止兼容性最好的系统可能就是HTTP协议支撑的大部分的web应用了，我们可以在Windows平台下用IE查看互联网上一个Linux ＋Apache服务器上的由Perl脚本自动生成的网页。这里的关键就是所有内容都是以格式化的文本方式传递的，不管Perl脚本如何执行，只要它的输出是符合HTML规范的网页，就可以被客户端的浏览器解释。而由于不同的操作系统上对

于相同的HTML的解释遵循相同的规范，因此不同操作系统下仍然能够看到一致的用户界面。

我们上面基本描述了SOA作为一种软件架构有哪些特点，下面让我们一起看看Web Service与SOA的关系。

SOA与Web Service

Web Service是就现在而言最适合实现SOA的一些技术的集合，事实上最近SOA 的火爆在很大程度上归功于Web Service标准的成熟和应用的普及为广泛的实现SOA架构提供了基础。下面让我们看看Web Service中的各种协议是如何互相工作来满足SOA所需的特点的：

* 独立的功能实体：通过UDDI的目录查找，我们可以动态改变一个服务的提供方而无需影响客户端的应用程序配置。所有的访问都通过SOAP访问进行，只要WSDL接口封装良好，外界客户端是根本没有办法直接访问服务器端的数据的。

* 大数据量低频率访问：通过使用WSDL和基于文本(Literal)的SOAP请求，我们可以实现能一次性接收大量数据的接口。这里需要着重指出的是SOAP请求分文本方式和远程调用(RPC)两种方式，正如上文已经提到的，采用远程调用方式的SOAP请求并不符合这点要求。但是令人遗憾的是现有的大多数SOAP请求采用的仍然是远程调用(RPC)方式，在某些平台上，例如IBM WebSphere的早期版本，甚至没有提供文本方式的SOAP支持。

* 基于文本的消息传递：Web Service所有的通讯是通过SOAP进行的，而SOAP 是基于XML的，不同版本之间可以使用不同的DTD或者XML Schema加以辨别和区分。因此只需要我们为不同的版本提供不同的处理就可以轻松实现版本控制的目标。

SOA对于软件架构设计的影响

无论您现在的系统是否牵涉到基于Internet的业务集成，采用SOA推荐的架构都对提高您系统的扩展性有很大帮助，下面是在系统中引入SOA后需要在软件架构方面做出的改变：

* 使用基于文本方式的SOAP调用，摆脱远程调用中出现的函数参数类型等与数据无关的信息，保证所有SOAP传递的都是有意义的商业数据。依赖于Schema，而不是类定义对这些数据进行解释。

* 传统的三层Web应用将可能变成四层结构：传统意义上的商业逻辑层将被进一步划分为存放每个会话(Session)信息的客户逻辑层和与状态无关Sateless的SOA层。

下面简要地描述了面向服务的体系结构的发展。然后探讨面向组件的开发与面向服务的体系结构之间的关系，并说明如何将组件作为实现服务的基础设施。

第一部分：新方法的商业驱动力

虽然IT经理一直面临着削减成本和最大限度地利用现有技术的难题，但是与此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。

在所有这些压力之下，有两个基本的主题：异构和改变。现在，大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自多个厂商跨不同平台的产品简直就像一场噩梦。但是我们也不能单单使用一家厂商的产品，因为改变应用程序套件和支持基础设施是如此之难。

在当今IT经理面临的问题之中，改变是第二个主题。全球化和电子商务加快了改变的步伐。全球化带来了激烈的竞争，产品周期缩短了，每个公司都想赢得超过竞争对手的优势。在竞争产品和可以从Internet上获得的大量产品信息的推动下，客户要求更快速地进行改变。因而，在改进产品和服务方面展开的竞争进一步加剧了。

为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。企业必须快速地适应这种改变，否则就难以生存，更别提在这个动荡不安竞争激烈的环境中取得成功了，而 IT 基础设施必须支持企业提高适应能力。

因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态系统业务范例发展。重点是扩展供应链，支持客户和合作伙伴访问业务服务。图 1 展示了企业的这种发展。

图1 企业的发展

如何使IT 环境更灵活且更快地响应不断改变的业务需求呢？我们如何使这些异构系统和应用程序尽可能无缝地进行通信呢？我们如何达到企业目标而不使企业走向破产的深渊呢？

IT 响应者/支持者是随着企业的这种发展而并行发展的，如图2 所示。现在，许多 IT 经理和专业人员都同样相信，我们真的快找到了一种满意的答案——面向服务的体系结构。

图 2 面向服务的术语

为了减少异构性、互操作性和不断改变的要求的问题，这样的体系结构应该提供平台来构建具有下列特征的应用程序服务：

松散耦合

位置透明

协议独立

基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特定服务，因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能多的技术。特别地，来自不同实现技术（如 J2EE 或 .NET）的技术规范不应该影响 SOA 用户。如果已经存在一个服务实现，我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具有更好的服务质量。

第二部分：作为解决方案的面向服务体系结构

自从“软件危机”促进软件工程的开创以来，IT界一直在努力寻求解决上述问题的方案。在过去几年里，下面简要概述的核心技术进展使我们走到了今天。我

们将简要讨论这些核心技术，而我们重点关注的将是这些技术如何帮助解决 IT 问题。

面向对象的分析和设计

在“Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design”中，Larman 将面向对象的分析和设计的本质描述为“从对象（物体、概念或实体）的角度考虑问题域和逻辑解决方案”。在

“Object-Oriented SoftwareEngineering: A Use Case Driven Approach”中，Jacobson 等将这些对象定义为“特点在于具有许多操作和状态（记忆这些操作的影响）的物体”。

在面向对象的分析中，这样的对象是用问题域来标识和描述的，而在面向对象的设计中，它们转变成逻辑软件对象，这些对象最终将用面向对象的编程语言进行实现。

通过面向对象的分析和设计，可以封装对象（或对象组）的某些方面，以简化复杂业务场景的分析。为了降低复杂性，也可以抽象对象的某些特征，这样就可以只捕获重要或本质的方面。

基于组件的设计并不是一种新技术。它是从对象范例中自然发展而来的。在面向对象的分析和设计的早期，细粒度的对象被标榜为提供“重用”的机制，但是这样的对象的粒度级别太低了，没有适当的标准可以用来使重用广泛应用于实践之中。在应用程序开发和系统集成中，粗粒度组件越来越成为重用的目标。这些粗粒度对象通过内聚一些更细粒度的对象来提供定义良好的功能。通过这种方式，还可以将打包的解决方案套件封装成这样的“组件”。

一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系结构，就可以将支持企业的应用程序划分成一组粒度越来越大的组件。可以将组件看作是打包、管理和公开服务的机制。它们可以共同使用一组技术：实现企业级用况的大粒度企业组件可以通过更新的面向对象的软件开发与遗留系统相结合来实现

面向服务的设计

在“Component-Based Development for Enterprise Systems”中，Allen 涉及了服务的概念，“它是将组件描述成提供相关服务的物理黑盒封装的可执行代码单元。它的服务只能通过一致的已发布接口（它包括交互标准）进行访问。组件必须能够连接到其他组件（通过通信接口）以构成一个更大的组”。服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。图3 展示了重要的面向服务术语：

?服务：逻辑实体，由一个或多个已发布接口定义的契约。

?服务提供者：实现服务规范软件实体。

?服务使用者（或请求者）：调用服务提供者的软件实体。传统上，它称为“客户端”。服务使用者可以是终端用户应用程序或另一个服务。

?服务定位器：一种特殊类型的服务提供者，它作为一个注册中心，允许查找服务提供者接口和服务位置。

?服务代理：一种特殊类型的服务提供者，它可以将服务请求传送到一个或多个其他的服务提供者。

图3 面向服务的术语

基于接口的设计

在组件和服务开发中，都需要进行接口设计，这样软件实体就可以实现和公开其定义的关键部分。因此，在基于组件和面向服务的系统中，“接口”的概念对于成功的设计非常关键。下面是一些与接口有关的重要定义：

?接口：定义一组公共方法签名，它按照逻辑分组但是没有提供实现。接口定义服务的请求者和提供者之间的契约。接口的任何实现都必须提供所有的方法。

?已发布接口：一种可唯一识别和可访问的接口，客户端可以通过注册中心来发现它。

?公共接口：一种可访问的接口，可供客户端使用，但是它没有发布，因而需要关于客户端部分的静态知识。

?双接口：通常是成对开发的接口，这样，一个接口就依赖于另一个接口；

例如，客户端必须实现一个接口来调用请求者，因为该客户端接口提供了某些回调机制。

图4 定义了客户关系管理 (CRM) 服务的 UML 定义，它表示为一个 UML 组件，实现接口 AccountManagement、ContactManagement 和 SystemsManagement。在这些接口中只有头两个接口是已发布接口，不过，后者是公共接口。注意，SystemsManagement 接口和 ManagementService 接口构成了双接口。CRMservice 可以实现许多这样的接口，但是它以多种方式行为的能力取决于客户端在行为的实现方面是否允许有大的灵活性。甚至有可能给特定类型的客户端

提供不同或附加的服务。在一些运行时环境中，这样的功能也用于在单个组件或服务上支持相同接口的不同版本。

图4 已实现的服务

分层应用程序体系结构

如前所述，面向对象的技术和语言是实现组件的极好方式。虽然组件是实现服务的最好方法，但是您必须理解的一点是，好的基于组件的应用程序未必就构成好的面向服务的应用程序。一旦理解了服务在应用程序体系结构中所起的作用，组件开发人员就很有可能会利用现有的组件。进行这种转变的关键是认识到面向服务的方法意味着附加的应用程序体系结构层。图5 演示了如何将技术层应用于程序体系结构以提供粒度更粗的实现（它更靠近应用程序的使用者）。为称呼系统的这一部分而创造的术语是“应用程序边界”，它反映了服务是公开系统的外部视图的极好方法的事实（通过内部重用并结合使用传统组件设计）。

图5 应用程序实现层：服务、组件、对象

第三部分：近距离审视面向服务的体系结构

面向服务的体系结构提供了一种方法，通过这种方法，可以构建分布式系统来将应用程序功能作为服务提供给终端用户应用程序或其他服务。其组成元素可以分成功能元素和服务质量元素。图6 展示了体系结构堆栈以及在一个面向服务的体系结构可能观察到的元素。

注意：面向服务的体系结构堆栈可能是一个容易引起争议的问题，因为各方面的支持者已经提出了几种不同的堆栈。我们的堆栈不是作为服务堆栈提出的。我们之所以在此提出它，是因为我们想要搭建一个有用的框架，在本书的剩余章节中，我们将通过这个框架来组织对 SOA 的讨论。

图6 面向服务的体系结构的元素

体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面，而右边的一半集中于体系结构的服务质量方面。这些元素详细描述如下：

功能性方面包括：

?传输是一种机制，用于将来自服务使用者的服务请求传送给服务提供者，并且将来自服务提供者的响应传送给服务使用者。

?服务通信协议是一种经过协商的机制，通过这种机制，服务提供者和服务使用者可以就将要请求的内容和将要返回的内容进行沟通。

?服务描述是一种经过协商的模式，用于描述服务是什么、应该如何调用服务以及成功地调用服务需要什么数据。

?服务描述实际可供使用的服务。

?业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用，以满足业务要求。注意，可以将业务流程本身看作是服务，这样就产生了业务流程可以由不同粒度的服务组成的观念。

?服务注册中心是一个服务和数据描述的存储库，服务提供者可以通过服务注册中心发布它们的服务，而服务使用者可以通过服务注册中心发现或查找可用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。

服务质量方面包括：

?策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我们在功能和服务质量两个区中都有策略功能。

?安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权和访问控制。

?传输是属性集，可以应用于一组服务，以提供一致的结果。例如，如果要使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个完成。

?管理是属性集，可以应用于管理提供的服务或使用的服务。

SOA 协作

图7 展示了面向服务的体系结构中的协作。这些协作遵循“查找、绑定和调用”范例，其中，服务使用者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹配的服务。如果服务存在，注册中心就给使用者提供接口契约和服务的端点地址。下图展示了面向服务的体系结构中协作支持“查找、绑定和调用”范例的实体。

图7 面向服务的体系结构中的协作

?服务使用者：服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。

?服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。

?服务注册中心：服务注册中心是服务发现的支持者。它包含一个可用服务的存储库，并允许感兴趣的服务使用者查找服务提供者接口。

面向服务的体系结构中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的某一种（或多种）。面向服务的体系结构中的操作包括：

?发布：为了使服务可访问，需要发布服务描述以使服务使用者可以发现和调用它。

?发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。

?绑定和调用：在检索完服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。

面向服务的体系结构中的构件包括：

?服务：可以通过已发布接口使用服务，并且允许服务使用者调用服务。

?服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和/或服务质量 (QoS) 级别。

除了动态服务发现和服务接口契约的定义之外，面向服务的体系结构还具有以下特征：

?服务是自包含和模块化的。

?服务支持互操作性。

?服务是松散耦合的。

?服务是位置透明的。

?服务是由组件组成的组合模块。

这些特征也是满足电子商务按需操作环境的要求的主要特征，如“e-business on demand and Service-oriented architecture”所定义的。

最后，我们需要说明的是，面向服务的体系结构并不是一个新的概念。如图8 所示，面向服务的体系结构所涉及的技术至少包括 CORBA、DCOM 和 J2EE。面向服务的体系结构的早期采用者还曾成功地基于消息传递系统（如 IBM WebSphere MQ）创建过他们自己的面向服务企业体系结构。最近，SOA 的活动舞台已经扩展到包括 World Wide Web (WWW) 和 Web 服务。

图8 面向服务的体系结构的不同实现

SOA范围中的服务

在面向服务的体系结构中，映射到业务功能的服务是在业务流程分析的过程中确定的。服务可以是细粒度的，也可以是粗粒度的，这取决于业务流程。每个服务都有定义良好的接口，通过该接口就可以发现、发布和调用服务。企业可以选择将自己的服务向外发布到业务合作伙伴，也可以选择在组织内部发布服务。服务还可以由其他服务组合而成。

服务与组件

服务是粗粒度的处理单元，它使用和产生由值传送的对象集。它与编程语言术语中的对象不同。相反，它可能更接近于业务事务（如 CICS 或 IMS 事务）的概念而不是远程 CORBA 对象的概念。

服务是由一些组件组成的，这些组件一起工作，共同提供服务所请求的业务功能。因此，相比之下，组件比服务的粒度更细。另外，虽然服务映射到业务功能，但是组件通常映射到业务实体和操作它们的业务规则。作为一个示例，让我们看一看 WS-I 供应链管理（WS-I Supply Chain Management）样本的定购单（PurchaseOrder）组件模型，如图9 所示。

图9 定购单组件模型

在基于组件的设计中，可以创建组件来严格匹配业务实体（如顾客（Customer）、定购单（Purchase Order）、定购项（Order Item）），并且封装匹配这些实体所期望的行为的行为。

例如，定购单（Purchase Order）组件提供获取关于已定购的产品列表和定购的总额的信息的功能；定购项（Order Item）组件提供获取关于已定购的产品的数量和价格的信息的功能。每个组件的实现都封装在接口的后面。因此，定购单（Purchase Order）组件的用户不知道定购单（Purchase Order）表的模式、计算税金的算法、以及定单总额中的回扣和/或折扣。

在面向服务的设计中，不能基于业务实体设计服务。相反，每个服务都是管理一组业务实体中的操作的完整单元。例如，顾客服务将响应来自任何其他系统或需要访问顾客信息的服务的请求。顾客服务可以处理更新顾客信息的请求；添加、更新、删除投资组合；以及查询顾客的定单历史。顾客服务拥有所有与它管理的顾客有关的数据，并且能够代表调用方进行其他服务查询，以提供统一的顾客服务视图。这意味着服务是一个管理器对象，它创建和管理它的一组组件。

第四部分：面向服务的体系结构所带来的好处

如前所述，企业正在处理两个问题：迅速地改变的能力和降低成本的要求。为了保持竞争力，企业必须快速地适应内部因素（如兼并和重组）或外部因素（如竞争能力和顾客要求）。需要经济而灵活的 IT 基础设施来支持企业。

我们可以认识到，采用面向服务的体系结构将给我们带来几方面的好处，有助于我们在今天这个动荡的商业环境中取得成功：

利用现有的资产。

SOA 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在 IT 方面的投资，方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值，而不必重新从头开始构建。

更易于集成和管理复杂性。

在面向服务的体系结构中，集成点是规范而不是实现。这提供了实现透明性，并将基础设施和实现发生的改变所带来的影响降到最低限度。通过提供针对基于完全不同的系统构建的现有资源和资产的服务规范，集成变得更加易于管理，因为复杂性是隔离的。当更多的企业一起协作提供价值链时，这会变得更加重要。

更快的响应和上市速度。

从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的组织提供了独特的优势。通过利用现有的组件和服务，可以减少完成软件开发生命周期（包括收集需求、进行设计、开发和测试）所需的时间。这使得可以快速地开发新的业务服务，并允许组织迅速地对改变做出响应和减少上市准备时间。

减少成本和增加重用。

通过以松散耦合的方式公开的业务服务，企业可以根据业务要求更轻松地使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增加。