SOA的根源——选自《SOA：Concepts,Technology,and Design》

4.3.SOA的根源（比较SOA和过去的架构）

现在我们回过头来看一下过去的架构平台和SOA之间的不同之处。这是一项有趣的学习，我们可以从中得知SOA的一些当前特征是如何得来的。

 

注意

本节解释了很多传统的架构，但是SOA的架构细节还要到本书的后面部分才能给出。因此本节并不是阅读以下章节所必需的，如果你对SOA与其他架构的区别不感兴趣的话，可以跳过这一节直接转到第五章。

 

4.3.1 .什么是架构？

从计算机自动化处理的解决方案出现时起，架构技术就存在了。然而，在过去的环境中，解决方案的架构太简单直接了，以至于我们很少去抽象和定义它的架构。

随着多层应用的兴起，应用赖以生成的各式各样的架构变得非常繁多，。IT部门开始认识到需要对某一个基准应用给出标准化的定义，这样可以使它作为其他应用的模版。 这个定义从性质上说是抽象的，但是明确地解释了适用于基于这个模版的所有解决方案的技术、边界、规则、局限和设计特点。这就是应用架构的由来。

 

应用架构

应用架构对于一个应用开发小组来说，就像蓝图对于一个建筑工人小组的作用一样。不同的组织用文档表述出不同层次的应用架构。有的文档从高层次上进行表述，提供对此技术蓝图的抽象的物理表示和逻辑表示。另一些文档则包括更多的细节，，如通用数据模型，通信流图，应用范围内的安全化需求和基础设施的一些方面。

一个组织拥有多个应用架构并不少见。一个架构文档通常就一种特定的解决方案环境。例如，一个同时拥有.Net和J2EE解决方案的组织很可能为每种解决方案都分别配有一套应用架构规范。

无论哪种应用层次的架构，都有一个关键部分，它反映了当前的解决方案的需求，同时也给出了长期的、战略性的IT目标。当一个组织内存在着多个应用架构时，总会有一个占统治地位的企业级架构，其他架构与之协调并保持一致。

 

企业架构

在较大的IT环境中，控制和指导IT基础设施是极其重要的。当多个不同的应用架构共存甚至集成时，对支撑它们的平台的要求可能会复杂而繁重。因此，通常要创立一个主规范，对企业内存在的所有异构的形式以及支持它们的架构的定义给出一个高层次的概括说明。

继续用我们先前的类比，一个企业架构说明对于一个组织来说，就像一个城市规划对于一个城市的作用一样。因此，一个总的城市规划和一幢建筑物的蓝图之间的关系，就像企业架构说明和应用架构说明的关系一样。

典型地，企业架构的变化直接影响着应用架构，这也就是为什么架构说明总是由同一些人来维护。此外，企业架构通常包含一个组织计划如何改进它的技术和环境的长远目标。例如，逐步淘汰一个过时的技术平台的目标就可以建立在这种说明中。

最后，此架构文档还可以定义企业范围的安全措施所包含的技术和策略。不过，这些部分通常被独立放在另一个安全架构规范中。

 

面向服务架构

简单地说，面向服务架构横跨了企业架构和应用架构领域。只有当跨越了多个解决环境时，SOA可以提供的潜在利益才能真正被人们意识到。这就是用基于供应商重力的童心平台建造可重用和科互操作的服务时的投资可以被充分平衡的地方。。这并不意味着整个企业必须成为面向服务的。SOA应归于那些能尽量从它所引进的特点和特色中获益的领域。

注意“SOA”这个术语，它并不特指一个特定的架构范围。SOA可以指一个应用架构，也可以指使整个企业的技术架构标准化的方法。由于SOA的可组合的本性（意思是单个的应用层架构可以由不同的扩展和技术组成），一个组织拥有不止一个SOA是完全有可能的。

