内容简介

SOA 是英文 Service-Oriented Architecture ，即面向服务架构的缩写。这个词汇最近一两年频频出现在各种技术期刊上。但是一直以来对于 SOA 到底是什么没有明确的回答； SOA 有什么特点？适合用于解决哪些问题？与其他的技术有什么区别与联系？ Web Service 和 SOA 又是什么关系 ？ SOA 的出现对于软件架构设计有什么影响？本文将就上面提到的这些问题，尝试根据作者自己的理解给出 SOA 的定义；总结出 SOA 特有的三个基 本特征；然后以 HTTP 协议为例对这些特征进行解释；最后简要的说明 SOA 对今后软件架构设计可能带来的影响。

SOA 定义

下面是作者给 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 层。