webservice 学习

Web Service是构建互联网分布式系统的基本部件。（以下内容从网络上整理而来）

下面是一些与Web Service有关的技术活概念：

Web Service主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。 Web Service所使用的是Internet上统一、开放的标准，如HTTP、XML、SOAP（简单对象访问协议）、WSDL等，所以Web Service可以在任何支持这些标准的环境（Windows,Linux）中使用。注：SOAP协议（Simple Object Access Protocal,简单对象访问协议）,它是一个用于分散和分布式环境下网络信息交换的基于XML的通讯协议。在此协议下，软件组件或应用程序能够通过标准的HTTP协议进行通讯。它的设计目标就是简单性和扩展性，这有助于大量异构程序和平台之间的互操作性，从而使存在的应用程序能够被广泛的用户访问。详情请参见 http://blog.csdn.net/jsfn_dai/article/details/4510289

Web Service 三个基本技术
Web Service通过 标准通信协议，在互联网上发布有用的程序模块（以服务的方式），目前大部分是用SOAP来作通信协议。

Web Service提供一份详细的 接口说明书，来帮助用户构建应用程序，这个接口说明书叫作WSDL（Web Service Description Language）。

通常已发布的Web Service要 注册到管理服务器，这样便于使用者查询和使用。这个是通过UDDI（Universal Discovery Description and Integration）来完成的。

SOAP
SOAP是Web Service的基本通信协议。因为SOAP与DCOM和CORBA在概念上有相同之处，所以很多人在问：“SOAP是怎样激活对象的？”或“SOAP在使用什么命名服务（Naming Service）？”。或许在执行SOAP的过程当中会用到这些，但这些并不在SOAP规范要考虑的范畴之内。SOAP只是定义SOAP消息的XML格式（XML Format），如果你用一对SOAP标记（SOAP Elements）把XML文档括起来，那么这个就是一个SOAP消息，这不是很简单吗？

SOAP规范还定义了怎样用XML来描述程序数据（Program Data）,怎样执行RPC（Remote Procedure Call）。这些可选的规范是为了构建RPC-style的应用程序（客户端SOAP消息包含函数名和在函数中用到的参数，而服务器端SOAP消息包含执行函数之后的结果）。大多数SOAP解决方案都支持RPC-style应用程序，因为很多程序员已对DCOM或CORBA熟悉。SOAP还支持Document-style应用程序（SOAP消息只包含XML文本信息）。Document-style应用程序有很好的灵活性，所以很多用RPC很难构建的Web Service用这种方式构建。

最后SOAP规范还定义了HTTP消息是怎样传输SOAP消息的。这并不代表SOAP只能用HTTP来作为传输协议，MSMQ、SMTP、TCP/IP都可以做SOAP的传输协议。

很多大公司根据SOAP规范，都开发出了自己的SOAP解决方案。这些解决方案都是相对于某种语言。比如说Microsoft SOAP toolkit2.0把COM函数转换成SOAP消息，而Apache toolkit把JAVA函数转换成SOAP消息。这样难免带来一些兼容性问题。

WSDL
WSDL是一种XML文档，它定义SOAP消息和这些消息是怎样交换的。IDL（Interface Description Language）是用于COM和CORBA的，WSDL是用于SOAP的。WSDL是一种XML文档，所以我们可以阅读和编辑，但很多时候是用工具来创建、由程序来阅读。

举个例子，你要使用供应商的Web Service构建应用程序。你可以向供应商索取使用Web Service的范例，然后按照范例来构建应用程序。这样可能出现意料不到的错误，比如说，你在程序中使用的客户代码的数据类型是integer，而供应商使用的数据类型是string.。WSDL详细定义客户端消息的格式，需要什么样的参数，这样可以避免不必要的错误。

UDDI
UDDI可以比喻成电话本，电话本里记录的是电话信息，而UDDI记录的是Web Service信息。你可以不把Web Service注册到UDDI。但如果要让全球的人知道你的Web Service，最好还是注册到UDDI。

