clant

3.3. 比较 SOA 与分布式互联网架构

这似乎有点自相矛盾，如果 SOA 可被视作分布式互联网架构的一种形式，同时我们初期建立早先类型的分布式架构也可被设计为 SOA 。尽管如此，且尽管现在的分布式环境可能已经深深地受到了面向服务原则的影响， SOA 这样的变化仍旧是罕见的。故而在此所提供的比较是将传统的分布式互联网架构作为其最常被设计的风格出现。

分布式互联网架构简史

为了对付两层客户服务器架构相关的成本与限制问题，构建基于构件应用的概念成为主流。多层客户 - 服务器架构浮出水面，将单独的客户程序分解成构件设计，成为符合面向对象的不同扩展。

在构件中不同的分布式应用逻辑（一些仍驻留在客户端，其他在服务器上），减少了大量逻辑都集中部署在服务器端的令人头痛的问题。服务器端构件，现在集中于应用服务器，从而可共享数据库连接管理池，减轻数据库并发访问的负担（ 图 4 ）。一个单连接就可轻易满足多用户要求。

图 4. 典型的多层客户 - 服务器架构。

获取这些效益的代价是复杂性的增加，并且最终转换为从部署问题到开发和管理过程的费用和努力。构建多样化处理能力的构件，并发请求比直接为单个用户开发一个可执行程序更困难，而且问题多多。

另外，替代客户 - 服务器数据库连接的是客户 - 服务器远程程序调用（ RPC ）连接。象 CORBA 与 DCOM 这样的 RPC 技术，准许客户工作站与服务器构件间进行远程通信。出现了类似客户 - 服务器架构的问题，包括资源及永久连接。增加这个新的维护是由于引入了中间件层。比如，在大型环境中对于应用服务器及事务监控需要特别关注。

随着万维网在 90 年代中后期成为一个计算技术的可用媒介，多层客户 - 服务器环境开始组成互联网技术。最重要的成就是软件构件被浏览器所替代。这个变化不仅从根本上改变（且限制）了用户界面设计，实际上还把 100% 的应用逻辑移到了服务器端 （ 图 5 ）。

图 5. 典型的分布式互联网架构

分布式互联网架构也引入了一个新的物理层， Web 服务器。这导致 HTTP 替代了专有的 RPC 协议而用于工作站与服务器间的通信。 RPC 的角色被限制到促成远程 Web 与应用服务器间的通信。

从 90 年代后期 2000 年中期，分布式互联网架构对于定制开发的企业解决方案而言，代表了事实上的计算平台。基于构件的日常编程技术及日益复杂的中间件，最终减少了一些整体复杂性。

那么，这个熟悉而又相似的架构该如何与 SOA 相比较呢？且看分布式互联网架构与 SOA 特征部分。

注意

尽管多层客户 - 服务器在其所有权内是一个独特的架构，我们不提供它与 SOA 之间的比较。大多数在客户 - 服务器及分布式互联网架构的比较中升级的问题，掩盖了将在多层客户 - 服务器与 SOA 的比较中讨论的问题。

应用逻辑

除了一些罕见的应用以专有扩展的方式嵌入到浏览器中以外，分布式互联网应用将其所有应用逻辑放在了服务器端。甚至客户端脚本想要执行在网页上的一个事件响应，都要从 Web 服务器基于初始的 HTTP 请求来下载。没有客户工作站上保存的逻辑，整个解决方案都是集中式的。

从而强调了：

• 应用逻辑应当如何被分割
• 被分割的处理逻辑应当驻留在何处
• 处理逻辑应当如何交互

从一个物理的角度来看，面向服务架构与分布式互联网架构非常相似。提供者逻辑驻留于服务器端而被分割成单独的单元。其中差异由刚刚所列三个主要设计原则所决定。

传统的分布式应用包含了驻留于一个或多个应用服务器上的一系列的构件。构件设计为不同粒度的功能，依赖于所执行的任务，以及它们被其他任务或应用的复用范围。驻留于相同服务器的构件通过专有 API 通信，按照它们暴露的公共接口来调用。 RPC 协议被用于实现跨越服务器边界的通信。这有可能通过使用代表远程构件的本地代理存根来实现（ 图 6 ）。

图 6 构件通信依赖于代理存根

在设计时，预期的交互构件将与其他一起考虑 --- 如此强烈以致实际对其他物理构件的引用可嵌入到程序代码内。这个设计时水平的依赖是紧耦合的形式。这样的稍许处理相对于试图在运行时定位所需构件的浪费而言是有效的。然而，嵌入式耦合导致绑定构件网络，一旦实现，不易更改。

当代 SOA 依然使用并依赖于构件。然而，整个建模方法现在会考虑创建封装一些或所有构件的服务。这些服务根据面向服务原则而设计，并且策略性地定位及暴露特定的功能集。同时这个功能可由构件提供，也可源自遗留系统及其他资源，象来自其它套装软件产品的适配器接口，或者甚至是数据库。

在服务内包装功能的目标是经由一个开放的、标准化的接口暴露功能 --- 而不用关心用于实现底层逻辑的技术。标准化的接口支持置于 SOA 核心的开放通信框架。而且，使用 Web 服务建立了松散耦合的环境，其中也运行着相对设计的分布式应用。如果设计得当，松散耦合的服务支持组合模型，允许单个的服务参与集合的设计。这引入了持续的复用与扩展机会。

有关分布式应用逻辑的设计与行为的另一个重要转变在于服务如何交换信息。当传统构件提供方法时，一旦被激活，就发送与接受参数数据，而 Web 服务通过 SOA P 消息通信。即使 SOA P 支持 RPC 风格的消息结构，大多数面向服务的 Web 服务设计却依赖于文档风格的消息。（这一重要差别在后面探究。）