注意，像上一章所解释的，web服务平台提供SOA多种实现方法的一种。它是本书专门研究的方法，但是其他方法也是存在的，如传统的分布式平台提供的方法。在接下来的几节和贯穿全书的一个重要的术语是我们用的“SOA”，它指的是现代SOA模型（基于web服务和面向服务原则），这些将在第三章讲到。

4.3.2 .SOA与客户/服务器架构

  几乎任意一个软件从另一个软件处请求或接收信息的环境都可以被称作“客户——服务器”。现存的应用架构每一个变种几乎都包含客户——服务器交互。然而，行业术语“客户/服务器架构”通常指的是早期环境中的特定的产物，那时的客户和服务器扮演了特定的角色并且有其独特的实现特点。

客户/服务器架构：简史

最初的单片主机系统可以使组织被严格地计算机化，它经常被认为是客户/服务器架构的原型。大容量的大型机后端为瘦客户端服务的环境可以看作是单层客户/服务器架构的一个实现。

图4.2 一个典型的单层客户/服务器架构

 

大型机系统支持同步和异步通信。后者的实现最初是用来允许服务器连续地从终端接收字符作为对每个按键敲击的响应。事实上只有在某些条件下服务器才会做出反应。

虽然它的遗留系统依然存在，随着80年代后期两层客户/服务器设计的出现，大型机作为首要计算平台的统治地位开始走下坡路。

这种新的途径在单个的工作站上引进了代表逻辑和处理责任的概念，导致了胖客户的产生。此后在90年代早期，有了图形化用户界面（GUI）的支持，两层客户/服务器被看作前进道路上一次巨大的飞跃，并统治IT世界多年。

这种架构的通用配置由多个胖客户组成，每个客户都与一个中心服务器保持一个连接。客户端软件做大量的处理，包括所有的和表示相关的逻辑和大多数数据访问逻辑(图4.3)。一个或多个服务器通过集合可升级的RDBMS（关系数据库管理系统）管理这些客户。

图4.3 一个典型的两层客户/服务器架构

 

我们来看一下两层客户/服务器架构的基本特征并和SOA的相对应的部分作一个比较。

应用逻辑

客户/服务器环境把大部分应用逻辑放在客户端软件中，产生一个可执行的单片机控制用户的行为及后端的资源。一个例外是业务规则的分派。一种流行的趋势是在数据库的存储程序和引擎中嵌入和维护业务规则，并使业务规则和数据相关联。这样就把一部分业务逻辑从客户端抽象出来并简化了数据访问程序。虽然还是由客户端运行程序。

现代面向服务解决方案中的表示层可以改变。任何一个根据请求服务协议能交换SOAP消息的软件都可以被归为一个服务请求者。由于请求者也可以提供服务，一个解决方案表示层的设计是完全开放和需求明确的。

在服务器环境中，关于应用逻辑可以放置在何处、如何分布，有多种选择。这些选择不排除利用数据库引擎或存储程序。然而，按照面向服务设计原则，通常要求把处理逻辑划分到自动处理单元中。这样可以提高详细设计的质量，例如无状态服务和互用性，还有将来的可组装性和可重用性。

另外，在SOA中，这些处理逻辑单元通如何工作通常是不可知的。这支持了在应用程序边界提高可重用性和松耦合的最终目标。

应用处理

由于大多数客户/服务器程序逻辑放置在客户端组件中，客户端工作站负责大量的处理工作。从以往的经验来看，客户端处理80%的工作而数据库服务器通常处理20%。尽管如此，经常成为性能瓶颈的仍然是数据库。

一个大用户基的两层客户/服务器解决方案通常要求为每个客户建立一个数据库连接。可以预知，通信是同步的，而且这些连接经常是持久稳固的（意思是用户登录后生成连接，连接一直处于活动状态直到用户退出程序）。私有数据库连接的开销是昂贵的，资源需求有时会使数据库服务器不堪重负，给所有的用户带来处理上的延迟。

另外，如果给客户端分配大部分的处理工作，它们会频繁请求大量的资源。客户端操作是完全记录状态的并且会消耗固定的大块内存。因此用户工作站只运行客户端程序，这样所有可用的资源才能被提供给应用。

