Web服务的几种实现方法

来源：互联网发布：找工作哪个软件好编辑：程序博客网时间：2024/04/30 14:36

我们为什么应该使用基于Document风格的SOAP服务？

RPC风格的承前启后性

在上节中，我们介绍了RPC和Document风格Web服务的差别。首先，有人可能要问，对RPC和Document wrapped风格的服务来说，我们毕竟只关心要交换消息及它们的WSDL，而不去管它是RPC还是Document风格，所以从这方面说，这两种方法差别不大。实际上，它们之间的差别不在于实际操作中，而更在于对概念的理解上面，对我们那些熟悉了数十年”方法调用”的人来说尤其如此。我们总想指望能调用一个方法(有时称之为过程或函数等)，传入几个参数，有时还需要返回调用结果。在这种情况下，SOAP在开始设计时，其中的Web服务或多或少就是上面模型的扩展，只是让RPC调用显得更加标准化而已。实际上，我们前面也曾提到，初始的SOAP规范就是基于RPC风格的。

面向Document的SOAP服务

现在，我们来说明一下面向Document的服务是怎样从原始的RPC转移到Document模型上来的？Document是一种全新的编程模型，它会在未来的Web服务开发方面占据主导地位，虽然，有人对此尚有争议。

Document与消息类似，它们都可以被发送或转发到目的地，然后进行处理。

基于Document编程模型

自包含的Document及异步编程模型

但Document被处理时，我们不应关心这个过程何时发生，但我们必须保证消息中包含了处理过程所需要的所有信息。因此，消息应该是自包含的业务文档，这是使用异步传输协议(比如SOAP支持的SMTP或JMS协议)进行消息传输的最基本的前提。这点虽然没有明文规定，但它不失为一个非常好的编程实践。

另外，对工作流系统而言，我们也必须要自包含的业务文档，这是因为工作流内部的转换天生就是异步的。因此，面向Document的编程模型非常适合这种情况。

Document模型的验证功能

前面我们已经说明，Document风格的一个优点是，它可以使用XML模式对交换的文档进行验证。

Document模型的解耦功能

RPC方法的一个主要缺点是强耦合，RPC调用必须依赖于服务器端的软件架构，一旦服务器端的方法签名发生改变，这种改变势必波及整个系统，其结果是客户端受到影响，从而客户端不得不进行相应的代码重构。但Document风格的服务缺克服了这一缺点，因为消息结构的更改(比如添加一个新属性)并不影响文档交换的机制。另外，服务器端修改方法的签名通常对消息结构没有影响。因此，Document风格的SOAP服务是松耦合的，它易于维护，也易于对软件进行模块化处理，因而使得软件的架构更加健壮和可靠。

Document模型的可交互性

最后，我们需要考虑Web服务的可交互性。互操作性可以使不同的技术和系统协同工作，我们可以通过和标准交换协议兼容，及和业界保持一致就可做到这一点。Document风格的服务获得业界一致支持，觉得大多数厂家都支持这种风格的服务。实际上，JAX-WS的Java参考实现及大多数其它的Java WS实现(将第6章)及.Net，都采用Document风格作为其Web服务的缺省实现风格。

Web服务的几种实现方法 – JAX-WS 2、Axis2、Spring-WS及XFire/CXF2.0

在接下来的Web服务之旅中，我们将介绍一下几种Web服务的实现方法。因为到某一时刻，我们总得选择Web服务的实现方法。如何选择Web服务的实现方法需要考虑多种因素。在本小节中，我们介绍一下几种主要的Web服务实现方法及它们的特点。

JAX-WS2

在前面的章节中，我们对JAX-WS已经做过介绍。首先，我们应注意，它是一个JSR规范(JSR-224)而不是一个实现，JAX-WS是JAVA API for XML Web Services的缩写，意为XML Web服务的Java编程接口，它继承自以前的JAX-RPC(Java API for XML-based Remote Procedure Call)规范。

选择JAX-WS实现Web服务的主要优势是，Java6标准版和Java5企业版都包含了该规范的参考实现。因此，我们在使用时无需另外下载相关的类库。如果您采用JAX-WS的独立发行版本，您可以使用其2.0版本的实现。到本书截稿时为止，JAX-WS独立发行版已经升级到2.1。

