webservice:
上世纪90年代流行的分布式技术，如DCOM,CORBA,RMI，范式是RPC，但各系统数据类型不一致，实现/调用机制不同，各系统间互通不可能。XML的出现，让数据类型一致了，SOAP的出现，让各系统可以相互调用了。Simple Object Access Protocol的原意是XML-RPC，但人们很快就发现方法调用太狭隘，而消息传递更加通用。WSDL即支持rpc/encoded也支持document/literal，但前者已成为历史遗留。
webservices是soa的道成肉身，rpc方式的webservices是历史遗留。
rest是roa的道成肉身。（这方面我不熟悉）
RMI CORBA DCOM
XML-rpc soap wsdl
微软的DCOM，sun的RMI、JMS，和OMG的CORBA
RMI：Romote Method Invocation，远程方法调用。基于java远程消息交换协议JRMP通信；JRMP是专为java远程对象制定的协议。是分布式应用程序的100%java解决方法。RMI对非java语言应用程序支持不足，不能实现互通。
RMI是面向对象的编程模型。广泛应用与EJB架构系统中。
RMI基于调用的模式，调用过程如下：客户端程序调用服务对象的客户端代理，代理负责打包参数并通过JRMP协议发送到服务端，服务端使用同样协议解析，执行业务逻辑处理，用同样方法返回结果给客户端。
RPC：RPC算是这几类的统称（这样说有点不准确，但也可以这么理解）。 RPC（Remote Procedure Call）远程过程调用，是实现分布式计算的一种技术。在某种传输协议（TCP\HTTP等)上携带信息数据，通过网络从远程计算机程序上请求服务。在OSI模型中，RPC跨越了传输层和应用层，使开发网络分布式应用程序变得容易。客户端代码像调用本地方法一样调用远程方法。
RPC基于请求应答模式，客户端发送调用信息（将远程方法名、参数打包进请求信息）到服务端，服务端解析到要调用的对象和方法执行后返回应答信息；客户端接受相应获取应答信息。
RPC是跨语言的通信标准，sun和微软都有其实现,微软的DCOM就是建立在ORPC协议之上。
RPC是面向过程的编程模型。
XML-RPC:XML Remote Procedure Call，即XML远程方法调用,利用http+xml封装进行RPC调用。基于http协议传输、XML作为信息编码格式。一个xml-rpc消息就是一个请求体为xml的http-post请求，服务端执行后也以xml格式编码返回。这个标准面前已经演变为下面的SOAP协议。可以理解SOAP是XML-RPC的高级版本。
SOAP:Simple Object Access Protocol ,简单对象访问协议，是一种轻量的、简单的、基于xml的远程访问协议。可以与现有的多种传输层或应用层协议结合使用，如TCP、HTTP、SMTP等。SOAP广泛使用的是基于HTTP和xml协议的实现（SOAP=RPC+HTTP+XML），也就是大家常提的Web Service使用的通信协议。一个SOAP方法可以简单地看作遵循SOAP编码规则的HTTP请求和响应。
比较：XML－RPC是启动web服务最容易的方法，在很多方面比SOAP更简单易用，但不同于SOAP的是，XML－RPC没有相应的服务描述语法，这妨碍了XML－RPC服务的自动调用。
JSON-RPC:JSON Remote Procedure Call，即JSON远程方法调用 。类似于XML-RPC，不同之处是使用JSON作为信息交换格式。
REST:
Some ‘RESTful’ APIs are really just RPC over HTTP
The REST architecture reuses the world wide web infrustructure where possible
XML
JSON: JavaScript Object Notation
Ajax:
HTTP:GET, POST, PUT, DELETE
URL:
XML-RPC: XML Remote Procedure Call
这种远程过程调用使用http作为传输协议，XML作为传送信息的编码格式。Xml-Rpc的定义尽可能的保持了简单，但同时能够传送、处理、返回复杂的数据结构。
XML-RPC是工作在Internet上的远程过程调用协议。一个XML-RPC消息就是一个请求体为xml的http-post请求，被调用的方法在服务器端执行并将执行结果以xml格式编码后返回。
在RMI和RPC之间最主要的区别在于方法是如何被调用的。在RMI中，远程接口使每个远程方法都具有方法签名。如果一个方法在服务器上执行，但是没有相匹配的签名被添加到这个远程接口上，那么这个新方法就不能被RMI客户方所调用。
简单描述:
rpcclient的工作原理:rpcclient根据URL找到rpcserver -> 构造命令包，调用rpcserver上的某个服务的某个方法 -> 接收到rpcserver的返回,解析响应包，拿出调用的返回结果。
rpcserver的工作原理:启动一个webserver(在使用内置的webserver的情况下) -> 注册每个能提供的服务，每个服务对应一个Handler类 ->进入服务监听状态。
1. 历史
第一轮：HTTP，带来了Internet与电子商务
第二轮：Java，cross-platform，最早的RMI
第三轮：XML，标准的数据封装技术，各种App之间交换数据不再是难事。
第四轮：RPC，Webservice、REST、高性能通信协议
2. What is RPC？
简单理解: 可互操作的Web服务
RPC（Remote Procedure Call）
– 在某种传输协议（TCP\HTTP等)上携带信息数据，通过网络从远程计算机程序上请求服务
– 在OSI模型中，RPC跨越了传输层和应用层
– 基于请求应答模式
– 跨语言的通信标准
任何一个RPC规范和实现都包含:
– 服务层（service）：RPC接口定义与实现
– 协议层（protocol）：RPC报文格式和数据编码格式
– 传输层（transport）：实现底层的通信（如 socket）
应用程序通信性能比较：ipc<tcp<http<soap
3. RPC
以XML-RPC为代表介绍
XML-RPC（XML Remote Procedure Call）
– 协议层：XML
– 传输层：HTTP（许多防火墙也配置为只允许HTTP连接）
一个XML-RPC消息就是一个请求体为xml的http-post请求，服务端执行后也以xml格式编码返回。
4. webservice
Webservice平台是一套标准，它定义了应用程序如何在Web上实现互操作性。标准包括：
– 描述数据的方法：XML
– 信息交换的协议：SOAP
– 传输协议：HTTP
– Web服务描述语言：WSDL
– 发布注册：UDDI
– 服务具体的实现技术：Java，C，Ptyhon…
SOAP介绍
– 可以看做是XML-RPC的高级版本
– SOAP是一种轻量的、简单的、基于XML的协议，允许应用程序通过HTTP来交换信息。或者更简单地讲，SOAP是用于访问Web服务的协议。
– 一个SOAP请求实际上也是一个http-post请求
更多了解参考"Webservice/SOAP/WSDL释疑篇"
5. REST
REST介绍
– 具象状态传输（Representational State Transfer）
– 业界开放服务新标准
– 面向资源开开发
– 公开目录结构式的 URI（http://twitter.com/statuses/user/zhangxu）
– 回归HTTP协议本性（GET、POST、PUT、DELETE）
6. 高性能应用程序通信协议
传统的RPC
– 不管是json还是xml传输数据，效率很低
RMI
– 效率高，仅适用于Java
直接socket连接
– 需要开发自己的协议，成本高
因此需要通过二进制HTTP传输的高性能通信中间件，其中高性能可以理解为：
– 对象的序列化、反序列化高性能
– 压缩算法高性能
– 传输高性能
常用于企业内部系统间的交互
常用技术
– hessian、thrift、protocol buffer
6.1 Hessian
Hessian 是开源的远程通讯协议。 Hessian 采用二进制 RPC 协议，基于 HTTP 传输，服务器端不用开放防火墙端口。 Hessian 协议的规范是公开的，可以用于任意语言。
Hessian通常通过Web应用来提供服务，因此非常类似于WebService。它不使用SOAP协议，并且按照二进制传输。
一次调用的流程：
客户端——>序列化写到输出流——>远程方法（服务器端）——>序列化写到输出流 ——>客户端读取输入流——>输出结果
6.2 Thrift
参考文章“跨平台通信中间件thrift学习【Java版本】”
6.3 protobuf
protocol buffer 是 google 的一种数据交换的格式，它独立于语言，独立于平台。google 提供了多种语言的实现：java、c++ 和 python等，每一种实现都包含了相应语言的编译器以及库文件。由于它是一种二进制的格式，比使用 xml 进行数据交换快许多。可以把它用于分布式应用之间的数据通信或者异构环境下的数据交换。
Protobuf只有一种序列化和反序列化的手段，并不涉及传输层
Protobuf序列化效率业界最高！
什么是Rest？
rest，即REST(Representational State Transfer 表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
REST特点：
1. Rest是一种设计风格，不是一个标准。
2. Rest通常使用HTTP,URI，XML，HTML等流行的协议和标准
3. Rest是从资源的角度来观察网络的，而资源是由URI来指定的。
4. Rest对资源的操作类型通常包括：获取，创建，删除和修改，这四种操作分别对应着HTTP协议请求的GET,POST,DELETE和PUT方法。
5. 资源的表现形式可以为:XML,HTML,JSON的文本。
6. Rest是服务端-客户端结构中的一种应用方法。
7. Rest使用的是HTTP协议，因此是无状态的。
接下来，我们来了解下为什么要Rest？要弄清楚这个问题首先要了解一下计算机软件之间通讯技术的发展历程。在计算机通讯中，TCP/IP协议是最为通用的标准协议，TCP是传输控制协议，IP是网际协议，但这两种协议都是非常原始的（RAW）,TCP协议是传输层协议，而IP是网络层协议。通过TCP/IP的确能胜任将信息从一个计算机传递给另外一台。但大家都知道比较底层的东西，往往比较难于理解。因此一些应用层协议营运而生，最初的应用层协议有SMTP,POP3,FTP,HTTP等，时至今日，大家每天使用最多的仍然是这些老牌应用协议。但这些协议同时都是有应用条件的。
RMI(remote method invocation，面向对象的远程方法调用)
RPC（remote procedure call，远程过程调用）
SOAP(simple object access protoal，简单对象访问协议)
REST(representational state transfer，表达性状态转移)
以上都理解为调用远程方法的一些通信技术“风格”。
1.Tcp/Ip （socket，RMI）
早些时候，程序员们为了让两个应用程序之间能够通讯，通常采用的是使用Socket的开发的TCP/IP通讯程序，并且都是自己定义数据格式规范，这种模式的优点是个性化，通常效率较高，但同时因为都各自为政，往往是开发了好多种程序，但每种都不一样，这对于爱偷懒的程序员来讲，真是杯具了呀！
RMI就好比它是本地工作，采用tcp/ip协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于JAVA语言，客户机与服务器紧耦合。
2.RPC
一些程序员开始想到，如果调用远程的一个方法能够像调用本地方法一样，那就简化多了，于是RPC模式的通讯产生了. RPC使用C/S方式，采用http协议，发送请求到服务器，等待服务器返回结果。这个请求包括一个参数集和一个文本集，通常形成“classname.methodname”形式。优点是跨语言跨平台，C端、S端有更大的独立性，缺点是不支持对象，无法在编译器检查错误，只能在运行期检查。
3.SOAP
之后为了标准化，跨平台又产生了基于SOAP协议的消息通讯模型。SOAP是在XML-RPC基础上，使用标准的XML描述了RPC的请求信息（URI/类/方法/参数/返回值）。因为XML-RPC只能使用有限的数据类型种类和一些简单的数据结构，SOAP能支持更多的类型和数据结构。优点是跨语言，非常适合异步通信和针对松耦合的C/S，缺点是必须做很多运行时检查。
4.REST
但随着时间的推移和SOAP的推广情况，大家很快发现，其实世界上已经存在了一个最为开放，最为通用的应用协议，那就是HTTP，使用SOAP的确让进程间通讯变得简单易用，但并不是每个厂商都愿意将自己的老系统再升级为支持SOAP，而且SOAP的解析也并不是每种语言都内置支持，比如JS.而HTTP正好完美了解决了这个问题，那好吧，我们就设计一种使用HTTP协议来完成服务端-客户端通讯的方法吧，Rest应运而生。
REST一般用来和SOAP做比较，它采用简单的URL方式来代替一个对象，优点是轻量，可读性较好，不需要其他类库支持，缺点是URL可能会很长，不容易解析。
总结来说，计算机通讯的历程可以用下图来阐述：
REST与RPC风格之比较
RPC(远程过程调用)的架构，是应用在基于XML-RPC(或者 RPC风格)的SOAP的Web服务中的。客户端发出命令，以使服务做出特定的操作。换句话说，RPC有动词的倾向。
REST强调资源(名词)有统一的接口以此来对它们寻址，而RPC强调过程(动词)有统一的接口来激发它们。一个基于RPC的架构，动词数量是没有限制的。REST说，我们使用四个动词——非常熟悉，HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应，REST使用资源寻址来处理其可变性。
REST和SOAP风格之比较
REST风格的Web服务依赖一套简单的“动词”，HTTP标准的GET、POST、PUT以及DELETE，把所有的复杂性都转移到了指定资源的“名词”中。与 REST 架构相比，SOAP 架构图明显不同的是：所有的 SOAP 消息发送都使用 HTTP POST 方法，并且所有 SOAP 消息的 URI 都是一样的，这是基于 SOAP 的 Web 服务的基本实践特征。
在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。
XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。
XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。如此一来，SOAP消息的开头部分就可以是任何类型的XML命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。
另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着HTTP传输。
随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。
一个简单的REST举例
假设我们希望一个Web服务暴露一部分目录，从这个目录中，用户将能够得到一些描述、图片、安装指令等等。为了得到数字“n1996-01”的描述，用户需要格式化一个GET请求，类似于下面的这个URL：
http://company.com/catalog/description/n1996-01
在处理这个请求时，“/catalog”将映射到一个服务中，之后，通过该服务对“description/n1996-01”进行解释，从而定位资源。在创建响应时，服务需要使用内容类型(Content-Type)的头文件来指定返回格式。在这种情况下，假定返回格式是HTML或者XML，客户端能够使用它来控制页面的布局。如果要得到图片，那么这个请求将对“/catalog/picture/n1996-01”进行寻址，返回的响应将是图片内容类型(Content-Type)。
REST风格web service和SOAPweb service的选择
以下从成熟度，效率和易用性，安全性三方面讲如何选择使用这两种风格：
成熟度(总的来说SOAP在成熟度上优于REST)
SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通（在部分复杂和特殊的参数和返回对象解析上，协议没有作很细致的规定，导致还是需要作部分修正）
REST国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况，在性能和可用性上会大大高于SOAP发布的web service，但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发，因此通用性要求不高。
由于没有类似于SOAP的权威性协议作为规范，REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想，但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。
效率和易用性(REST更胜一筹)
SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。
安全性：
这点其实可以放入到成熟度中，不过在当前的互联网应用和平台开发设计过程中，安全已经被提到了很高的高度，特别是作为外部接口给第三方调用，安全性可能会高过业务逻辑本身。
SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持（虽然在一些细节上还是有不兼容的问题，但是互通基本上是可以的）。
REST没有任何规范对于安全方面作说明，同时现在开放REST风格API的网站主要分成两种，一种是自定义了安全信息封装在消息中（其实这和SOAP没有什么区别），另外一种就是靠硬件SSL来保障,但是这只能够保证点到点的安全，如果是需要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题，今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO，其实是直接采用了XML-Security和XML-Signature，效率看起来也不是很高。未来REST规范化和通用化过程中的安全是否也会采用这两种规范，是未知的，但是加入的越多，REST失去它高效性的优势越多。
具体选择举例：
在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外，现在，有许多集成开发环境能够在现有代码的基础上，依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务，或者你需要一些安全功能如消息签名和加密，那么，SOAP能够确保消息的安全性。另一方面，如果你希望使用简单接口来公布一些信息，而不需要繁琐的处理过程，那么，REST也许是最佳选择。
假如我们要通讯的两个应用程序都是同一个架构的，比如都是.Net Application，或者都是Java Application，或者二者是其他对SOAP支持较好的程序，那么建议使用Soap形式来实现通讯，但如果服务的客户有使用浏览器调用服务，有使用js调用服务的需求，那么最好服务最好还是设计成Rest风格的。也就是说现阶段其实Rest的开放性，通用性都要优于SOAP.