开始学习WebService了.首先了解一些概念.
首先要说:本人一直用CXF,它都支持JAX-WS和JAX-RS.不过JAX-RS是JAVA EE 6提出的功能.
与 WebServices 相关的 J2EE 技术称为 JWS（Java WebServices），其中含有 JAX-WS、JX-RS、JAXB、JAXR、SAAJ、StAX 等技术。
支持 SOAP 的是 JAX-WS，即 JSR 224，http://jcp.org/en/jsr/detail?id=224
支持 REST 的是 JAX-RS，即 JSR 311，http://jcp.org/en/jsr/detail?id=311
SOAPY与REST的区别:
一直想比较一下这两种风格，却不知如何落笔，最终写成了如下的FAQ形式。
什么是SOAP？ 简单对象访问协议，基于XML，是一种应用协议，可以跨多种传输协议来传递消息（比如HTTP、SMTP），Soap是针对RPC的解决方案。 Soap的初衷是作为一种轻量级解决方案出现的，采用xml格式定义过程调用和返回，一个Soap消息就是一个特定格式和内容的XML文档。
什么是Restful web service？ Rest是针对Web提出的一种架构风格，Restful web service本质上就是Web，任意一个URL地址，一个HTTP网页都可以称作是Restful web service。Rest把网络上的所有事物抽象为资源，把对资源的操作抽象为CRUD，对应HTTP的PUT，Get，Post，Delete。注意此处的资源不是静态的数据，而是数据加上状态，是随时间变化的，每个资源有一个唯一的标识，URL。
Rest提出了一些设计概念和准则： 1、网络上的所有事物都被抽象为资源（resource）； 2、每个资源有一个唯一的资源标识（resource identifier）； 3、通过通用的连接器接口（generic connector interface）对资源进行操作； 4、 对资源的各种操作不会改变资源标识； 5、所有的操作都是无状态的（stateless）。 什么是架构风格？ 来自Roy Thomas Fielding博士的定义： 一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。我觉得可以这么来理解： 架构风格是接口 如果说架构是一个对象， 那么架构风格就好比是一组接口，一个特定的架构可能实现了多种架构风格，一种架构风格也可能是继承了多个基本架构风格的混合风格。 架构风格是模式 存在一组基本的架构风格，每个基本风格适用于特定的设计场景，设计师可以根据具体的应用需求进行取舍，对基本风格进行取舍、组合，确定适用于具体的需求的架构设计。而实际的软件架构就是架构设计的具体实现。
Soap是Rest风格的一种实现吗？ 当然不是。 1、Soap也可以看作是一种风格，面对的应用需求是RPC，而Rest面对的应用需求是分布式超媒体系统（Web）。 2、Rest架构风格更强调数据，请求和响应消息都是数据的封装。而Soap风格更强调接口，Soap消息封装的是过程调用。REST是面向资源的，而Soap是面向接口的。 3、REST架构下，HTTP是承载协议，也是应用协议，而Soap架构下，HTTP只是承载协议，Soap才是应用协议。
什么时候用Soap？什么时候用REST？ 1、过程调用用soap。如果服务是作为一种功能提供，客户端调用服务是为了执行一个功能，用Soap，比如常见的认证授权。而数据服务用REST。 2、可以定义清晰明了的正式接口的情况下，用Soap，比如在企业应用中，系统间的耦合采用面向接口的方式。 3、要更多的考虑非功能需求，比如安全、传输、协作等需求，使用Soap。 4、低带宽，客户端的处理能力受限的场合，比如在PDA，手机上消费服务，用REST。
如今，Web开发者的可选技术相当之多；从简化的数据库访问技术，到易用的中间件服务包装技术，以及各种有趣的客户端软件等等，一应俱全。所有这些产品和工具，都是为了帮助Web开发者用最快的速度开发出最好的Web应用。 然而，拥有大量可选软件方案以及为Web应用的特定部分选用特定方案，都是具有挑战的事；而且，现在Web开发者必须持续跟踪各种不断变化着的标准与方法。 举个例子，Web服务技术就有SOAP（Simple Object Access Protocol，简单对象访问协议）和REST（Representational State Transfer，表示性状态转移）这两种方案。它们都是有效的方案，但在具体场合下采用哪种方案好，这要取决于Web开发者。 目前，大部分Web开发者似乎都了解REST——一种采用标准URI进行调用的方案。REST很容易理解，而且只要是支持HTTP/HTTPS的客户端/服务器就支持它。你可以用HTTP GET方法来执行命令。所以，开发者们感受到的REST的优势是：开发简单、只需依托现有Web基础设施、以及学习成本低。 然而，SOAP作为一种古老的Web服务技术，短期内还不会退出历史舞台。而且，随着SOAP 1.2的出现，SOAP印象中的一些缺点已得到改进，采纳率和易用程度也都得到提高。另需注意的是，从W3C SOAP 1.2版开始，SOAP这一缩写不再代表Simple Object Access Protocol（简单对象访问协议），而是仅仅作为协议名称而已。 相对REST而言，SOAP 1.2多出一些开销，不过这些开销也带来了一些好处。 首先，SOAP在三个方面离不开XML（Extensible Markup Language，可扩展标记语言）： · SOAP信封（envelope）是基于XML的，它定义了消息里有什么以及如何处理它； · 一套用于数据类型的编码规则； · 过程调用和响应的规划。 SOAP信封由传输协议（HTTP/HTTPS）发出，RPC（Remote Procedure Call，远程过程调用）得到执行，然后一个XML文档随SOAP信封返回。 需要注意的是，基于“通用”传输协议是SOAP的一个优点。REST目前基于HTTP/HTTPS；而SOAP可支持任何传输协议，从HTTP /HTTPS到SMTP（Simple Mail Transfer Protocol，简单邮件传送协议），甚至JMS（Java Messaging Service，Java消息传递服务）。不过，由于XML较为冗长且解析费时，因此采用XML也成为一个弊端。 不过，对Web开发者来说的好消息是，目前上述两种方案都是行之有效的方案。REST和SOAP都能解决许多Web方面的问题与挑战，而且在许多情况下，它们各自都能满足开发者的要求，也就是说可互换使用。 但很多人不知道，这两种技术可以混合搭配使用。REST很好理解，且极易上手；不过由于它缺乏标准，因此只被看作是一种架构方法。与之相比，SOAP是一个工业标准，它具备良好定义的协议，以及一套良好确立的规则，在大型和小型系统中均有采用。 因此，REST的适用场合包括： * 有限的带宽和资源别忘了返回的结构可以采用（由开发者定义的）任何格式。另外，由于REST采用标准的GET、PUT、POST和DELETE动词，因此可被任何浏览器所支持。除此以外，REST还可以使用为目前大多数浏览器支持的XMLHttpRequest对象，这为AJAX增色不少。 * 完全无状态的操作对于那些需多步执行的操作，REST并非最佳选择，采用SOAP更合适。但是，如果你需要无状态的CRUD（Create/Read/Update /Delete，创建/读取/更新/删除）操作，那么应采用REST。 * 缓存考虑若要利用无状态操作的特性，使得信息可被缓存，那么REST是很好的选择。 以上已经覆盖很多方案了，那么，为什么还要考虑SOAP呢？正如前述，SOAP比较成熟而且是经过良好定义的，具有完整的规范。而REST只不过是一种方法，对开发未作任何规约；因此，假如你遇到以下场合，那么SOAP是最佳选择： * 异步处理与调用 如果你的应用需要确保可靠性与安全性，那么请采用SOAP。SOAP 1.2为确保这种操作补充定义了WSRM（WS-Reliable Messaging）等标准。 * 形式化契约 若提供者/消费者双方必须就交换格式取得一致，那么采用SOAP更合适。SOAP 1.2为这种交互提供了严格的规范。 * 有状态的操作 如果应用需要上下文信息与对话状态管理，那么应采用SOAP。 SOAP 1.2为此补充定义了WS-Security、WS-Transactions和WS-Coordination等标准。相比之下，REST方法要求开发者自己来实现这些框架性工作。 正如你所看到的，REST和SOAP各自有其用武之地。它们在安全性和传输层等方面有着自己的潜在问题，不过它们都能完成任务，而且在许多情况下，它们都丰富了Web的技术手段。因此，就这一论题，其实最好的原则就是灵活性原则；因为至少在现今的Web开发中，无论面对何种问题，Web开发者们总有办法运用好这两种技术中的一种。