ESP Chapter 02

第2章面向服务的体系结构

“为了顺利运作，企业必须具有灵活性，必须具有灵活的IT基础设施。很多公司都在通过基于面向服务的架构（SOA）对系统进行整合来获得协调统一的IT和业务灵活性。”

IBM软件集团副总裁Sandy Carter

SOA之热仍在蔓延。在2006年4月初美国加州圣塔克拉拉举办的2006软件大会上，主流厂商和财富500强企业的CIO们冠盖云集，或指点企业信息化迷津，或畅谈未来IT 架构，或讨论软件技术创新。每一个热门话题，每一次思维碰撞，似乎总是绕不过面向服务的体系结构（SOA）。

最近一项调查称，80％的财富500强企业表示在大概两年的时间内会转变一次他们的业务模式，而业务模式的成功改变很大程度上取决于其信息系统对快速演变的商业环境的适应能力，因为大概一半受访公司表示，这项转变会受到僵硬的信息系统的牵制。针对这个问题，CIO们需要借助一个灵活的方式，通过一个整合的平台利用并扩展一系列各异的企业软件以支持新的要求并实现创新。

十年前，解决灵活性问题的方法是企业应用集成（EAI），在主机端运行经过整合的软件。不过，这一方法已越来越难于适应日新月异的商业环境，其中最重要的原因是新的商业过程往往跨越多个组织或需要复杂的分析和协作。因此，新的解决方案不仅需要提供高效的商业推动力，更需要是能组建未来业务模式灵活的模块。客户机/服务器时代必然转向SOA 这一新的潮流。

面对这一分水岭，能够率先提供基于网络服务为企业应用提供各种灵活的商业模块的SOA成为重量级厂商追逐的目标，包括SAP、IBM、BEA、Oracle、微软在内的厂商都竞相为此推波助澜。

公司都在努力将IT系统环境转为以服务为导向的架构（SOA），以支持安装各种软件来有效交换数据，从而降低创建和维护界面的成本。业界分析公司Gartner估计，到2008年，60%以上的企业将在创建基础软件应用和业务流程时，将SOA作为“指导原则”。

2.1什么是面向服务的体系结构

1996年，Gartner最早提出SOA。2002年12月，Gartner认为SOA是“现代应用开发领域最重要的课题”，还预计到2008年，SOA将成为占有绝对优势的软件工程实践方法，主流企业现在就应该在理解和应用SOA开发技能方面进行投资。

体系结构的讨论由来已久，为什么SOA引起了如此广泛的关注？让我们先来回顾一下SOA提出的背景。

虽然IT经理一直面临着削减成本和最大限度地利用现有技术的难题，但是与此同时，

他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。

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

图2- 1 CIO调查：最重要的下一年度战略软件平台项目

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

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

因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态系统业务范例发展。重点是

扩展供应链，支持客户和合作伙伴访问业务服务。如下图所示。

图2- 2 企业的发展

我如何使我的IT 环境更灵活且更快地响应不断改变的业务需求呢？我们如何使这些异构系统和应用程序尽可能无缝地进行通信呢？我们如何达到企业目标而不使企业走向破产的深渊呢？IT 响应者/支持者是随着企业的这种发展而并行发展的，如下图所示。现在，许多IT经理和专业人员都同样相信，我们真的快找到了一种满意的答案——面向服务的体系结构。

图2- 3 体系结构的发展

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

?松散耦合

?位置透明

?协议独立

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

事实上，就我们上面提到的问题，自从“软件危机”促进软件工程的开创以来，IT界一直在努力寻找解决这些问题的方案，从面向对象的分析和设计、基于组件的设计到我们在SOA中谈到的面向服务的设计。

因此，我们说SOA是一种架构模型和一套设计方法学，其目的是最大限度地重用应用程序中立型的服务以提高IT适应性和效率。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

