Web服务走向何方？

申请免费试用、咨询电话：400-8352-114

Web服务走向何方？

分布式计算技术的发展从来没有停止。就在你庆幸自己熟悉了如何设计分布式应用时，新的理论出现了，设计方法也随之改变。与此同时，从理论研究到理论在标准、商品化产品上应用之间，也存在一定的时间差。当你开始应用最新的发展成果时，下一次重大发展已经在研究和酝酿之中了。

一、革新之潮流

当前，用来构造Web服务的工具和规范仍有待进一步完善；尽管如此，即使在最原始的Web服务构造方法获得广泛应用之前，人们也已经开始审视Web服务的局限，探讨更有效的应用构造方法。Java通过JCP（Java Community Process）下面一个未见报道的工作组驾驶着这一轮的革新，即JSR-159 Java Process Component API。这个在2001年12月才组建的JSR最终会得出什么结论，仍有待观察。现在能够看到的只有一个规范需求说明。然而，过去几年中分布式计算研究的课题是该工作组的基础，而且随着在实践经验的基础上技术的不断改进，研究课题也将一直继续。
分布式计算支持多种应用开发模式。应用之间能够利用预先确定的协议，通过字节流实现通信。通信过程可以模式化成为过程调用，从而形成远程过程调用（RPC）机制。不同的网络服务可以视为带有不同方法的对象，在此基础上，我们得到了RPC的面向对象编程版本，即远程方法调用（RMI）。在应用中，组件之间的耦合可以是宽松的，也可以是紧密的；组件之间的消息传递可以是同步的，也可以是异步的。以队列形式缓冲的消息可以通过可靠的传输机制传递到任何可能的接收者，通过消息中包含的各种事件，应用的行为可以得到有效的控制。分布式计算应用可以按照多种途径组合和分拆。不过，除了科学计算领域的并行处理之外，当前的趋势是，应用各个组件之间的耦合应当尽量地宽松，从而提高组件的可重用性，方便组件的集成。这种趋势引导我们走向Web服务。在Web服务环境下，组件耦合的宽松程度达到了最大化（实际上不再相互耦合），组件具有最好的可重用性。同时，由于在Web服务环境下，通信依赖于平台中立的XML消息，因此组件的集成也比以前更加容易。
从根本上看，Web服务本身没有提供什么新的东西。从某种意义上来说，它只是一次从侧面对原有技术的革新。以前曾经有过分布式对象系统，但它的设计意图不是针对多个系统的相互通信。曾几何时，即使对于同一个系统，来自不同厂商的不同实现也不能相互操作（还记得IIOP之前的CORBA吗？）。你要么保证在所有应用开发中使用单一的分布式对象系统，要么使用某种起连接作用的桥式工具，听任应用的性能和可靠性由于使用桥接工具而降低。即使两个建立在不同对象系统基础上的服务在功能上完全符合应用的需求，试图让它们在同一个应用之内运行也会面临极大的风险。

二、解决应用集成面临的难题

人们期望Web服务能够解决所有应用集成过程中出现的问题。尽管Web服务的设计意图并不是完全被当作分布式对象使用，但它们也没有提供一种全新的编程模式。虽然所有服务之间的通信都以XML格式的消息为基础，但调用服务的基本途径主要还是RPC。在分布式计算技术发展的这一阶段，之所以要提出Web服务，是因为原有的技术无法实现多个系统的相互协作，继续向前发展已经很困难。有了Web服务，集成分布式应用中的各个组件就有了一个公共的框架，无需再考虑每一个组件的具体实现方式。

对Web服务的进一步改进将要如何进行呢？在回答这个问题之前，必须先理解Web服务的应用情况。更准确地说，是想象一下Web服务的应用情况，因为当前实际使用的基于Web服务的应用还不是很多。

