应用逻辑

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

从而强调了：

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

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

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

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

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

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

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

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

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

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

应用处理

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

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

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

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

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

技术

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

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

安全

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

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

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

管理

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

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

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

3.4. 比较SOA与混合Web服务架构

在前一节中，我们提到最近的分布式互联网架构变化已如何成为混合Web服务。这一主题值得详细说明，因为它已经是(并预期继续是)SOA周围的混乱之源。

首先，传统架构内使用Web服务是完全合理的。由于许多编程语言都支持对Web服务的开发，他们可轻易地将其嵌入老的应用设计。并且，对于那些不支持Web服务定制开发的遗留环境，通常也可用适配器的方法来解决。

注意

尽管我们集中于分布式互联网架构，但并没有限制两层客户-服务器的应用使用Web服务。

Web服务作为构件包装器

Web服务在这个语境中的主要角色已引进了一个包含包装器服务的整合层，促成经由SOAP兼容的集成通道的同步通信(图4.7)。实际上，SOAP规范初始发布和第一代SOAP服务器都被特别设计用来复制使用消息的RPC风格的通信。

这些集成通道主要在集成结构中，被用以促进与其他应用或外部合作伙伴的通信。也被用于促成与其他(更多的面向服务)解决方案通信，还可利用第三方工具提供的Web服务。不管他们在传统架构中的使用或目的，关键是要澄清靠这种方式在分布式互联网架构中纳入Web服务不具备真正的SOA资格。这只是使用Web服务的分布式互联网架构。

并非是反映构件接口和用Web服务建立点对点连接，SOA提供了对于不同通讯模型的强健支持(基于同步和异步的交换)。另外，在SOA内的Web服务受制于特定的设计需求，象由面向服务原则提供的那些。这些和其他的特征都支持对和谐的松散耦合的追求。一旦实现，单个服务不再限于点对点通信;它能够适应任何的现在和未来的请求者。

SOA内部的Web服务

然而SOA在大小和品质方面会有所不同，SOA与其他架构在Web服务的使用方面有切实不同的特征。本书主要专注于探索这些特征。目前已经充分阐明:基本上，SOA构建于一组Web服务，它们被设计用于一个或多个电子商务流程的集体自动化(或者参与自动化的)，SOA促进将这些服务组织成抽象企业自动化逻辑特定部分的特定层。

同样通过跨企业的标准SOA，出现了天然的协同性，超越了专有的应用平台。这考虑到先前不同的环境组成，以支持新的和进化的业务自动化过程。