事实上，存在大量关于什么是SOA的讨论，因为SOA对不同的人具有不同的含义，下表列举了一些不同角色的人对SOA的理解。

表2- 1 对SOA的不同理解

我们认为，SOA的关键是“服务”的概念，在“Component-Based Development for Enterprise Systems”中，Allen 涉及了服务的概念，“它是将组件描述成提供相关服务的物理黑盒封装的可执行代码单元。它的服务只能通过一致的已发布接口（它包括交互标准）进行访问。组件必须能够连接到其他组件（通过通信接口）以构成一个更大的组”。服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。

SOA中关于服务的术语如下图所示。

图2- 4 面向服务的术语

在上图中，我们可以看到：

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

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

●服务使用者（或请求者）：调用服务提供者的软件实体。传统上，它称为“客户端”。

服务使用者可以是终端用户应用程序或另一个服务。

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

供者接口和服务位置。

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

的服务提供者。

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

SOA并不是包治百病的万灵单，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。

IBM对SOA的定义如下：“面向服务的体系结构(SOA) 是一种用于创建企业IT 体系结构的体系结构样式，利用了面向服务的原则来实现业务和支持业务的信息系统之间更为紧密的关系。”

SOA的特征包括：

●服务的封装（Encapsulation）

●服务的重用（Reuse）

●服务的互操作（Interoperability）

●服务是自治的（Autonomous）功能实体

●服务之间的松耦合度（Loosely Coupled）

●服务是位置透明的（Location Transparency）

IBM也提供了一个SOA的参考模型，此模型说明了为了支持SOA所需的主要功能，如下图所示。

图2- 5 IBM SOA Foundation参考模型

SOA中包含三个角色，服务申请者（Service Requester）、服务提供者（Service Provider）、服务注册器（Service Registry），如图2-1所示。

图2- 6 SOA中的三个角色

服务提供者负责建立一个有用的服务，并为它创建一个服务描述，然后将这个服务描述发布给一个或多个服务注册器，并从一个或多个服务注册器那里接收服务请求信息。服务请求者负责寻找发布在一个或多个服务注册器那里的一个服务描述，并负责使用服务描述来bind或者invoke服务提供者所提供的服务。一个服务的任何用户都可被看作服务请求者。服务注册器负责将服务提供者发布在其上的服务描述广而告之，并允许服务请求者在本服务注册器所拥有的服务描述里搜寻。一旦服务注册器将服务请求者和服务提供者配对，服务注册器就不需要再参与交互过程。

SOA还包含三种操作：发布（publish），查找（find）和绑定（bind）。这些操作定义了SOA的角色之间的合约。

发布操作是服务注册或者服务广告的动作。它成为服务注册器和服务提供者之间的契约。通过查找操作，服务请求者陈述一条或者多条搜索标准，例如服务的类型，服务的质量，等等。查找操作的结果是一个符合查找标准的服务描述的列表。绑定操作在服务请求者和服务提供者之间体现client-server的关系。绑定操作可以是动态的（或说晚期），例如实时产生的基于服务描述（用作唤醒服务）的客户端代理；或者它也可以是非常静态的（或说早期），例如开发者手工编码定制一个客户程序唤醒一个服务的方式（也就是说，在程序创建期间）。

SOA中的构件包括：

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

●服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自服务的

请求和响应的格式。服务描述可以指定一组前提条件、后置条件和/或服务质量

(QoS) 级别。

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

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

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

图2- 7 定购单组件模型

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

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

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

从业务的角度来说，面向服务的体系结构的重点在于开发能帮助您完成业务任务的技术，而不是通过技术约束来规定您的行动。例如，销售过程（制造、运输和收到货款）可能会涉及数十个步骤和若干不同的数据库和计算机系统。但就其实质而言，此过程包含一系列人工活动，例如：

●销售人员找到潜在客户

●客户订购产品

●生产部门制造产品

●生产部门发出产品

●收款部门开具产品帐单

客户支付产品货款

