SOA进化之SOA的根源(3)

　　除了一些罕见的应用以专有扩展的方式嵌入到浏览器中以外，分布式互联网应用将其所有应用逻辑放在了服务器端。甚至客户端脚本想要执行在网页上的一个事件响应，都要从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，还有定制解决方案。