1.什么是Web Service（Web服务）
从表面上看，Web Service就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。
这就是说，你能够用编程的方法透明的调用这个应用程序，不需要了解 它的任何细节，
跟你使用的编程语言也没有关系。
例如可以创建一个提供天气预报的Web Service，那么无论你用哪种编程语言开发的应用，都可以通过调用它的API并传入城市信息来获得该城市的天气预报。
之所以称之为Web Service，是因为它基于HTTP协议传输数据，
这使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件，
就可相互交换数据或集 成。
2.SOA（Service-Oriented Architecture，面向服务的架构）
SOA是一种思想，它将应用程序的不同功能单元通过中立的契约联系起来，
独立于硬件平台、操作系统和编程语言，使得各种形式的功能单元能够更好的集成。
显然，Web Service是SOA的一种较好的解决方案，它更多的是一种标准，而不是一种具体的技术。
3.概念解释：SOAP、WSDL、UDDI
SOAP |
简单对象访问协议（Simple Object Access Protocol）， 是Web Service中交换数据的一种协议规范。 |
WSDL |
Web服务描述语言（Web Service Description Language）， 它描述了Web服务的公共接口。 这是一个基于XML的关于如何与Web服务通讯和使用的服务描述； 也就是描述与目录中列出的Web服 务进行交互时需要绑定的协议和信息格式。 通常采用抽象语言描述该服务支持的操作和信息， 使用的时候再将实际的网络协议和信息格式绑定给该服务。 |
UDDI |
统一描述、发现和集成（Universal Description, Discovery and Integration）， 它是一个基于XML的跨平台的描述规范， 可以使世界范围内的企业在互联网上发布自己所提供的服务。 简单的说，UDDI是访问各 种WSDL的一个门面（可以参考设计模式中的门面模式）。 |
4.Java规范中和Web Service相关的规范有哪些
Java规范中和Web Service相关的有三个
JAX-WS(JSR 224) |
这个规范是早期的基于SOAP的Web Service规范JAX-RPC的替代版本， 它并不提供向下兼容性， 因为RPC样式的WSDL以及相关的API已经在Java EE5中被移除了。 WS-MetaData是JAX-WS的依赖规范， 提供了基于注解配置Web Service和SOAP消息的相关API。 |
JAXM(JSR 67) |
定义了发送和接收消息所需的API,相当于Web Service的服务器端 |
JAX-RS(JSR 311 & JSR 339 & JSR 370) |
是针对REST（Representation State Transfer）架构风格制定的一套Web Service规范。 它不像SOAP那样本身承载着一种消息协议， 可以将REST视为基于HTTP协议的软件架构。 REST中最重要的两个概念是资源定位和资源操作， 而HTTP协议恰好完整的提供了这两个点。 HTTP协议中的URI可以完成资源定位， 而GET、POST、OPTION、DELETE方法可以完成资源操作。 而不像SOAP协议那样只利用了HTTP的传输特性， 定位和操作都是由SOAP协议自身完成的， 也正是由于SOAP消息的存在使得基于SOAP的Web Service显得笨重逐渐被淘汰。 |
5.REST和SOAP Web Service的比较
5.1什么是SOAP?
SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，
用于在Web Service中，把远程调用和返回封装成机器可读的格式化数据。
事实上SOAP数据使用XML数据格式，
定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。
而且随着需要的增长，又不得增加协议以支持安全性，
这使SOAP变得异常庞大，背离了简单的初衷。
另一方面，各个服务器都可以基于这个协议推出自己的API，
即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。
WSDL (Web Service Description Language) 也遵循XML格式，
用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，
简言之，服务发现。
现在，使用Web Service的过程变成，
获得该服务的WSDL描述，
根据WSDL构造一条格式化的SOAP请求发送给服务器，
然后接收一条同样SOAP格式的应答，
最后根据先前的WSDL解码数据。
绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。
5.2什么是REST？
REST (REpresentational State Transfort)，
形式上应该表述为客户端通过申请资源来实现状态的转换，
在这个角度，系统可以看成一台虚拟的状态机。
REST应该满足这样的特点：
1)客户端和服务器结构；
2)连接协议具有无状态性；
3)能够利用Cache机制增进性能；
4)层次化的系统；
5)按需代码。
说到底，REST只是一种架构风格，而不是协议或标准。
但这种风格对现有的以SOAP为代表的Web Service造成的冲击也是革命性的，
因为它面向资源，甚至连服务也抽象成资源，
因为它和HTTP紧密结合，因为它服务器无状态。
5.3REST与SOAP的区别？
即使绝大多数SOAP是运行在HTTP上，使用URI标识服务，
SOAP也仅仅使用POST方法发送请求，用一个唯一的URI标识服务的入口。
对于SOAP，delete操作也要用POST方法来发送，
而其实HTTP协议有更合逻辑的DELETE方法可用。
REST为每一个资源指定一个唯一的URI，
而用HTTP的4种方法GET、POST、PUT、DELETE直观地表示
获取、创建、更新和删除图书。
REST的优点?
REST简单而直观，把HTTP协议利用到了极限。
1. 它用HTTP请求的头信息来指明资源的表示形式，
2. 用HTTP的错误机制来返回访问资源的错误。
由此带来的直接好处是构建的成本减少了，
例如用URI定位每一个资源可以利用通用成熟的技术，
而不用再在服务器端开发一套资源访问机制。
3. 只需简单配置服务器就能规定资源的访问权限，
例如通过禁止非GET访问把资源设成只读。
4. 服务器无状态带来了更多额外好处，
因为每次请求都包含响应需要的所有信息，所有状态信息都存储在客户端，
服务器的内存从庞大的状态信息中解放出来。
而且现在即使一台服务器突然死机对客户的影响也微乎其微，
因为另一台服务器可以马上代替它的位置，而不需要考虑恢复状态信息。
5. 更多的缓存也变成可能，
而之前由于服务器有状态，对同一个URI的请求可能导致完全不同的响应。
总体结果是，网络的容错性和延展性都增强了，这些本来是WEB设计的初衷，
日趋复杂和定制的WEB把它们破坏了，现在REST又返璞归真，
试图把Web Service带回简单的原则中来。
REST的不足之处？
无状态带来了巨大的优势，同时也带来了难以解决的问题，
例如，怎样授权特定用户才能使用的服务？怎样验证用户身份？
如果坚持服务器无状态，也就是不记录用户登录状态，
势必要求每一次服务请求都包含完整的用户身份和验证信息。
在这种情况下，怎样避免冒认？怎样避免用户信息泄漏？
事实上，构建REST附属的安 全机制已经在讨论中，
其结果无非导致另一个SOAP：复杂的需求摧残了易用性。
REST在面向资源的应用中左右逢源，但在面向事务的应用中却未如人意。
面向资源的应用操作简单，无非创建、读取、改变、删除几项，
但是面向事务的应用不允许用户直接操作资源，
用户只需向系统提交一个事务说明要求，然后等待事 务的完成，
就如一个网上银行的用户不直接修改账户和存款，
而是提交一个事务告诉银行自己要转账。
如果把这样的服务看成一种资源，
通过向资源发送POST请 求完成事务，那不过是SOAP的翻版而已。
无论是这样，还是通过PUT来创建事务，
都改变了系统的状态（资源本身未改变，此处是改变了用户的余额），
显然 违背了REST直观的初衷。
来源：oschina
链接：https://my.oschina.net/u/1386987/blog/538361