面向服务的体系结构基于这些实际活动或业务服务进行组织，而不是形成公司所维护的不同的信息竖井(Silo)。

2.2可以用面向服务的体系结构做什么？

对SOA 的需要来源于需要使业务IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

下面举一个具体的例子。一个服装零售组织拥有500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的SOA 模型得出的。这是来自SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。

正如您可以看到的，在这里，改变和SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。

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

1.利用现有的资产

SOA 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在IT 方面的投资，方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值，而不必重新从头开始构建。组织可以通过合并构建在不同的机器上、运行在不同的操作系统中、用不同的编程语言开发的组件来创建服务。遗留系统可以通过Web服务接口来封装和访问。

2.更易于集成和管理复杂性

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

3.更快的响应和上市速度

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

4.减少成本和增加重用

通过以松散耦合的方式公开的业务服务，企业可以根据业务要求更轻松地使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增加。同时，开发团队的学习难度也降低了，因为他们可能已经熟悉了现有的组件。

5.降低风险

重用现有的组件降低了在增强或创建新的业务服务的过程中带来的风险，也减少了维护和管理支持服务的基础架构的风险。

6.持续改进业务流程

通过SOA，企业可以未雨绸缪，为未来做好充分的准备。SOA 业务流程是由一系列业务服务组成的，可以更轻松地创建、修改和管理它来满足不同时期的需要。流程操作是以一定的模式重组部件（构成业务服务的组件）来实现的。这将进一步允许更改流程流，而同时监视产生的结果，因此促进了持续改进。

7.建立以流程为中心的体系结构

现有的体系结构模型和实践往往是以程序为中心的。应用程序是为了程序员的便利而开发的。通常，流程信息在组件之间传播。应用程序很像一个黑匣子，没有粒度可用于外部。重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中，应用程序是为过程开发的。流程可以分解成一系列的步骤，每一个步骤表示一个业务服务。实际上，每个过程服务或组件功能都相当于一个子应用程序。将这些子应用程序链接在一起可以创建能够满足业务需求的流程流。这种粒度允许利用和重用整个组织中的子应用程序。

SOA 提供了灵活性和响应能力，这对于企业的生存和发展来说是至关重要的。但是面向服务的体系结构决不是灵丹妙药，而迁移到SOA 也并非一件可以轻而易举就完成的事情。请别指望一个晚上就将整个企业系统迁移到面向服务的体系结构，我们推荐的方法是，在业务要求出现或露出苗头时迁移企业功能的适当部分。

2.3构成SOA 的技术是什么？

SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用XML 和Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。您还可以通过分布式事务处理和分布式软件状态管理来进一步地改善它。

SOA 服务和Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web 服务在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现SOA 模型是通过HTTP 传递的SOAP 消息中最常见的SOA 模型。因而，从本质上讲，Web 是实现SOA 的具体方式之一。

尽管我们觉得Web 服务是实现SOA 的最好方式，但是SOA 并不局限于Web 服务。其他使用WSDL 直接实现服务接口并且通过XML 消息进行通信的协议也可以包括在SOA 之中。正如在别处指出的，CORBA 和IBM 的MQ 系统通过使用能够处理WSDL 的新特征也可以参与到SOA 中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的信息交换。

既为了建立所有这些信息的适当控制，又为了应用安全性、策略、可靠性以及会计方面的要求，在SOA 体系结构的框架中加入了一个新的软件对象。这个对象就是企业服务总线（Enterprise Service Bus，ESB），它使用许多可能的消息传递协议来负责适当的控制、流

甚至还可能是服务之间所有消息的传输。虽然ESB 并不是绝对必需的，但它却是在SOA 中正确管理您的业务流程至关重要的组件。ESB 本身可以是单个引擎，甚至还可以是由许多同级和下级ESB 组成的分布式系统，这些ESB 一起工作，以保持SOA 系统的运行。在概念上，它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。