UDDI目录说明文件也是一个XML文档，它包括三个部分。“白页（White Paper）”说明提供Web Service的公司（人）信息，比如说名称、地址和联系方式等等。“黄页（Yellow Paper）”说明UDDI目录的分类，比如说金融、服务和印刷等等。“绿页（green Paper）”说明接口（Web Service 提供的）的详细信息。

UDDI提供多种查询方式，来帮助你找到需要的Web Service。如果你查询与财务有关的Web Service，那么UDDI会提供详细的信息。

软件和数据重用
WebService在允许重用代码的同时，可以重用代码背后的数据。使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。

另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。

当前比较流行的几种 开发框架：AXIS、XFire、CFX(XFire的下一代)

AXIS：
最新版本：1.4
Axis是Apache组织推出的SOAP引擎，Axis项目是Apache组织著名的SOAP项目的后继项目， 但是Axis不仅仅是一个SOAP引擎，它还包括：
1)个独立运行的SOAP服务器
2)一个servlet引擎的插件，这个servlet引擎可以是Tomcat
3)对WSDL的扩展支持
4)一个将WSDL的描述生成JAVA类的工具
5)一些示例代码
6)还有一个监控TCP/IP包的工具
全称：Apache EXtensible Interaction System 阿帕奇可扩展交互系统

Axis2
最新版本：1.5
Axis2 具有模块化体系结构，由核心模块和非核心模块组成。据说，Axis2 核心是纯 SOAP 处理引擎，并没有包含 Java™ API for XML-based RPC (JAX-RPC) 概念作为其核心的一部分。同时，Axis2 体系结构的设计充分考虑了以下原则：
逻辑和状态分离，以提供无状态处理机制，因为 Web 服务是无状态的。
所有信息位于一个信息模型中，允许对系统进行挂起和恢复。
能够在不更改核心体系结构的情况下扩展功能，能以最小或没有核心更改的情况下直接支持新 Web 服务规范。
Axis2 核心体系结构包括以下核心和非核心组件：
核心组件
XML 对象模型 (AXIOM)
SOAP 处理模型：处理程序框架
信息处理模型：上下文和描述
其他组件
部署模型
传输
客户机 API
核心生成模型

XFire是一个免费的,开源的SOAP框架. 它不仅允许你轻松简易地实现这么一个环境.而且还提供了很多先进的特性.用XFire构建Web服务很简单.如果你的Web应用有一个Java类, 现在你希望这个类编程Web服务,用XFire完成这一工作你不必写一句代码.仅需操作一下部署描述器,你就会得到一个Web服务.
XFire 是 codeHaus 组织提供的一个开源框架，它构建了 POJO 和 SOA 之间的桥梁，主要特性就是支持将 POJO 通过非常简单的方式发布成 Web 服务，这种处理方式不仅充分发挥了 POJO 的作用，简化了 Java 应用转化为 Web 服务的步骤和过程，也直接降低了 SOA 的实现难度，为企业转向 SOA 架构提供了一种简单可行的方式。

CXF
最新版本：2.2.2
开源服务框架，可以通过API，如JAX-WS，构建和开发服务。服务可以使多种协议的，例如SOAP, XML/HTTP, RESTful HTTP,  CORBA，并可以工作与多种传输协议之上，如HTTP，JMS，JBI。

比较

Axis1.X VS Axis2

Axis2 不仅是 Apache 的新 Web 服务框架。它还体现了从 Axis 1.x 系列获得的经验和最近两年在 Web 服务领域的发展。推出 Axis2 的主要原因之一是从速度和内存方面获得更好的性能——不过还添加了一些新特性和功能。大部分新特性都是为了提高 Axis2 的易用性，并同时保留通过各种方式扩展功能的空间。大部分新功能所添加到的主要领域如下所示：
新 XML 对象模型 (AXIOM)

与 Axis 1.x 相比，Axis2 构建于全新的体系结构之上。引入 Axis2 的主要原因之一是获得合适的 XML 处理模型。Axis 1.x 使用 DOM 作为其 XML 表示机制，但使用 DOM 的缺点是，需要在内存中保存完整的对象层次结构（与传入消息对应）。对于小消息，这将不是问题，但对于大型消息就是问题了。为了克服此问题，Axis2 引入了新的 XML 表示形式作为其基础。
基于消息传递的核心

