SOA是什么？

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/WebService技术之后的自然延伸。

SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

4.2.3.1 SOA 的概念

SOA 是一种架构模型，它将应用程序的不同功能单元(即服务)通过服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。

不同的厂商和个人对 SOA 有如下不同的定义:

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

(2)Looselycoupled.com 将 SOA 定义为: “按需连接资源的系统。在 SOA 中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA 规定了资源间更为灵活的松散耦合关系。”

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

虽然不同厂商或个人对 SOA 有着不同的理解，但是从以上定义可以看出 SOA 的几个关键特性: 一种粗粒度、松散耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

SOA 并不是一种现成的技术，而是一种架构和组织 IT 基础结构及业务功能的方法。SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)的模型。SOA要求开发人员将应用设计为服务的集合，以及跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服务，由此来实现重用。

4.2.3.2 构成 SOA 的技术

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

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

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

4.2.3.3 SOA 的基本特征

SOA 是一种粗粒度、松散耦合的软件架构，其服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。这种模型具有下面几个特征(http://tech.ccidnet.com/art/1110/20060210/425863_ 1.html)［U1］。

(1)松散耦合。服务请求者到服务提供者的绑定与服务之间是松耦合的。松散耦合旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务接口作为与服务实现分离的实体而存在，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台等等。服务请求者往往通过消息调用操作请求消息和响应而不是通过使用文件格式。服务实现的修改完全不会影响到服务的使用者。

(2)粗粒度服务。服务粒度指的是服务所公开功能的范围，一般分为，细粒度和粗粒度。其中，细粒度服务是那些能够提供少量业务流程可用性的服务。粗粒度服务是那些能够提供高层业务逻辑的可用性服务。粗粒度服务可以灵活组合稳定性强、重用性高的细粒度服务，而快速形成新的业务逻辑。虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。

(3)标准化的接口。服务描述的重点在于与几部分交互所用的操作服务、调用操作的消息、构造这种消息的细节和关于向何处发送用于构造这种消息的处理细节的消息。通过服务接口的标准化描述，从而使得该服务可以提供给在任何异构平台和任何用户接口使用。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。

(4)无状态服务。服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好定义成通用业务流程、函数和数据模型，而不是实现构件比如会话密钥。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分开。

---