从开发人员的角度来说，他们使用的工具必须知道SOA 的能力，并允许开发人员有效地使用SOA 对象。这将设计SOA 模型、开发服务和服务对象以及测试SOA 应用程序这些过程包括进来并组成一个整体。因而，开发人员的工作必须为面向服务的应用程序设计/开发（Service-Oriented Application Design/Development，SOAD）做好准备。

从上文中我们可以看到Web服务和ESB是目前SOA中最重要的技术，下面我们就针对这两种技术进行详细论述。

2.3.1Web服务

使用Web 服务技术，应用程序可以通过与平台和编程语言无关的方式相互通信。Web 服务是一个软件接口，它描述了一组可以在网络上通过标准化的XML 消息传递访问的操作。它使用基于XML 语言的协议来描述要执行的操作或者要与另一个Web 服务交换的数据。在面向服务的体系结构（Service-Oriented Architecture，SOA）中，一组以这种方式交互的Web 服务定义了特定的Web 服务应用程序。

软件业最终会接受这样的事实：跨多个操作系统、编程语言和硬件平台集成软件应用程序不可能由任何一种专门的环境来解决。传统上，这个问题一直是一个紧耦合问题，调用远程网络的应用程序通过自己发出的函数调用和请求的参数与远程网络紧密地联系在一起。在Web 服务出现之前，在大多数系统上，采用的是固定的接口，但对于不断变化的环境或需求，这样做缺乏灵活性或适用性

Web 服务所使用的XML 可以用真正与平台无关的方式来描述任何（所有）数据，以跨系统交换数据，因此转向了松耦合应用程序。而且，Web 服务可以在较抽象的层面上工作，较抽象层面可以按照需要动态地重新评估、修改或处理数据类型。所以，从技术层面上讲，Web 服务可以更方便地处理数据，并且允许软件更自由地进行通信。

从更高的概念层面上讲，我们可以将Web 服务视为一些工作单元，每个单元处理特定的功能任务。再往上一步，可以将这些任务组合成面向业务的任务，以处理特定的业务操作任务，从而使非技术人员可以考虑一些应用程序，这些应用程序能够在Web 服务应用程序工作流中一起处理业务问题。因此，一旦由技术人员设计并构建好Web 服务之后，业务流程架构师就可以聚集这些Web 服务来解决业务层面上的问题。这里借用汽车引擎来作类比，业务流程架构师考虑将整个汽车引擎与汽车框架、车身、变速器和其他系统组合在一起，而不是研究每个引擎内的各个部件。而且，动态平台意味着引擎可以与其他汽车制造商的变

速器或部件一起工作。

最后一个方面是，Web 服务有助于在组织内的业务人员和技术人员之间架起一座桥梁。Web 服务使业务人员更容易理解一些技术上的操作。业务人员可以描述一些事件和活动，然后技术人员可以将这些事件和活动与相应的服务相关联。

有了通用定义的接口和设计良好的任务，重用这些任务就变得更容易了，因而重用这些任务所代表的应用程序也就变得容易了。应用程序软件的可重用性意味着在软件上的投资有了更好的回报，因为可以从同一资源产生更多收益。可重用性使业务人员可以考虑以一种新的方式来使用现有的应用程序，或者以一种新的方式将应用程序提供给合作伙伴，因此可能增加合作伙伴间的业务交易。

所以，Web 服务试图解决的主要问题是数据和应用程序集成的问题，以及将技术性的功能转换为面向业务的计算任务的问题。这两个方面使企业可以就流程或应用程序层面与他们的合作伙伴进行交流，同时为适应新形势或按照需要与不同合作伙伴进行合作留有动态的余地。

2.3.1.1Web服务模型