JAX-WS使用JAXB作为其数据绑定模型，使用的XML解析引擎为StAX(Steaming API for XML，基于XML流的编程接口)，StAX是一种基于数据流的拉式解析引擎。这种解析方法只有在客户端请求时才能得到XML数据，和DOM方法相比，它提高了执行效率。因为DOM需要解析整个XML文档，在内存中生成这个的对象树。StAX不仅对内存要求较低，而且它还可以使XML的解析过程开始较早。

JAX-WS既支持SOAP协议，也支持REST交换协议。虽然它不能自动生成生成REST风格服务的代码(和SOAP/WSDL方法相比)，这是因为REST风格的Web服务的描述标准目前尚未定义。

JAX-WS服务的实现在很大程度上依赖于Java语的注解功能，并支持SMTP、JMS及HTTP等网络传输协议。而且，使用JAX-WS开发出来的Web服务具有很多特点，它可支持WS-Security(Web服务安全)、WS-Atomic Transaction(Web服务原子交易)及WS-ReliableMessaging(Web服务可靠消息传输)等功能。最后， JAX-WS还可支持有状态的Web服务。

Axis2

Axis2是Apache Web服务项目中的一个工具，Apache Web项目由一套项目组成，覆盖了从Web服务开发到使用的诸多方面，实现了相关的协议和规范。Axis2是对以前的Axis1.X版本的完全重构，它有两套不同的实现，即Axis2/Java和Axis2/C这两种实现方式。

在以前的版本中使用的基于事件的SAX XML解析器，已经被“拉式”的StAX XML解析器所替代，这样就能更好地控制文档的处理过程，其效率更高，性能更优。Axis2其实是使用AXIOM(AXIs Object Model，AXIs对象模型)来对XML进行处理，该模型是一个轻量级的对象模型，它以StAX为基础，并增加了许多新功能。

Axis2既可用来开发基于SOAP的Web服务，也可以用来开发REST风格的服务，同时，它还支持异步非阻塞式的Web服务调用，异步调用是通过回调机制实现的。Axis在设计过程中使用了模块化和可扩展的架构，SOAP消息的发送和接受是通过两个“管道”(或“流”) – 即流入管道和流出管道 – 实现的。每个管道在处理XML消息时，可以分为几个阶段，而每个处理阶段又可有一些可插拔的“处理器”。因此，其整体架构具有高度可扩展性，实际上，除了Axis2自带的XML处理阶段外，用户可以选择添加自定义的XML处理阶段，并在其中加入用户自定义的处理器。这样，就可以执行新的处理过程，或者覆盖原有的处理过程。

另外，处理器可以组装在一起，形成模块。每个模块定义了一套处理器及相应的处理阶段规则的描述，每个处理器不仅不仅表明它所在的处理阶段，而且还可通过阶段规则描述表明它在整个处理过程各种的执行顺序。在Axis2语言中，当一个模块装入系统后，该模块虽然没有激活，但它已经处于可访问(available)的状态；但该模块激活后，它就转变为待命(engaged)状态，此时，其中的处理器就可安放到某一阶段并执行。因此，我们可以非常容易地出入新的模块，来处理和Web服务相关的规范，比如Web服务安全规范(Apache Rampart模块)或者Web服务原子交易规范(Apache Kandula2模块)。

XML数据绑定并不是Axis2的核心部分，在Axis2中，数据绑定是通过扩展机制实现的，我们可以选择ABD（Axis Data Biding)、XML Bens、JAX-Me和JibX等技术来实现Axis2的数据绑定。而且，Axis2可支持多种传输协议(如HTTP、TCP、SMTP和JMS等)。

Axis2的缺省安装过程为：将一个WAR文件包部署到应用服务器即可，对Axis2推荐的Tocmcat服务器而言，我们只需要把这个WAR文件拷贝到CATALINA_HOME/webapps目录即可完成安装。当我们把这个名叫axis2的Web应用部署到应用服务器后，它就是Axis2的管理平台，您可以通过它增加和配置Web服务和模块。

请您注意，Axis2中配置的服务、模块、阶段及处理器对其它的Web应用是独立的，这也就是说，如果您有多个Web应用，每个应用都有其特定的义务逻辑，此时，您不需要把服务部署到其中的一个Web应用中，您只需要将Web服务部署到axis2这个Web应用即可。这样，每个服务消费者(客户端或另一个Web应用)都可以调用该服务。