SOA中的处理是高度分布式的。每个服务都有一个显式的功能边界和相关的资源需求。在设计一个面向服务的架构时，关于如何配置和部署服务有多个选择。

企业解决方案由多个服务器组成，每一个都拥有几套web服务并且支持中间件。因此SOA没有固定的处理比率。服务可以根据需求被分派，性能需求只是决定物理部署配置的因素之一。

服务器和请求者之间的通信可以是同步的或异步的。这种灵活的特性允许处理可以被改进，尤其是使用异步消息方式通信时。另外，通过把大量的信息放在消息中，可以在消息水平上管理消息，这样促进了服务的无状态和自主的特点，通过减少状态信息实时缓存的需求进一步减轻了处理工作的负荷。

技术

客户/服务器应用的出现推动了第四代编程语言的使用，如Visual Basic和PowerBuilder。这些开发环境工具可创建美观和更富交互性的用户界面，进一步发挥了Windows操作系统的优点。尽管传统的第三代编程语言仍然在使用，如C++，尤其对于性能要求更严格的解决方案。后端的主流数据库供应商，如Oracle，Informix, IBM, Sybase和Microsoft，提供健壮的RDBMS（关系数据库管理系统），在提供灵活的数据存储和数据管理的同时，可以管理多个连接。

SOA使用的技术集并没有随它扩展程度而改变多少。旧编程语言的新版本，如Visual Basic，仍然可以用来创建web服务，关系数据库的使用仍然是很平常的。SOA的技术前景是无可限量的。在标准web技术（如HTML，CSS，HTTP等）的基础上，现代SOA给我们带来了：建立一个XML数据表示架构的全部必要条件，一个SOAP消息框架，和一个由不停扩展的web服务平台组成的服务架构。

安全性

除了数据的存储和管理、嵌入在存储程序和引擎中的业务规则，在客户/服务器架构中另一个经常受到关注的方面是服务器端的安全性。数据库可以精确地管理用户帐号和组，并把它们分配给物理数据模型的独立部分。

客户端操作的安全性也是可以控制的，特别当它涉及到执行应用逻辑的详细业务规则（如通过限制用户访问界面的一部分来选择用户）。另外，可以和操作系统级的安全结合在一起，通过单一的登录，从用户的操作系统登录帐号信息处获得安全保障

虽然我们极力夸赞SOA的种种优点，但是大多数的体系架构者们还是很羡慕客户/服务器架构的安全性之简单。在客户和服务器之间建立一个简单的连接，公共数据就可以通过一个确认点得到保护。在SOA的分布式环境中，这是不可能的。安全性成为一个和安全措施要求级别直接相关的重大的难点。其中涉及到很多组成WS安全框架的技术（详见第7章和第17章）。

管理

造成客户/服务器时代结束的一个主要原因是日益增大的分布式和用户工作站的应用逻辑的维护开销。由于每个客户都有一套程序代码，每次更新应用程序都要求对所有的工作站重新分配客户软件。在更大的环境中，这将会导致管理过程特别繁重。

客户端和服务器端都要作维护工作。客户工作站遭遇了特定环境的问题，因为不同的工作站可能会安装不同的软件程序，或从不同的硬件供应商处购买。此外，在服务器端对数据库的请求会增多，尤其当一个客户/服务器应用扩展到一个更大的用户基时。

由于面向服务的解决环境可以有多种请求者，它们会受到客户端维护的影响。当它们的分布式后端能够容纳应用程序和数据库服务器，会产生新的管理需求。例如，一旦SOA发展到这样一个境地，服务可被重用并成为多服务组合的一部分，服务器资源和服务接口的管理会要求强大的管理工具，包括私有注册的使用。

4.3.3 .SOA与分布式互联网架构

这个比较看起来可能有点矛盾，因为SOA可以被看作分布式互联网架构的一种形式，我们以前建立的分布式互联网架构也可以被设计成SOA。虽然有可能，而且以前就曾出现过分布式环境并深深地影响了面向服务设计原则，这种SOA的变种仍然很稀少。把这个比较看作SOA和传统的分布式互联网架构在设计上的共同之处作的一个对照。