简单、基础的Web服务不值得太多关注，它们就象是远程过程调用，只是调用通过一个XML消息进行，且消息具有遵从SOAP或XML-RPC之类规范的特定格式。它们只是通用服务模型下的一些特例。从理论的角度来看，服务是对事件的响应，而这里的事件又具有消息的形式。类似于RPC系统的服务只响应一种类型事件，即一个指定了方法名字和一组参数的调用，调用可能要求返回一个结果。按照这种模式构造的应用面临着与传统RPC和RMI系统同样的局限。过程调用需要昂贵的开销，要求通过广域网传输参数和返回值，与局域网相比，广域网的延时高、带宽小。如果调用是同步的，调用者还要等待调用返回。另外，这类调用的结果经常是下一次远程过程调用的输入参数，从而导致数据在网络上重复传输。而在通用服务模型下，服务能够响应任意事件，从而支持更复杂、更高效的数据流程。

如果应用的多个组件不必由正在运行程序的主线程分别地、单独地控制，那么，在把最终结果返回给主程序之前，处理的中间结果可以由一个组件传递给处理流程中的下一个组件。通过控制组件之间的输入、输出和调用流程，从几个基本的组件出发可以构造出大量不同的函数。
这种思想与二十世纪七十年代导致实现Unix管道的思想属于同一类型。不同之处在于，现在讨论的不再是进程之间字节流的流程，我们现在面对的是网络服务之间XML消息的流程。按照这种思路，Web服务被视为构造应用的基本模块，为尽可能地提高重用性，这种思路要求程序员更小心地进行设计。在这个基础上，Web服务趋向于复合式的Web服务，而不是各个服务孤立地存在。这里“复合”一词源于离散数学。在离散数学中，复合两个函数g(x)和f(x)得到g(f(x))。如果g和f是服务，它们的复合结果是把f服务的输出作为输入传递给g服务。

三、Web服务=可复合的函数

把Web服务视为可复合的函数能够简化分布式应用开发。理论上，新的服务可以作为一系列服务的有机组成部分方便地装配，而且这个过程不需要任何编程工作。可视化工具能够把多个服务按照合适的次序连接在一起，并生成实施复合操作所必需的消息代码。至于这类工具是否能够很快进入普通用户手中，或者说服务复合是否具有足够的吸引力达到广泛应用的程度，目前还不能确定。然而，JSR-159工作组看来已经相信，复合服务正是分布式组件技术发展的下一个目标。同一种思路，虽然那次是在模块粒度不同的一个层次上应用，曾经导致把Filter（过滤器）机制加入到Java Servlet 2.3 API。在Java平台的发展中，我们不断追求的就是尽可能地提高可重用性和尽可能地简化应用开发，如果借用一个面向概念编程技术的术语，那么其途径就是分离概念。

Java Process Component（JPC） API将建立在对象管理组织（OMG）的EDOC CCA规范的基础上（其中EDOC是Enterprise Distributed Object Computing的缩写，即企业分布式对象计算；CCA是Component Collaboration Architecture，即组件协作体系）。EDOC CCA规范已经指出了复合服务组件框架的许多细节。JPC的目标是成为J2EE未来版本的标准组成部分，但它不会取代Java Servlet或者EJB。Java Web服务将继续用现有的API构造，但JPC提供了一种把Servlet、JSP和EJB耦合到一个Process级组件里面的途径。

JPC组件类似于在它之前的研究系统，比如Stanford的Paths框架，它也是事件驱动的。组件拥有输入和输出端口，数据流通道可通过输入输出端口建立，JPC容器负责管理事件递送和数据流程。

四、结束语

如果你想要在自己的应用中使用可复合Web服务的一些概念，不必等到JPC全部完成。任何Web服务，即使它不遵从标准的API，都可以被另一个服务封装。服务复合最常见的应用恐怕就是过滤器。想象一下，有一个无线应用需要访问一些来自某个Web服务的数据，但该Web服务并不压缩数据，从而延长了接收数据的等待时间。这时，你可以构造一个压缩服务，任何来自其他Web服务的数据都可以经由压缩服务的处理再传递给无线应用。至于具体如何把压缩服务和数据服务连接在一起，使它们看起来象单一的服务，这正是JCP力图进行简化的。

到目前为止，复合式Web服务还只显现了一个轮廓，最终的情形到底会怎么样，现在还无从得知。但可以肯定的是，现在就为迎接复合式Web服务做好准备是明智的。这样，当它们最终到来时，你就不会措手不及了。