Web 服务体系结构基于三种角色（服务提供者、服务注册中心和服务请求者）之间的交互。交互涉及发布、查找和绑定操作。这些角色和操作一起作用于Web 服务构件：Web 服务软件模块及其描述。在典型情况下，服务提供者托管可通过网络访问的软件模块（Web 服务的一个实现）。服务提供者定义Web 服务的服务描述并把它发布到服务请求者或服务注册中心。服务请求者使用查找操作来从本地或服务注册中心检索服务描述，然后使用服务描述与服务提供者进行绑定并调用Web 服务实现或同它交互。服务提供者和服务请求者角色是逻辑结构，因而服务可以表现两种特性。下图显示了这些操作、提供这些操作的组件及它们之间的交互。

图2- 8 Web服务角色、操作和构件

1.Web 服务体系结构中的角色

●服务提供者。从企业的角度看，这是服务的所有者。从体系结构的角度看，这是托

管访问服务的平台。

●服务请求者。从企业的角度看，这是要求满足特定功能的企业。从体系结构的角度

看，这是寻找并调用服务，或启动与服务的交互的应用程序。服务请求者角色可以

由浏览器来担当，由人或无用户界面的程序（例如，另外一个Web 服务）来控制

它。

●服务注册中心。这是可搜索的服务描述注册中心，服务提供者在此发布他们的服务

描述。在静态绑定开发或动态绑定执行期间，服务请求者查找服务并获得服务的绑

定信息（在服务描述中）。对于静态绑定的服务请求者，服务注册中心是体系结构

中的可选角色，因为服务提供者可以把描述直接发送给服务请求者。同样，服务请

求者可以从服务注册中心以外的其它来源得到服务描述，例如本地文件、FTP 站

点、Web 站点、广告和服务发现（Advertisement and Discovery of Services，ADS）或发现Web 服务（Discovery of Web Services，DISCO）。

2.Web 服务体系结构中的操作

对于利用Web 服务的应用程序，必须发生以下三个行为：发布服务描述、查询或查找服务描述以及根据服务描述绑定或调用服务。这些行为可以单次或反复出现。这些操作具体为：

●发布。为了使服务可访问，需要发布服务描述以使服务请求者可以查找它。发布服

务描述的位置可以根据应用程序的要求而变化（请参阅“服务发布”以了解更多细

节）。

●查找。在查找操作中，服务请求者直接检索服务描述或在服务注册中心中查询所要

求的服务类型（请参阅“服务发现”以了解更多细节）。对于服务请求者，可能会在

两个不同的生命周期阶段中牵涉到查找操作：在设计时为了程序开发而检索服务的

接口描述，而在运行时为了调用而检索服务的绑定和位置描述。

●绑定。最后需要调用服务。在绑定操作中，服务请求者使用服务描述中的绑定细节

来定位、联系和调用服务，从而在运行时调用或启动与服务的交互。

3.Web 服务的构件

●服务。在这里，Web 服务是一个由服务描述来描述的接口，服务描述的实现就是

该服务。服务是一个软件模块，它部署在由服务提供者提供的可以通过网络访问的

平台上。服务存在就是要被服务请求者调用或者同服务请求者交互。当服务的实现

中利用到其它的Web 服务时，它也可以作为请求者。

●服务描述。服务描述包含服务的接口和实现的细节。其中包括服务的数据类型、操

作、绑定信息和网络位置。还可能包括可以方便服务请求者发现和利用的分类及其

它元数据。服务描述可以被发布给服务请求者或服务注册中心。

Web 服务体系结构解释了如何实例化元素和如何以一种可以互操作的方式实现这些操作。

4.Web 服务开发生命周期

Web 服务开发生命周期包括了设计和部署以及在运行时对服务注册中心、服务提供者和服务请求者每一个角色的要求。每个角色对开发生命周期的每一元素都有特定要求。服务注册中心的开发和部署不在本文的范围以内。

开发生命周期有以下四个阶段：

阶段1. 构建