分布式互联网架构：简史

为了解决两层客户/服务器架构的开销和局限性问题，建立基于组件的应用的概念逐渐成为主流。多层客户/服务器架构出现了，它结束了单片客户的执行，被设计成组件化，这个改变符合面向对象的思想。

多组件的分布式应用逻辑（一些放置在客户端，另一些放置在服务器端）通过把大量的逻辑集中在服务器上减少了部署上的难题。服务器端组件，现在放置在专门的应用服务器上，可以共享和管理数据库连接池，减轻了当前对数据库服务器的访问的负载（图４.4）。一个单独的连接可以很容易地服务多个用户。

图4.4 一个典型的多层客户/服务器架构

这些优点是以增加复杂性为代价的，不再需要从部署方面到开发和管理过程所需的转换开销和努力。相对于开发一个针对单个用户的直接的可执行程序，建立有能力处理多个并发请求的组件更难更容易出现问题。

另外，代替客户/服务器数据库连接的是客户/服务器远程过程调用（RPC）连接。RPC技术（如CORBA和DCOM）允许放置在客户工作站和服务器上的组件间的远程通信。与客户/服务器架构问题相同的部分涉及到资源和持久连接的问题。还有由于引进中间件层所导致的日益增大的维护开销。例如，在更大的环境中，必须密切关注应用服务器和事务监控器。

在90年代中后期，随着万维网作为交互媒介的计算机技术的时代来临，多层客户/服务器环境开始和互联网技术共同协作。浏览器代替了定制软件客户组件，成为一项重大的突破。这不仅从根本上改变（限制）了用户界面的设计，还几乎把100%的应用逻辑都转到了服务器上。（图４.5）

图4.5 一个典型的分布式互联网架构

分布式互联网架构同时引进了一个新的物理层——Web服务器。这导致了HTTP取代了过去在用户工作站和服务器之间通信的私有RPC协议。RPC在远程Web和应用服务器之间的通信上能力有限。

从90年代后期到2000年中期，分布式互联网架构代表了为定制开发企业解决方案事实上的计算平台。基于组件的编程技术的日常化使用和中间件的日益完善，最终在一定程度上减少了总体的复杂度。

那么，这个流行而又常见的架构和SOA比起来怎么样呢？下面的几个部分将分布式互联网架构和SOA的特点作了一个对照。

注意

尽管多层客户/服务器是一个不同的架构，我们不给出它和SOA直接的比较。客户/服务器架构和分布式互联网架构比较的大部分方面将会在多层客户/服务器架构与SOA的比较中讨论。

应用逻辑

除了少数应用把业务功能嵌入在浏览器中，分布式互联网应用把它们全部的应用逻辑都放置在服务器端。即使客户端可执行脚本也是通过初始的HTTP请求从web服务器上下载的，作为对一个网页事件的响应。整个解决方案是集中式的，在客户工作站上没有一点应用逻辑。

因此我们要强调的是：

l         应用逻辑如何划分

l         处理逻辑划分的单元应该放置在何处

l         处理逻辑单元如何交互

从物理角度上看，面向服务架构和分布式互联网架构非常相像。供给者的逻辑作为分散的单元放置在服务器上。不同之处在于决定上面罗列的三个设计考虑点的原则。

传统的分布式应用由一系列放置在一个或多个应用服务器上的组件组成。组件被设计成具有不同的功能粒度，这取决于它们所执行的任务，以及在什么程度上它们可以被其他任务或应用重用。放置在同一个服务器上的组件之间通过私有API进行通信，每个组件都对外提供一个公共接口。RPC协议用来实现服务器之间的通信。这是通过使用代表远程组件的本地代理桩程序来实现的（图４.6）。

图4.6 远程通信中代理桩程序的组件