Axis2 核心是纯 SOAP 处理引擎，并不了解数据绑定、传输、WSDl 等内容。Axis2 核心的主要功能是处理传输消息，并将其交付给目标应用程序。与 Axis 1.x 一样，Axis2 也具有用于扩展其主要功能的处理程序概念。
Axis 1.x 并没有异步 Web 服务调用的概念，它完全绑定到请求-响应调用，但在 Axis2 中却是另一番景象。Axis2 体系结构能够支持在客户端和服务器端同时支持异步调用。同时，Axis2 也支持请求-响应样式的调用，但这会以两个异步调用的方式进行。在 Axis2 中，进入系统的消息可能有也可能没有响应，应该注意，Aixs2 支持 WSDL 2.0 中定义的所有八种消息交换模式（Message Exchange Patterns，MEP）。
Axis2 具有流的概念，流是阶段的集合，而阶段是处理程序的集合。根据给定方法调用的 MEP，与其关联的流的数量可能会有所变化。

部署模型

在 Axis 1.x 中，用户必须手动调用管理客户机，并更新服务器类路径，然后重新启动服务器，以应用更改。这个有点麻烦的部署模型对新手肯定是一道障碍。Axis2 经过了精心的设计，能够克服此缺点，并提供灵活、用户友好、可方便进行配置的部署模型。Axis2 部署引入了类似于 Java™ 2 Platform Enterprise Edition (J2EE) 部署机制的概念，开发人员可以在其中将所有类文件、库文件、资源文件和配置文件一起打包为存档文件，并将其放置在文件系统中的指定位置。

模块体系结构

在 Axis 1.x 中，要添加处理程序，需要首先更改全局配置文件，然后需要重新启动系统，并没有在运行时更改处理程序链的动态方法。为了克服这个问题和增加新特性，Axis2 引入了 Web 服务扩展或模块的概念；其中模块的主要工作是对核心功能进行扩展。在 Axis 1.x 中，可以通过向处理程序链添加处理程序来实现此目标。与 Axis 1.x 处理程序链相比，使用模块的优势在于，您可以在根本不改变全局配置文件的情况下添加新模块。同时，模块是一个自容器，其中可以包含处理程序、第三方库、模块相关资源和模块配置文件。

XFire VS Axis

XFire是与Axis2 并列的新一代WebService平台。之所以并称为新一代，因为它：

1.   支持一系列Web Service的新标准--JSR181、WSDL2.0 、JAXB2、WS-Security等；
2.   使用Stax解释XML,性能有了质的提高。XFire采用Woodstox 作Stax实现；
3.   容易上手，可以方便快速地从pojo发布服务；
4.   Spring的结合；
5.   灵活的Binding机制，包括默认的Aegis,xmlbeans,jaxb2,castor。
XFire与Axis1性能的比较

XFire比Axis1.3快2-6倍
XFire的响应时间是Axis1.3的1/2到1/5
XFire与Axis2的比较

虽然XFire与Axis2都是新一代的WebService平台，但是Axis2的1.0版本还不是一个稳定的版本。在XFire捐献给apache后有人认为Axis2将会灭亡。在很多人眼里，Axis2并不是pojo形式，Dan Diephouse证明了XFire比Axis更有市场。用XFire进行WebService的开发比Axis2简单很多。

AXIS VS CXF

在SOA领域，我们认为Web Service是SOA体系的构建单元（building block）。对于服务开发人员来说，AXIS和CXF一定都不会陌生。这两个产品都是Apache孵化器下面的Web Service开源开发工具。 Axis2的最新版本是1.3.CXF现在已经到了2.0版本。

这两个框架 都是从已有的开源项目发展起来的。Axis2是从Axis1.x系列发展而来。CXF则是XFire和Celtix项目的结合产品。Axis2是从底层全部重新实现，使用了新的扩展性更好模块架构。 CXF也重新的深化了XFire和Celtix这两个开发工具。

