迄今为止，对于面向服务的架构(Service-Oriented Arhitecture，SOA)还没有一个公认的定义。许多组织从不同的角度和不同的侧面对 SOA 进行了描述，较为典型的定义如下。

(1)W3C将SOA定义为:“一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程”

(2)将SOA定义为:“本质上是服务的集合，服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数”。

(3)Gartner 则将 SOA 描述为:“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成，SOA与大多数通用的客户端/服务器模型不同之处，在于它着重强调软件构件的松散糊合，并使用独立的标准接口

SOA概述

SOA 并不仅是一种现成的技术，还是一种架构和组织IT 基础结构及业务功能的方法，是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)模型的方法。下图描述了一个完整的面向服务的架构模型。

面向服务的架构

在 SOA 架构模型中，首先，所有的功能都定义成了独立的服务。服务之间通过交互、协调作业从而完成业务的整体逻辑。所有的服务通过服务总线(Services Bus)或流程管理器来连接服务和提高服务请求的路径。这种松散耦合的架构使得各服务在交互过程中无须考虑双方的内部实现细节，以及部署在什么平台上。应用程序的松散耦合还提供了一定级别的灵活性和互操作性，使用传统的方法构建高度集成的、跨平台的程序，对程序的通信环境所能提供的灵活性和互操作性无法与之相比。下面从微观的角度，看看独立的单个服务内部的结构模型。一个独立的服务基本结构模型如图所示。

单个服务内部结构

由图  可以看出，与构件模型的区别在于，服务模型的表示层从逻辑层分离出来，中间增加了服务对外的接口层。服务接口的意义在功能上表现为:更多、更灵活的

功能可以在服务接口中实现。此外，更加突出的变革性突破在于，通过服务接口的标准化描述从而使得该服务可以提供给在任何异构平台和任何用户接口使用。这允许并支持基于 web 服务的应用程序成为松散耦合、面向构件和跨技术实现。调用程序很可能根本不知道该服务在哪里运行是由哪种语言编写以及消息的传输路径。只需要提出服务请求，然后就会得到答案。同时，由于服务模型中的业务逻辑构件之上增加了一层可以被大部分系统都认可的协议，从而使得系统的集成不再是一个问题。

SOA 是一种粗粒度、松耦合的服务架构，其服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。这种模型具有下面三个特征。

(1)松散耦合。SOA 是松散耦合构件服务，这一点区别于大多数其他的构件架构松散耦合旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。大多数松散耦合方法都依靠基于服务接口的消息，基于消息的接口能够兼容多种传输方式，可以采用同步或异步协议实现。

(2)粗粒度服务。服务粒度(Service Granularity)指的是服务所公开功能的范围一般分为细粒度和粗粒度，其中，细粒度服务是那些能够提供少量商业流程可用性的服务。粗粒度服务是那些能够提供高层商业逻辑的可用性服务。选择正确的抽象级别是SOA建模的一个关键问题。设计中应该在不损失或损坏相关性、一致性和完整性的情况下，尽可能地进行粗粒度建模。通过一组有效设计和组合的粗粒度服务，业务专家能够有效地组合出新的业务流程和应用程序。

(3)标准化接口。SOA 通过服务接口的标准化描述，使得该服务可以提供给在任何异构平台和任何用户接口中使用。这一描述囊括了与服务交互需要的全部细节，包括消息格式、传输协议和位置。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。

面向服务的分析与设计

从概念上讲，SOA 有三个主要的抽象级别，分别是操作、服务和业务流程。其中位于抽象最低层的操作代表了单个逻辑单元的事物。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作可以直接与面向对象的方法相比，它们都有特定的结构化接口，并且返回结构化的响应，完全与方法一样。位于第二层的服务代表了操作的逻辑分组。最高层的业务流程则是为了实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。在 SOA 术语中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。其中操作的排序、选择和执行成为服务或流程的编排，典型的情况是调用已编排服务来响应业务事件。

从建模的观点来看，SOA 带来的主要挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。针对这个问题，Olaf Zimmerman和Pal Krogdahl综合了OOA，OOD企业架构(Enterprise Architecture,EA)框架和业务流程建模(Business Process Modeling，BPM)中的适当原理，将这些规则中的原理与许多独特的新原理组合起来，提出了面向服务的分析与设计(Service-Oriented Analysis and Design，SOAD)的概念，OOAD、EA 和BPM 分别从基础设计层、应用结构层和业务组织层三个层次上为SOAD 提供了理论支撑。其结构如图 所示。