在设计的时候，组件之间预期的交互被考虑得最多，这样，对其它物理组件的实际引用可以被嵌入到程序代码当中。这种水平上的设计时依赖是紧耦合的一种形式。对于那些小的处理是有效的，对于试图在运行时定位一个所需的组件就是浪费了。然而，嵌入的耦合会导致过紧的组件边界网络，一旦实现就不容易改变了。

现代SOA仍然使用和依赖组件。然而，整个建模方法现在考虑建立封装部分或全部组件的服务。这些服务按照面向服务原则来设计，策略上提供特定的功能集。这个功能可以由组件来提供，也可以从遗留系统和其他资源处获得，如打包的软件产品和适配器接口甚至数据库。

把功能封装到一个服务中，目的是通过一个开放的、标准化的接口对外提供功能，而不管底层逻辑的具体实现技术。这个标准化的应用接口支持SOA核心的开放通信框架。此外，使用web服务可以建立一个与很多传统的分布式应用设计不同的松耦合环境，。如果恰当地设计，松耦合服务支持组合模型，允许单个的服务参与集合，这为将来的重用和扩展创造了机会。

另一个关于分布式应用逻辑设计和实现的巨大转变是服务如何交换信息。传统的组件提供这样的方法，一经调用，发送和接收参数，web服务就会通过SOAP消息进行通信。尽管SOAP支持RPC类型的消息结构，大部分面向服务的Web服务在设计上依赖文档类型的消息。（这个重要的区别将在接下来的几章探讨）

消息尽可能地被设计成可以定义自身的结构。通过使用SOAP header，消息内容中可以带有很多元信息、处理指令和规则。与纯组件间数据交换相比，SOA使用的消息框架更加复杂和完备，容量更大，可以减少单个传输。

最后，尽管在传统的分布式设计方法中，重用经常被强调，SOA通过建立解决方案未知的服务，在深层次上鼓励了可重用性和跨程序协作性。

应用处理

不管什么平台，组件表示了最大部分的应用逻辑，因此负责大多数的处理。然而，由于内部组件通信所使用的技术和实现内部服务通信所使用的技术不同，其处理需求也不同。

分布式互联网架构促进了私有通信协议的使用，如DCOM和供应商为远程数据交换而实现的CORBA。尽管这些技术以前都曾经受到过挑战，它们被认为是相对有效和可靠的，特别是当一个活动的连接建立的时候。它们可以支持主要与同步数据交换的交互组件的建立，无论它是有状态或是无状态的（异步通信由一些不常用的平台支持）。

SOA，从另一个方面来看，依赖基于消息的通信。这其中涉及到对包含XML文档的SOAP消息的序列化，传输和反序列化。处理过程涉及到把相关数据转换成XML支持的结构，传输前后XML文档的确认，接收方对XML文档的解析和数据抽取。尽管有了一定的进步，如使用企业级解析器和硬件加速器，人们还是认为RPC通信比SOAP要快得多。

在面向服务应用环境中，一个由SOAP服务器组成的网络可以有效地取代RPC类型的通信方式，由此引发的处理开销成为一个不容忽视的设计问题。文档和消息建模惯例和确认逻辑的策略化布置是塑造面向服务架构的传输层的重要因素。

这个消息框架促进了支持各种消息交换方式的自主服务的建立。尽管完全支持同步通信，异步通信方式通过减少通信量优化处理。可以选择各种范围的管理支持无状态服务，包括WS规范（如WS-Coordination和WS-BPEL）和定制解决方案。

技术

在过去的几年中，分布式互联网架构所使用的技术经历了许多阶段。最初的架构由组件、服务器端脚本和原始的Web服务（如HTML和HTTP）组成。中间件的改进允许增加的处理能力和事务控制。XML引进的精确的数据表示法事实上充实了通过互联网协议传输的内容。Web服务的并发性使得分布式互联网应用可以跨越私有平台边界。

