web服务实现方案

目前知道的三种主流的Web服务实现方案为：
REST：表象化状态转变 (软件架构风格）
SOAP：简单对象访问协议 
XML-RPC：远程过程调用协议 （已经慢慢被SOAP取代）;

REST：表征状态转移（Representational State Transfer），采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。REST是一种软件架构风格而非协议也非规范，是一种针对网络应用的开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

 

SOAP：简单对象访问协议（Simple Object Access Protocol）是一种标准化的通讯规范，主要用于Web服务（web service）中。用一个简单的例子来说明 SOAP 使用过程，一个 SOAP 消息可以发送到一个具有 Web Service 功能的 Web 站点，例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个 XML 格式的信息，其中包含了查询结果（价格，位置，特点，或者其他信息）。由于数据是用一种标准化的可分析的结构来传递的，所以可以直接被第三方站点所利用。

XML-RPC：一个远程过程调用（remote procedure call，RPC)的分布式计算协议，通过XML将调用函数封装，并使用HTTP协议作为传送机制。后来在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协定。XML-RPC协定是已登记的专利项目。XML-RPC透过向装置了这个协定的服务器发出HTTP请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。

 

三种方案的简单比较

XML-RPC已慢慢的被SOAP所取代，现在很少采用了，但它还是有版权的，我在此就不作多介绍。
成熟度上：SOAP在成熟度上优于REST

效率和易用性上：REST更胜一筹（REST效率更高的原因在于，仅仅是建议的Http协议之上的一种协议。而SOAP则需要对数据、xml封装信息头，解封装等）

安全性上：SOAP安全性高于REST，因为REST更关注的是效率和性能问题

分布式能力：REST更适合在分布式环境中使用、因为REST是基于原生Http协议的，而http协议是无状态的。大型分布式环境都能够对无状态支持良好，无状态增强了整个系统的扩展性。这也是为什么越来越多的云计算，分布式项目选择REST。

（注：SOAP也是基于HTTP协议的，但是却提供了session、cookie等机制来使得SOAP有状态，从而支持需要有状态的业务。有状态举例：1、增加一个用户2、获取最新增加的用户。那1的执行成功与否，及执行先后顺序的状态将会影响2的结果。）

总体上，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景，正是那句老话：适合的才是最好的

同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。

SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持。REST没有任何规范对于安全方面作说明。因此在考虑安全性上，SOAP要高于REST。

ICE：

ICE是分布式应用的一种比较好的解决方案，虽然现在也有一些比较流行的分布式应用解决方案，如微软的.NET（以及原来的DCOM）、CORBA及WEB SERVICE等，但是这些面向对象的中间件都存在一些不足：
 .NET是微软产品，只面向WINDOWS系统，而实际的情况是在当前的网络环境下，不同的计算机会运行不同的系统，如LINUX上面就不可能使用.NET；
 CORBA虽然在统一标准方面做了很多的工作，但是不同的供应商实现之间还是缺乏互操作性，并且目前还没有一家供应商可以针对所有的异种环境提供所有的实现支持，且CORBA的实现比较复杂，学习及实施的成本都会比较高；
 WEB SERVICE最要命的缺点就是他的性能问题，对于要求比较高的行业是很少会考虑WEB SERVICE的。
 ICE的产生就是源于.NET、CORBA及WEB SERVICE这些中间件的不足，它可以支持不同的系统，如WINDOWS、LINUX等，也可以支持在多种开发语言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服务端可以是上面提到的任何一种语言实现的，客户端也可以根据自己的实际情况选择不同的语言实现，如服务端采用C语言实现，而客户端采用JAVA语言实现，底层的通讯逻辑通过ICE的封装实现，我们只需要关注业务逻辑。

ESB与EAI区别：

ESB是将所有的系统的交互都放在SOA统一服务总线上面来控制处理。

EAI只是将不同的系统集成起来（可以采用ESB总线形式，也可以采用点对点的形式）。