新产品的退出导致了几个问题。是不是现有的使用Axis 1.x，XFire和Celix的应用需要迁移的新的版本上。如果一个开发人员确定要迁移它的应用到新的框架上，那么他应该选择哪一个呢？相反的，如果一个开发者决定从头开发一个新的Web Service，他应该使用哪个呢？ 这两个框架哪一个更好一些呢？

对于系统迁移来说，也许迁移到新的框架并不难。Axis和CXF都提供了迁移的指导。能够给开发者一些迁移的技巧和经验。但是对于这样迁移，这两个开源项目都没有提供迁移的工具。对于这样的迁移工作，尽管很值得去寻找所有的可行方案。Axis2和CXF都有各自不同的WebService开发方法，每个方法都有相当数量拥护者。

通过一个比较矩阵来比较Axis2和CXF变得有现实的意义。这两个项目都开发不够成熟，但是最主要的区别在以下几个方面：

1.CXF支持 WS-Addressing，WS-Policy， WS-RM， WS-Security和WS-I Basic Profile。Axis2不支持WS-Policy，但是承诺在下面的版本支持。

2. CXF可以很好支持Spring。Axis2不能

3. AXIS2支持更广泛的数据并对，如XMLBeans，JiBX，JaxMe和JaxBRI和它自定义的数据绑定ADB。注意JaxME和JaxBRI都还是试验性的。CXF只支持JAXB和Aegis，并且默认是 JAXB 2.0。

4. Axis2支持多语言-除了Java,他还支持C/C++版本。

比较这两个框架的Web Service开发方法与比较它们的特性同样重要。 从开发者的角度，两个框架的特性相当的不同。 Axis2的开发方式类似一个小型的应用服务器，Axis2的开发包要以WAR的形式部署到Servlet容器中，比如Tomcat，通过这些容器可以对工作中的Web Service进行很好的监控和管理。Axis2 的Web administrion模块可以让我们动态的配置Axis2.一个新的服务可以上载，激活，使之失效，修改web服务的参数。管理UI也可以管理一个或者多个处于运行状态的服务。这种界面化管理方式的一个弊端是所有在运行时修改的参数没有办法保存，因为在重启动之后，你所做的修改就会全部失效。

Axis2允许自己作为独立的应用来发布Web Service，并提供了大量的功能和一个很好的模型，这个模型可以通过它本身的架构（modular architecture）不断添加新的功能。有些开发人员认为这种方式对于他们的需求太过于繁琐。这些开发人员会更喜欢CXF。

CXF更注重开发人员的工效（ergonomics）和嵌入能力（embeddability）。大多数配置都可以API来完成，替代了比较繁琐的XML配置文件， Spring的集成性经常的被提及，CXF支持Spring2.0和CXF's API和Spring的配置文件可以非常好的对应。CXF强调代码优先的设计方式（code-first design)，使用了简单的API使得从现有的应用开发服务变得方便。

不论选择Axis2还是CXF，都可以从开源社区得到大量的帮助。这两个框架都有商业公司提供服务，WSO2提供AXIS2的支持，Iona提供CXF的支持。这两公司都有很活跃的开发者社区。 Axis2出现的时间较早，CXF的追赶速度快。如果需要多语言的支持，应该选择AXIS2。如果需要把的实现侧重JAVA并希望和Spring集成，CXF就是更好的选择，特别是把Web Service嵌入其他的程序中。

搭建Web Service项目简单实例请参见：
XFire方式 http://blog.csdn.net/meteorlwj/article/details/4545100
JAX-WS方式 http://horizonhyg.iteye.com/blog/378046

信息链接：
http://blog.csdn.net/jsfn_dai/article/details/4510289推荐
http://blog.csdn.net/jsfn_dai/article/details/4510289
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/webservbasics.asp
http://hi.baidu.com/%C0%C1%C0%C1%B5%C4%B8%F2%F3%A1/blog/item/205f8efcb496f483b901a099.html