由于当前很多分布式应用使用XML和Web服务，这些解决方案使用的技术和基于SOA的解决方案所用的技术可能会有一点不同。一个明显的区别是，现代SOA大多建立在XML数据表示法和Web服务技术平台之上。除了使用互联网核心技术和组件之外，传统的互联网应用使用的技术无法管理。因此XML和Web服务对分布式互联网架构是可选的，但现代SOA不是。

安全性

应用逻辑分散在多个物理边界时，实现基础的安全措施（如验证和授权）会更难。

在一个两层客户/服务器环境中，一个单独的服务器端连接很容易使得用户的确认和公有数据的传输的安全性成为可能。。然而，当这种连接的唯一性不存在时，当数据需要在不同的物理层之间传输时，就需要新的安全性方法。为了确保信息的安全传输和用户身份的识别，在保留原先的安全性环境时，传统的安全架构和一些方法（如委托和模仿）整合。其他容易受到攻击的HTTP协议还使用了加密技术以保证数据在Web服务器之外的传输过程中被保护。

 SOA在安全性如何被整合与应用上作出了大的更改，从这个安全模型中分离出来。由于深深依赖WS安全框架建立的扩展和思想，SOA使用的安全模型强调在消息水平上安全逻辑的放置。SOAP消息提供header块，安全逻辑可以被放在header块中。这样，无论消息走到哪儿，其安全信息也跟到哪儿。这种方法被用来保留服务之间的单个自主和松耦合以及一个服务可以保持完全无状态的程度

管理

维护基于组件的应用涉及到追踪单个组件实例，追踪本地和远程通信问题，控制服务器资源需求，标准数据库管理任务。分布式互联网架构还引进了web服务器和附加的物理环境，此环境在解决方案执行时需要注意。因为，无论是本地还是外部组织的客户端，使用HTTP连接到这些解决方案，web服务器成为第一个正式联系的点。因此它必须被设计成可升级的，以便将来可以创建服务器群来共享资源池。

企业级SOA一般要求额外的运行时管理。相对基于RPC的数据交换来说，消息框架带来的问题（尤其使用异步交换方式时）更难被发现。这是由于关于消息如何交换存在着太多的变化了。RPC通信通常要求来自初始化组件的一个应答以指示成功或失败。当遭遇连接失败的情况时，就会执行一个异常处理程序。消息框架的异常处理可能更复杂但是不健壮。尽管目前WS系列的扩展已经可以较好地处理这些情况，在管理方面仍然需要付出很大的努力。

其他维护任务也是必要的，如资源管理（与组件管理类似）。然而，为了最大程度地增进可重用性和可组装性，在企业建立大量web服务时，私有注册是所需的管理基础设施的一个有用部分。UDDI是用来标准化这个接口仓库的技术之一，可以手动或者通过程序自动发现服务描述。

4.3.4 .SOA与混合web服务架构

在前面的部分中我们提到最近多个分布式互联网架构的变种如何与web服务整合。这个话题值得详细描述，因为它现在是（并预计将来也会是）一些关于SOA的困惑的根基所在。

首先，使用web服务的传统架构是完全合理的。由于有用确定的语言编写的web服务开发支持，它们可以很容易地适应旧有的应用设计。而且，对于那些不支持定制开发web服务的遗留环境，可以使用适配器。

注意

虽然我们现在关注的是分布式互联网架构，两层客户/服务器应用在与web服务配备时没有限制。

Web服务作为组件包装

Web服务在此的最初角色是引进一个由封装的服务组成的集成层， 这些服务可以通过SOAP集成通道达到同步通信（图4.7）。事实上，SOAP规范的最初版本和第一代SOAP服务器被专门设计成使用消息来复制RPC类型的通信。

图4.7 封装服务组件

这些集成通道最初被用在集成架构上来实现与其他应用或外部设备的通信。它们也被用来与其他（大部分是面向服务的）解决方案通信，并利用第三方web服务产品提供的某些特点。不管它们在传统的架构中用途或目的为何，重要的是搞清楚用这种方式与web服务整合的一个分布式互联网架构，并不是真正意义上的SOA。它只不过是一个使用Web服务的分布式互联网架构。