生命周期的构建阶段包括开发和测试Web 服务实现、定义服务接口描述和定义服务实现描述。可以通过创建新的Web 服务、把现有的应用程序变成Web 服务和由其它Web 服务和应用程序组成新的Web 服务提供Web 服务的实现。

阶段2. 部署

部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义，以及把Web 服务的可执行文件部署到执行环境（典型情况下，Web 应用程序服务器）中。

阶段3. 运行

在运行阶段，可以调用Web 服务。在此，Web 服务完全部署、可操作并且服务提供者可以通过网络访问服务。现在服务请求者可以进行查找和绑定操作。

阶段4. 管理

管理阶段包括持续的管理和经营Web 服务应用程序。安全性、可用性、性能、服务质量和业务流程问题都必须被解决。

2.3.1.2Web服务规范

Web 服务采用一系列的相关协议来描述、传递服务和与服务交互。根据其通常的功能和使用，可以将这一系列协议进一步划分为组。

第一组处理消息传递、接口描述、寻址和交付的问题。最有名的是消息传递协议，称为简单对象访问协议（Simple Object Access Protocol，SOAP）。此协议对消息进行了编码，这样就可以通过传输协议（如HTTP、IIOP、SMTP 或其他协议）在网络上传递它们。

Web 服务描述语言（Web Services Description Language，WSDL）表示为一系列XML 语句，这些语句组成了每个服务的接口的定义。另一个正在制订的规范是Web 服务寻址(WS-Addressing)，它定义了如何在分布式体系结构中唯一地进行Web 服务寻址和标识Web 服务。另一个流行的规范是Web 服务调用框架（Web Services Invocation Framework），在这种框架中，您可以定义任何类型的组件的WSDL 接口，即使它们没有使用相同的消息传递协议。

下一组协议和规范定义了服务如何公开它们自己以及如何在网络上相互发现。对于要相互查找的服务，统一描述、发现和集成（Universal Description, Discovery and Integration，

UDDI）为查找和访问服务定义了注册中心和相关的协议。Web 服务检查语言（Web Services Inspection Language）是UDDI 在不使用注册中心的情况下采用的一种可选机制。

用于Web 服务的安全性协议是从Web 服务安全性(WS-Security) 规范开始的，该规范为安全通信定义了基于令牌的体系结构。以此为基础，有六个主要的组成规范：

●Web 服务策略(WS-Policy) 和相关的规范，定义了关于服务交互方式的策略规

则。

●Web 服务信任(WS-Trust)，定义了安全交换的信任模型。

●Web 服务隐私(WS-Privacy)，定义了如何维护信息的隐私。

●Web 服务安全会话(WS-Secure Conversation)，定义了如何使用在Web 服务策

略(WS-Policy)、Web 服务信任(WS-Trust) 和Web 服务隐私(WS-Privacy)

中定义的规则，以在用于交换数据的服务之间建立安全会话。

●Web 服务联盟(WS-Federation)，定义了分布式标识的规则以及如何对其进行管

理。

●Web 服务授权(WS-Authorization)，定义了如何处理对访问和交换数据的授权。

除了安全性模型之外，还有特定于应用程序的规范，其中包括Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS），它定义了一起进行分布式事务处理的工作流操作、Web 服务事务(WS-Transaction)、Web 服务协调(WS-Coordination)。

目前计划制订的规范是Web 服务分布式管理(Web Services Distributed Management)，用于对所有的服务和面向服务的体系结构进行软件管理。最后，还有一些用于用户界面（Web 服务交互应用程序(WS-InteractiveApplications)）和Web 服务的远程访问（Web 服务远程门户(WS-RemotePortals)）的规范。

用于Web 服务的规范还处在不断制订的过程中，而且它们仅仅是开始解释服务之间应该如何交互。然而，它们无法包括每一种方案和这些方案的可能组合。因此，Web 服务互操作性组（Web Services Interoperability Group，WS-I）的组成成员几乎来自所有从事Web 服务开发的大大小小的供应商，它已经肩负起开发案例研究、示例应用程序、实现方案和测试工具的重任，目的是确保这些标准和规范能够真正地协同工作，而不考虑供应商的产品实现。