(1)底层设计层。采用了OOA 和 OOD 的思想其主要目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的底层服务构件。对于设计已定义的服务中的底层类和构件结构，OO是一种很有价值的方法。但是，目前与 SOAD 有关的OO设计在实践中也存在着一些问题:OO的粒度级别集中在类级，对于服务建模来说，这样的抽象级别太低。诸如继承这样的强关联产生了相关方之间一定程度的紧耦合。与此相反，SOAD试图通过松耦合来促进灵活性和敏捷性，这使得00 难以与 SAD架构保持一致

(2)架构层。采用了 EA 的理论框架。企业应用程序和IT 基础架构发展成SOA是一个庞大的工程，其中可能会涉及到众多的业务流水线和组织单元。因此，需要应用 EA架构，以努力实现单独的解决方案之间架构的一致性。在 SOA 中，架构层必须以表示业务服务的逻辑构件为中心，并且集中于定义服务之间的接口和服务级协定。

(3)业务组织层。采用了 BPM规则。BPM 是一个不完整的规则，其中有许多不同的形式、表示法和资源，其中应用较为广泛的是UML。SOA 必须利用所有现有的BPM方法作为SOAD的起点，同时需要服务流程编排模型中用于驱动候选服务和它们的操作的附加技术来对其加以补充。

此外，SOAD 中的流程建模必须与设计用例保持同步。SOA 是一种企业系统架构，它是从企业的业务需求开始的，但是，SOA 比其他企业架构方法具有明显优势的地方在于SOA 提供了业务的敏捷性。业务捷性是指企业对业务的变化能更快速和有效地进行响应，并且利用快速变更来得到竞争优势的能力。要满足这种业务敏捷性，SOA 必须遵循以下原则。

(1)业务驱动服务，服务驱动技术。在抽象层次上，服务位于业务和技术之间，业务处于主导地位，业务的变化需要服务的重新编排和组合，服务的编排和组合可能会带来实现细节的变化。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系;另一方面，同样要理解服务与提供这些服务的底层技术之间的关系;最后，需要设计良好的服务动态组合来应对多变的业务逻辑，这也是 SOA 最核心的问题。

(2)业务敏捷是基本的业务需求。SOA 考虑的是提供响应变化需求的能力是新的“元要求”，而不是一些业务上固定不变的需求。系统整个架构都必须满足敏捷需求，因为在 SOA 中任何的瓶颈都会影响到整个系统的灵活性。因此，架构设计师需要将敏捷的思想贯穿在整个系统设计中。SOA的目的就是应对变化，其最高准则是“以不变应万变”，也就是以尽量少的变化成本应对不断变化的业务需求，具体来说，就是通过现有的可重用性服务的重新组合来应对新需求。

Web服务实现SOA

在采用 Web 服务作为 SOA 的实现技术时，该系统应该至少分为6个层次:底层传输层、服务通信协议层、服务描述层、服务层、业务流程层和服务注册层。

(1)底层传输层。底层传输层主要负责消息的传输机制，HTTP、JMS 和SMTP 都可以作为 Web 服务的消息传输协议，其中HTTP 使用最广

(2)服务通信协议层。服务通信协议层的主要功能是描述并定义服务之间进行消息传递所需的技术标准，常用的标准是 SOAP 协议，还有新出现的REST (RepresentationaState Transfer)协议。

(3)服务描述层。服务描述层主要以一种统一的方式描述服务的接口与消息交换方式，相关的标准是WSDL。

(4)服务层。服务层的主要功能是将遗留系统进行包装，并通过发布的 WSDL接口描述被定位和调用。

(5)业务流程层。业务流程层的主要功能是支持服务发现，服务调用和点到点的服务调用，并将业务流程从 Web 服务的底层调用抽象出来。相关的标准是WS-BPEL(WebService-Business Process Execution Language，Web 服务业务流程执行语言)。

(6)服务注册层。服务注册层的主要功能是使得服务提供者能够通过 WSDL 发布服务定义，并支持服务请求者查找所需的服务信息。相关的标准是UDDI。