SOA为多种消息模型（基于同步和异步交换）提供强大的支持，而不反映组件接口和建立同web服务的点对点连接。另外，SOA中的web服务受详细设计需求（如面向服务规范提供的）的支配。这些和其他特性支持长久的松耦合。一旦实现，一个单个的服务再不会被限制在点对点通信，它可以容纳许多当前或将来的请求者。

 

SOA中的web服务

SOA可以在尺寸和质量上变化，但确实存在着一些特性可以把SOA和其他使用Web服务的架构区分开来。本书大部分都在探索这些特性。现在可以充分证明，SOA使用一套web服务共同地自动处理一个或多个业务流程，SOA推动这些服务的组织到特定的层，这些层抽象出企业自动控制逻辑的确定的部分。

通过在一个企业中SOA的标准化，具有了超越以往应用平台的协同工作能力。这允许先前的异构环境可以被组合，以支持新的和发展中的业务自动化流程。

4.3.5 .面向服务和面向对象（第1部分）

注意本节的标题是“面向服务和面向对象”，而不是“面向服务对比面向对象”。两者的不同在于前者强调这两派观点之间的关系，后者则注重比较。

事实上，面向对象编程经常被用来在web服务中封装应用逻辑。然而，面向对象编程方法和面向服务在根本上的区别是值得探讨的。理解它们之间的不同有助于你更好地工作。

下面是关于二者的设计方法的一个比较。（面向服务基于服务的设计，面向对象关注对象的建立。由于比较服务和对象容易使人感到困惑，这里用了术语“处理逻辑单元”。）

l         面向服务强调处理逻辑单元（服务）之间的松耦合。尽管面向对象支持重用，松耦合编程方法，大部分是建立在已经定义好的类上，导致处理逻辑单元间更紧的边界（对象）。

l         面向服务鼓励“粗糙的接口”（服务描述），这样每个通信（消息）单元包含一个给定任务尽可能多的信息。面向对象编程完全支持“精细的接口”（API），这样通信单元（RPC或本地API调用）可以执行各种大小的任务。

l         面向服务可以预见处理逻辑单元（服务）可改变的范围。面向对象逻辑单元（对象）趋向于变得更小更详细。

l         面向服务促进建立活动未知的处理逻辑单元（服务），它是通过智能通信单元（消息）驱动的。面向对象鼓励把处理逻辑单元和数据绑定起来，导致高智能单元（对象）。

l         面向服务把处理逻辑单元（服务）尽可能地设计成无状态的。面向对象支持数据和逻辑绑定，可以创建出更多有状态的单元（对象）。（但是，最近越来越多的基于组件的设计方法偏离了这个方向。）

l         面向服务支持松耦合处理逻辑单元（服务）的组装。面向对象也支持组装，但也支持处理逻辑单元（对象）间的继承，而这可导致紧耦合依赖。

你可能已经注意到我们避免提到详细的面向对象规范，如封装，继承和聚合。因为我们还没有全面地描述面向服务的规范，我们无法在这个层次上比较它们各自的范例。第8章将详细解释面向服务规范，那时我们再在《面向服务和面向对象（第2部分）》继续讨论。

 

要点总结

l         SOA与客户/服务器架构有根本上的不同。目前的SOA仍然使用构建客户/服务器应用所需的部分技术。由于更加精细，SOA引进了复杂性，和两层客户/服务器架构的简单性形成鲜明对比。

l         分布式互联网架构与SOA有很多共同之处，包括其所使用的大量的技术。然而，SOA在技术和基础设计规范上都有其独特的特性。例如，SOA引进了处理和安全需求，这点和分布式互联网架构不同，SOA的管理由于依赖基于消息的通信而更加复杂。

l         传统的架构可以在它们的设计范例中继续使用web服务。不要把这些架构和SOA混淆是很重要的。在分布式互联网架构中经常使用非SOA的web服务，web服务被用来反映RPC类型的通信。