WS-I 已经定义了第一个用于Web 服务的基本概要(Basic Profile 1.0)，并且还发布了方案、示例应用程序和测试工具，以便根据方案评估和比较各种实现的结果。

除了WS-I 之外，Organization for the Advancement of Structured Information Standards (OASIS) 、World Wide Web Consortium (W3C) 和Internet Engineering Task Force (IETF) 也在进行大量的标准制订工作。

WS-BPEL规范，单个服务很好处理，但应用程序在大多数情况下则较难处理。企业级

计算要求至少将多个服务组合为一个完整的系统，而WS-BPEL 提供了用于指定创建此类系统所必需的交互（如分支和并发处理）。

2.3.2企业服务总线

业务功能的虚拟化（SOA 的一个主要目标）是通过将服务的定义和使用与服务的实现分离开来而实现的。我们可以使用各种技术实现服务，这些技术包括IBM WebSphere? MQ、IBM CICS? 或IBM IMS?、Java? 2 Platform Enterprise Edition (J2EE) Enterprise JavaBeans (EJB)、Java 类、IBM DB2? 查询、Java 消息服务(JMS) 或Microsoft? .NET。服务请求者将请求发送到提供其所需功能的服务提供者，而不必考虑它如何实现。

ESB 是一种体系结构模式，支持虚拟化通信参与方之间的服务交互并对其进行管理。它提供服务提供者和请求者之间的连接，即使它们并非完全匹配，也能够使它们进行交互。此模式可以使用各种中间件技术和编程模型实现。ESB提供的体系结构能够移除服务请求者和提供者之间的直接连接。服务请求者连接到总线而不是实现具体服务的提供者，这样就进一步降低了请求者和提供者之间的耦合程度。同时，服务总线还能提供附加的价值和功能，例如，安全性和服务递送的质量保证等。

图2- 9 企业服务总线概览

在ESB 模式中，服务交互的参与方并不直接交互，而是通过一个总线交互，该总线提供虚拟化和管理功能来实现和扩展SOA 的核心定义。IBM ESB 模式提供以下几方面的虚拟化：

位置和标识：参与方不需要知道其他参与方的位置或标识。例如，请求者不需要知道请求是否可以由某个提供者提供服务。您可以随意添加或删除服务提供者，而不

会带来任何干扰。

●交互协议：参与方不需要采用相同的通信协议或交互方式。表达为SOAP/HTTP

的请求可能由仅理解Java 远程方法调用(RMI) 的提供者提供服务。

●接口：请求者和提供者不需要就公共接口达成协议。ESB 可以通过将请求消息转

换为提供者所期望的格式来处理此类差异。

●（交互）服务质量(QoS)：参与方声明其QoS 要求，包括性能和可靠性、请求的

授权、消息内容的加密/解密、服务交互的自动审核以及如何对请求进行路由（如

根据工作负载分布标准将请求路由到可用的实现）。描述请求者和提供者的QoS

要求和功能的策略可以由服务自己实现或者由进行不匹配补偿的ESB 实现。

因此ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和QoS 的服务提供者。提供者接收他们要响应的请求，而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编程模型和技术调用或交付服务，而无需考虑是直接连接还是通过ESB 传递的。连接到ESB 是部署决策；应用程序源代码不会受到影响。

ESB 支持许多交互类型，包括单向、请求/响应、异步、同步和发布/订阅。它还支持复杂事件处理（在复杂事件处理中，可能会观测到一系列事件），以产生一个事件作为该系列中的关系的结果。