消息也是结构化的并尽可能是自足的。通过使用 SOA P 报头，消息内容可以伴随阒宽泛的元信息、处理指导以及策略规则。与纯粹构件世界内的数据交换相比较， SOA 所用的通讯框架更加复杂、更加庞大，并且更易导致少数的个别传输。

最后，尽管也普遍强调复用传统的分布式设计方法， SOA 可通过促进解决方案未知服务的创建鼓励复用以及深层次的跨应用协同。

应用处理

不管什么平台、构件都代表了最大部分的应用逻辑并因此负责大多数的处理。然而，因为用于构件间通信的技术不同于完成服务间通信的技术，处理需求也是如此。

分布式互联网架构促进专有通信协议的使用，象用于远程数据交换的 DCOM 和厂商实现的 CORBA 。当这些技术遭遇历史性挑战时，它们相对是有效可靠的，特别是一旦有主动连接时。它们能够支持有状态和无状态构件的创建，主要影响同步数据交换（一些平台支持异步通信，但并未普遍使用）。

另一方面， SOA 依赖基于消息的通信。包括负载有 XML 文档的 SOA P 消息序列化、传输及去序列化。处理步骤会包括将关系数据转换成 XML 兼容结构、 XML 文档预校验以及随后的传输、以及对所接收文档进行解析和抽取。尽管已有所进步，譬如企业解析器及硬件的持续加速，大部分还是抱怨 SOA P 比 RPC 通信明显要慢一些。

在面向服务应用环境中，因为 SOA P 服务器的网络能够有效代替 RPC 风格的通信通道，导致系统开销成为一个重要的设计问题。文档与消息建模规约及校验逻辑的布置策略是重要因素，形成了面向服务架构的传输层。

这个通讯框架促进了自治服务的创建，支持宽泛的消息交换模式。尽管完全支持同步通信，但还是鼓励异步模式，因为它们提供了由通信最小化而带来的进一步优化的机会。深入支持无状态服务是不同语境的管理可采取的措施，包括使用 WS-* 规范，如 WS- 协调与 WS-BPEL ，还有定制解决方案。

技术

分布式互联网架构背后的技术在过去几年内经历了几个阶段。初始架构包含有构件、服务器端脚本以及原生的 Web 技术，比如 HTML 与 HTTP 。中间件方面的进步，允许增加处理能力及事务控制。 XML 的出现引入了复杂的数据表达，实际上提供了经由互联网协议传输的东西。后来 Web 服务的可用性允许分布式互联网应用跨越专有平台的边界。

因为许多当前的分布式应用使用了 XML 与 Web 服务，有可能这些解决方案背后的技术与那些基于 SOA 的没有太大不同。虽然一个明显的区别在于当代 SOA 将有可能构建在 XML 数据表达与 Web 服务技术平台技术之上。除了互联网核心技术集和构件的使用，没有被传统的互联网应用所统治的技术。因此， XML 与 Web 服务对于分布式互联网架构而言是可选的，但对于当代 SOA 不是。

安全

当应用逻辑散布于多个物理边界时，实现象鉴权与授权这样的基本安全措施变得更加困难。

在两层客户 - 服务器环境中，一个独有的服务器端连接可轻易实现用户论证及企业数据的传输安全。然而，当独立的连接被移除时，而且要跨越不同的物理层传播时，就需要新的安全方法。要确保信息的安全运输及用户凭证的识别、同时保留原始的安全语境，可用象委托和假冒这样传统的安全架构合成方法。加密也被加到其他广泛而开放的 HTTP 协议方面，可在 Web 服务器之外传送时受到保护。

SOA 通过引入对安全如何组合以及对应用的大规模改变，从而远离了这个模型。由于严重依赖 WS- 安全框架所建立的扩展和概念，在 SOA 中所用的安全模型在通讯层面上强调安全逻辑的安置。 SOA P 消息提供的报送区块中可存入安全逻辑。那样，无论消息在何方，安全也就随之而至。这个方法需要个体自治和服务间的松散耦合，同时一个服务可完全维持在无状态的范围。

管理

维护基于构件的应用包括跟踪单个构件实例、本地及远程通信问题，监控服务器资源需求，当然，还有标准化的数据库管理任务。分布式互联网架构进一步引入了 Web 服务器，同时解决方案执行时还需要关注额外的物理环境。因为客户 --- 不管本地的还是外部的组织 --- 使用 HTTP 连接到这些解决方案， Web 服务器就成为正式的第一接触点。因此它必须设计成可扩展的 --- 这一需求已导致 Web 服务器机器资源池的创建。

企业级 SOA 典型地需要一个额外的运行时管理。通讯框架带来的问题（特别是工作在异步交换模式时）会比基于 RPC 的数据交换的问题更不易发现。这是因为关于消息如何交换，存在太多的变化。 RPC 通信一般需要一个来自初始构件的响应，表明成功还是失败。遇到一个失败条件，就会抛出一个异常。通讯框架的异常处理可能更复杂而更不健壮。尽管 WS-* 扩展被定位于更好地处理这些情形，仍需努力保持高度管理。

其他维护任务，象资源管理（类似于构件管理），同样需要。然而，为了更好地促进复用性及可组合性，对于企业构建大量的 Web 服务而言，管理基础设施的一个很有用部分是私有注册。 UDDI 是一个标准化的技术，用于标准化地注册接口，能够手工或程序化地访问发现服务描述。