但是，Axis2管理平台上所作的配置不能被保存，因此，重启axis2 Web应用后，您所有的配置将丢失。针对这种情况，您需要手动编辑axis2的配置文件。

另外，您可以选择安装Axis2的“标准二进制分发软件包”，它不但包括Axis2必须的Jar文件，而且还包括一下命令行工具：

(1) wsdl2java工具可以从WSDL生成Java代码，而java2wsdl工具可以根据Java代码生成WSDL描述；

(2) axis2server工具可以启动一个简单的独立运行的服务器，您可以在其中部署Web服务；

(3) axis2工具将启动一个Java应用程序，该应用将自动加载Axis2所有必须的类库。

Spring-WS

Spirng框架无疑是当今Java开发领域较受欢迎的产品之一，它对软件项目的设计方法来说不啻于是一场革命，它使用面向方面的思想，引入了“控制反转(IoC)”或者称之为“依赖注入”的概念，这样，我们就更容易搭建一个J2EE应用，同时我们的应用也会更简洁。但Spring远不只是一个简单的IoC容器，它提供了许多现成的模式和模板，同时，它和其它的框架和工具进行了很好的集成，在灵活性、模块化及软件的鲁棒性方面都有所提高。

Spring社区在Web服务领域也作出了自己的贡献，它推出了“Spring Web服务”的产品，该产品也称作“Spring-WS”。

采用Spring框架的一个优势是，它和Spring的概念和模式一脉相承，您马上就可以重用以前您解决问题的那些经验。比如，服务契约(或接口)和其实现之间的松耦合就是选择Spring的第一个好处。

主流的Web服务开发方法教导我们，应先设计服务的WSDL(从契约开始设计)，而不是先从Java编码开始。Spring对这种方法更进一步，它要求设计者先从消息的XML模式(XSD)开始，然后从XSD自动产生WSDL。

在Spring-WS中，XML的处理过程是可配置的，您既可以选择使用基于DOM的处理类库(比如W3C DOM、JDOM、dom4J、XOM等)，也可以使用SAX、StAX或XPath 等，而XML绑定库，您可以在JAXB、Castor、XMLBeans、JiBX和XStream之间进行选择。

Spring-WS提供了强大而灵活的消息分发器，它能处理XML消息的分发，在消息验证、数字签名、加解密等Web服务安全方面，它也非常出色。

XFire/CXF

XFire旨在提高Axis1.x的性能而设计的，Axis1.x是当时Web服务的事实标准。XFire使用了基于StAX的快速对象模型对XML进行操作。XFire简单易用，它支持JAXB、Castor和XML Beans等XML绑定库，其缺省的XML绑定库为Aegis绑定，这是一种快速XML绑定机制，对内存要求较低。

XFire和Spring、PicoContainer(另一种依赖反转的容器)有很好的集成，而且，它还有一套易用的客户端API，用于创建客户端应用及开发单元测试。XFire支持的传输协议有：HTTP、JMS和Jabber/XMPP等。

最近，XFire和另一个Web服务框架Celtix进行了合并，形成了一个新的产品CXF2.0，它应算是对XFire1.x的延续。CXF2.0这个新产品将在性能和易用性方面有进一步的提高。

CXF支持除SOAP之外的许多协议，比如REST(通过Java注解)和CORBA。它也支持诸多标准和Web服务规范。另外，它还可以嵌入到其它程序中。但是，它强调开发Web服务先从Java代码开始，而不是先从契约开始。

小结

在本章中，我们介绍了SOA方法学和Web服务实现的基础知识，及它们二者之间的关系。我们看到，XML作为一种通用语言，可以解除Web服务及服务的消费者之间的耦合。我们从基础的XML-over-HTTP方法开始，介绍了REST和SOAP方法。针对他们的复杂度和灵活性，我们讲解了Web服务的实现细节。而且，我们还针对SOAP协议，讲述了RPC风格和Document实现风格之间的差别，指出了为什么Document风格要优于RPC风格。实际上，Document风格的SOAP服务是主流Web服务实现框架的缺省风格。