下图对基本ESB 模式进行了描述。消息流过将各个通信参与方相互连接在一起的总线。某些参与方会调用其他参与方提供的服务；而其他参与方则会向感兴趣的使用者发布信息。端点与ESB 交互的位置称为服务交互点(SIP)。例如，SIP 可以是Web 服务端点、WebSphere MQ 队列或RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据：SIP 的要求和功能（例如，提供或需要的接口）、它们希望与其他SIP 的交互方式（例如，同步或异步，通过HTTP 或JMS）、它们的QoS 要求（例如，首选的安全、可靠交互）以及支持与其他SIP 交互的其他信息（例如，语义注释）。

图2- 10 ESB基本模式

将总线插入参与方之间，提供了将它们的交互通过称为中介的构造进行协调的机会。中介对请求者和提供者之间动态传递的消息进行操作。对于复杂的交互，可以按顺序将中介连在一起。中介模式部分讨论了实现这些虚拟化、QoS 和管理概念的常用中介模式。

ESB 模式为SOA 实现提供了灵活且易于管理的方法。总线透明地插入端点之间，可以提高服务质量，可以促进请求者和提供者间的交互（而不受协议、交互模式或服务功能不匹配的影响），还可以支持监视和管理。

2.3.2.1SOA用户角色与任务

通过研究创建和管理SOA 解决方案的用户的角色及任务，可以进一步深入了解ESB 模式。ESB 工具和运行时将SOA 解决方案的生命周期划分为四个阶段：

●发现与描述：对可以在整个ESB 中进行互连的SIP 进行标识和描述。这包括创

建新的服务、发现现有服务、以及描述其接口、要求和功能。

●建模与构建：通过新建的或现有的中介进行SIP 互连，以描述解决方案的端到端

交互。

●配置与部署：针对特定的运行时拓扑配置解决方案的抽象声明，并对其进行部署，

同时创建必要的运行时构件。

●监视与管理：通过SIP 和中介的行为监视和管理解决方案。此阶段将使用ESB 运

行时中的检测和控制点、以及观测和响应消息流的中介。

对于ESB 中间件，最重要的SOA 解决方案开发角色是集成开发人员和解决方案管理员，但其中也涉及到业务分析人员、解决方案架构师、实现人员、适配器开发人员和操作人员。（这些角色都是概念性的；一个人可以担任其中的多个角色。）下图显示了这些角色交互的方式。

图2- 11 SOA用户角色

业务分析人员确定业务需求，并检查业务流程。他们将概括出解决方案的目标、涉及的业务流程、监视解决方案的运行状况和状态的关键指标，以及IT 系统需要提供的业务服务的类型。

解决方案架构师确定哪些业务需求可以通过对现有IT 资产进行重用、修改或组合得到满足，哪些需要编写或购买新的IT 资产。他们定义IT 资产间的交互，包括消息交换的内容。

开发工作在三个角色中分配。实现人员编写新的应用程序代码，这些代码将通过服务接口调用。适配器开发人员构建包装现有或新采购的应用程序和软件包的服务，从而为其他服务提供可访问性。集成开发人员使用ESB 的相关工具和技术构建逻辑，以控制请求在这些服务间路由的方式。

解决方案管理员部署新的IT 资产并将其服务定义导入到服务注册表中，从而使新的IT 资产可用。当解决方案就绪后，操作人员将监视其执行，根据需要启动和停止IT 系统，并给解决方案管理员提供建议（后者可能将据此调整解决方案配置）。

2.3.2.2ESB模式

集成开发人员和解决方案管理员会使用一组模式对SOA 解决方案进行设计和部署。

基本ESB 模式将应用程序组件抽象为一个服务集，这些服务通过总线进行交互（而不是通过直接的点到点通信交互）。某个给定的服务既可以是提供者，也可以是请求者，或者同时兼有两个角色。任何SOA 实现都会支持基本虚拟化，允许在不影响依赖请求者的情况下替换等效提供者实现。ESB 模式通过其对请求者/提供者交互的显式管理提高了此基本SOA 功能。只要能提供与请求者所需的功能相似的功能，且ESB 能对其进行协调，任何