远程通信的几种选择

远程通信的几种选择

（RPC，Webservice，RMI，JMS的区别）

方式：

RPC（Remote Procedure Call Protocol）

RPC使用C/S方式，采用http协议,发送请求到服务器，等待服务器返回结果。这个请求包括一个参数集和一个文本集，通常形成“classname.methodname”形式。优点是跨语言跨平台，C端、S端有更大的独立性，缺点是不支持对象，无法在编译器检查错误，只能在运行期检查。

Web Service

Web Service提供的服务是基于web容器的，底层使用http协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。就是通过一个servlet，提供服务出去。

首先客户端从服务器的到WebService的WSDL（网络服务描述语言），同时在客户端声称一个代理类(Proxy Class) 这个代理类负责与WebService服务器进行Request 和Response 当一个数据（XML格式的）被封装成SOAP格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析，然后对事物进行处理，处理结束以后再对这个计算结果进行SOAP包装，然后把这个包作为一个Response发送给客户端的代理类(Proxy Class)，同样地，这个代理类也对这个SOAP包进行解析处理，继而进行后续操作。这就是WebService的一个运行过程。

Web Service大体上分为5个层次:

1. Http传输信道

         2. XML的数据格式

         3. SOAP封装格式（soap用来描述传递信息的格式）

         4. WSDL的描述方式

         5. UDDI  UDDI是一种目录服务，企业可以使用它对Webservices进行注册和搜索

RMI （Remote Method Invocation）

RMI 采用stubs 和 skeletons来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的，通过该机制RMI就好比它是本地工作，采用tcp/ip协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于Java语言，客户机与服务器紧耦合。

来看下基于RMI的一次完整的远程通信过程的原理：

1. 客户端发起请求，请求转交至RMI客户端的stub类；
         2. stub类将请求的接口、方法、参数等信息进行序列化；
         3. 基于socket将序列化后的流传输至服务器端；
         4. 服务器端接收到流后转发至相应的skelton类；
         5. skelton类将请求的信息反序列化后调用实际的处理类；
         6. 处理类处理完毕后将结果返回给skelton类；
         7. Skelton类将结果序列化，通过socket将流传送给客户端的stub；
         8. stub在接收到流后反序列化，将反序列化后的java Object返回给调用者。

JMS（Java Messaging Service）

JMS是Java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。JMS支持两种消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即点对点和发布订阅模型。

JMS呢，是实现java领域远程通信的一种手段和方法，基于JMS实现远程通信时和RPC是不同的，虽然可以做到RPC的效果，但因为不是从协议 级别定义的，因此我们不认为JMS是个RPC协议，但它确实是个远程通信协议，在其他的语言体系中也存在着类似JMS的东西，可以统一的将这类机制称为消 息机制，而消息机制呢，通常是高并发、分布式领域推荐的一种通信机制，这里的主要一个问题是容错（详细见ErLang论文）。

来看JMS中的一次远程通信的过程：

1. 客户端将请求转化为符合JMS规定的Message；
         2. 通过JMS API将Message放入JMS Queue（点对点）或Topic（发布/订阅）中；
         3. 如为JMS Queue，则发送中相应的目标Queue中，如为Topic，则发送给订阅了此Topic的JMS Queue。
         4. 处理端则通过轮训JMS Queue，来获取消息，接收到消息后根据JMS协议来解析Message并处理。

几者的区别与联系

1、RPC与RMI

（1）RPC 跨语言，而 RMI只支持Java。

（2）RMI 调用远程对象方法，允许方法返回 Java 对象以及基本数据类型，而RPC 不支持对象的概念，传送到 RPC 服务的消息由外部数据表示 (External Data Representation,XDR) 语言表示，这种语言抽象了字节序类和数据类型结构之间的差异。只有由 XDR 定义的数据类型才能被传递， 可以说 RMI 是面向对象方式的 java RPC 。

（3）在方法调用上，RMI中，远程接口使每个远程方法都具有方法签名。如果一个方法在服务器上执行，但是没有相匹配的签名被添加到这个远程接口上，那么这个新方法就不能被RMI客户方所调用。在RPC中，当一个请求到达RPC服务器时，这个请求就包含了一个参数集和一个文本值，通常形成“classname.methodname”的形式。这就向RPC服务器表明，被请求的方法在为 “classname”的类中，名叫“methodname”。然后RPC服务器就去搜索与之相匹配的类和方法，并把它作为那种方法参数类型的输入。这里的参数类型是与RPC请求中的类型是匹配的。一旦匹配成功，这个方法就被调用了，其结果被编码后返回客户方。

  

2、JMS和RMI

采用JMS 服务，对象是在物理上被异步从网络的某个JVM 上直接移动到另一个JVM 上（是消息通知机制）

而RMI 对象是绑定在本地JVM 中，只有函数参数和返回值是通过网络传送的（是请求应答机制）。

RMI一般都是同步的，也就是说，当client调用Server的一个方法的时候，需要等到对方的返回，才能继续执行client端，这个过程调用本地方法感觉上是一样的，这也是RMI的一个特点。

JMS 一般只是一个点发出一个Message到Message Server,发出之后一般不会关心谁用了这个message。

所以，一般RMI的应用是紧耦合，JMS的应用相对来说是松散耦合应用。

3、Webservice与RMI

RMI是在tcp协议上传递可序列化的java对象，只能用在java虚拟机上，绑定语言，客户端和服务端都必须是java

webservice没有这个限制，webservice是在http协议上传递xml文本文件，与语言和平台无关

4、Webservice与JMS

Webservice专注于远程服务调用，jms专注于信息交换。

大多数情况下Webservice是两系统间的直接交互（Consumer <--> Producer），而大多数情况下jms是三方系统交互（Consumer <- Broker -> Producer）。当然，JMS也可以实现request-response模式的通信，只要Consumer或Producer其中一方兼任broker即可。

JMS可以做到异步调用完全隔离了客户端和服务提供者，能够抵御流量洪峰； WebService服务通常为同步调用，需要有复杂的对象转换，相比SOAP，现在JSON，rest都是很好的http架构方案；（举一个例子，电子商务的分布式系统中，有支付系统和业务系统，支付系统负责用户付款，在用户在银行付款后需要通知各个业务系统，那么这个时候，既可以用同步也可以用异步，使用异步的好处就能抵御网站暂时的流量高峰，或者能应对慢消费者。）

JMS是java平台上的消息规范。一般jms消息不是一个xml，而是一个java对象，很明显，jms没考虑异构系统，说白了，JMS就没考虑非java的东西。但是好在现在大多数的jms provider（就是JMS的各种实现产品）都解决了异构问题。相比WebService的跨平台各有千秋吧。

框架

目前java领域可用于实现远程通讯的框架或library，知名的有：JBoss-Remoting、Spring-Remoting、Hessian、Burlap、XFire(Axis)、ActiveMQ、Mina、Mule、EJB3、Thrift（facebook开源）、Dubbo（alibaba开源）等等。

Spring-Remoting

Spring-remoting是Spring提供java领域的远程通讯框架，基于此框架，同样也可以很简单的将普通的spring bean以某种远程协议的方式来发布，同样也可以配置spring bean为远程调用的bean。

是基于什么协议实现的？作为一个远程通讯的框架，Spring通过集成多种远程通讯的library，从而实现了对多种协议的支持，例如rmi、http+io、xml-rpc、binary-rpc等。 怎么发起请求？在Spring中，由于其对于远程调用的bean采用的是proxy实现，发起请求完全是通过服务接口调用的方式。

怎么将请求转化为符合协议的格式的？Spring按照协议方式将请求的对象信息转化为流，例如Spring Http Invoker是基于Spring自己定义的一个协议来实现的，传输协议上采用的为http，请求信息是基于java串行化机制转化为流进行传输。使用什么传输协议传输？支持多种传输协议，例如rmi、http等等。

响应端基于什么机制来接收请求？响应端遵循协议方式来接收请求，对于使用者而言，则只需通过spring的配置方式将普通的spring bean配置为响应端或者说提供服务端。怎么将流还原为传输格式的？按照协议方式来进行还原。

处理完毕后怎么回应？处理完毕后直接返回即可，spring-remoting将根据协议方式来做相应的序列化。

Hessian

Hessian是由caucho提供的一个基于binary-RPC实现的远程通讯library。

是基于什么协议实现的？基于Binary-RPC协议实现。怎么发起请求？需通过Hessian本身提供的API来发起请求。

怎么将请求转化为符合协议的格式的？Hessian通过其自定义的串行化机制将请求信息进行序列化，产生二进制流。

使用什么传输协议传输？Hessian基于Http协议进行传输。

响应端基于什么机制来接收请求？响应端根据Hessian提供的API来接收请求。怎么将流还原为传输格式的？Hessian根据其私有的串行化机制来将请求信息进行反序列化，传递给使用者时已是相应的请求信息对象了。

处理完毕后怎么回应？处理完毕后直接返回，hessian将结果对象进行序列化，传输至调用端。

Burlap

Burlap也是有caucho提供，它和hessian的不同在于，它是基于XML-RPC协议的。

是基于什么协议实现的？基于XML-RPC协议实现。怎么发起请求？根据Burlap提供的API。

怎么将请求转化为符合协议的格式的？将请求信息转化为符合协议的XML格式，转化为流进行传输。

使用什么传输协议传输？Http协议。

响应端基于什么机制来接收请求？监听Http请求。怎么将流还原为传输格式的？根据XML-RPC协议进行还原。

处理完毕后怎么回应？返回结果写入XML中，由Burlap返回至调用端。

XFire、Axis

XFire、Axis是Webservice的实现框架，WebService可算是一个完整的SOA架构实现标准了，因此采用XFire、Axis这些也就意味着是采用webservice方式了。

是基于什么协议实现的？基于SOAP协议。

怎么发起请求？获取到远端service的proxy后直接调用。

怎么将请求转化为符合协议的格式的？将请求信息转化为遵循SOAP协议的XML格式，由框架转化为流进行传输。

使用什么传输协议传输？Http协议。

响应端基于什么机制来接收请求？监听Http请求。怎么将流还原为传输格式的？根据SOAP协议进行还原。

处理完毕后怎么回应？返回结果写入XML中，由框架返回至调用端。

ActiveMQ

ActiveMQ是JMS的实现，基于JMS这类消息机制实现远程通讯是一种不错的选择，毕竟消息机制本身的功能使得基于它可以很容易的去实现同步/异步/单向调用等，而且消息机制从容错角度上来说也是个不错的选择，这是Erlang能够做到容错的重要基础。

是基于什么协议实现的？基于JMS协议。

怎么发起请求？遵循JMS API发起请求。

怎么将请求转化为符合协议的格式的？不太清楚，猜想应该是二进制流。

使用什么传输协议传输？支持多种传输协议，例如socket、http等等。

响应端基于什么机制来接收请求？监听符合协议的端口。

怎么将流还原为传输格式的？同问题3。

处理完毕后怎么回应？遵循JMS API生成消息，并写入JMS Queue中。

Mina

Mina是Apache提供的通讯框架，在之前一直没有提到网络IO这块，之前提及的框架或library基本都是基于BIO的，而Mina是采用NIO的，NIO在并发量增长时对比BIO而言会有明显的性能提升，而java性能的提升，与其NIO这块与OS的紧密结合是有不小的关系的。

是基于什么协议实现的？基于纯粹的Socket+NIO。

怎么发起请求？通过Mina提供的Client API。

怎么将请求转化为符合协议的格式的？Mina遵循java串行化机制对请求对象进行序列化。使用什么传输协议传输？支持多种传输协议，例如socket、http等等。

响应端基于什么机制来接收请求？以NIO的方式监听协议端口。

怎么将流还原为传输格式的？遵循java串行化机制对请求对象进行反序列化。

处理完毕后怎么回应？遵循Mina API进行返回。

MINA是NIO方式的，因此支持异步调用是毫无悬念的。

Dubbo

Dubbo就是一个java版的RPC框架，基于Netty的高性能RPC框架，由阿里巴巴开发并使用，结合zookeeper，实现流动计算架构完成资源调度和治理的工作。

应用级协议

远程服务通讯，需要达到的目标是在一台计算机发起请求，另外一台机器在接收到请求后进行相应的处理并将结果返回给请求端，这其中又会有诸如one way request(单一请求)、同步请求、异步请求等等请求方式，按照网络通信原理，需要实现这个需要做的就是将请求转换成流，通过传输协议传输至远端，远端计算机在接收到请求的流后进行处理，处理完毕后将结果转化为流，并通过传输协议返回给调用端。
         原理是这样的，但为了应用的方便，业界推出了很多基于此原理之上的应用级的协议，使得大家可以不用去直接操作这么底层的东西，通常应用级的远程通信协议会提供：

1. 为了避免直接做流操作这么麻烦，提供一种更加易用或贴合语言的标准传输格式；
         2. 网络通信机制的实现，就是替你完成了将传输格式转化为流，通过某种传输协议传   输至远端计算机，远端计算机在接收到流后转化为传输格式，并进行存储或以某种方       式通知远端计算机。

所以在学习应用级的远程通信协议时，我们可以带着这几个问题进行学习：

1. 传输的标准格式是什么？
         2. 怎么样将请求转化为传输的流？
         3. 怎么接收和处理流？
         4. 传输协议是？

不过应用级的远程通信协议并不会在传输协议上做什么多大的改进，主要是在流操作方面，让应用层生成流和处理流的这个过程更加的贴合所使用的语言或标准，至于传输协议则通常都是可选的，在java领域中知名的有：RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS，来具体的 看看这些远程通信的应用级协议：

RMI

RMI是个典型的为java定制的远程通信协议，我们都知道，在single vm（单独的虚拟机）中，我们可以通过直接调用Java object instance（java对象实例）来实现通信，那么在远程通信时，如果也能按照这种方式当然是最好了，这种远程通信的机制成为RPC（Remote Procedure Call），RMI正是朝着这个目标而诞生的。

来看下基于RMI的一次完整的远程通信过程的原理：

1. 客户端发起请求，请求转交至RMI客户端的stub类；
2. stub类将请求的接口、方法、参数等信息进行序列化；
3. 基于socket将序列化后的流传输至服务器端；
4. 服务器端接收到流后转发至相应的skelton类；
5. skelton类将请求的信息反序列化后调用实际的处理类；
6. 处理类处理完毕后将结果返回给skelton类；
7. Skelton类将结果序列化，通过socket将流传送给客户端的stub；
8. stub在接收到流后反序列化，将反序列化后的java Object返回给调用者。

根据原理来回答下之前学习应用级协议带着的几个问题：

1. 传输的标准格式是什么？
是Java ObjectStream。
2. 怎么样将请求转化为传输的流？
基于Java串行化机制（对象通过写出描述自己状态的数值来记录自己 ，这个过程叫对象的串行化）将请求的java object信息转化为流。
3. 怎么接收和处理流？
根据采用的协议启动相应的监听端口，当有流进入后基于Java串行化机制将流进行反序列化，并根据RMI协议获取到相应的处理对象信息，进行调用并处理，处理完毕后的结果同样基于java串行化机制进行返回。
4. 传输协议是？
Socket（socket是“open—write/read—close”模式的一种实现，socket就提供了这些操作对应的函数接口。）。

JAVA对RMI的支持
         java.rmi是JAVA提供 RMI 包。RMI是一种机制，能够让在某个Java 虚拟机上的对象调用另一个 Java虚拟机中的对象上的方法。可以用此方法调用的任何对象必须实现该远程接口。调用这样一个对象时，其参数为 "marshalled"并将其从本地虚拟机发送到远程虚拟机（该远程虚拟机的参数为"unmarshalled"）上。该方法终止时，将编组来自远程机的结果并将结果发送到调用方的虚拟机。如果方法调用导致抛出异常

，则该异常将指示给调用方.Remote接口用于标识其方法可以从非本地虚拟机上调用的接口。

具体方法：http://blog.csdn.net/csh624366188/article/details/7340638

XML-RPC

XML-RPC也是一种和RMI类似的远程调用的协议，它和RMI的不同之处在于它以标准的xml格式来定义请求的信息(请求的对象、方法、参数 等)，这样的好处是什么呢，就是在跨语言通讯的时候也可以使用。

来看下XML-RPC协议的一次远程通信过程：

1. 客户端发起请求，按照XML-RPC协议将请求信息进行填充；
         2. 填充完毕后将xml转化为流，通过传输协议进行传输；
         3. 接收到在接收到流后转换为xml，按照XML-RPC协议获取请求的信息并进行处理；
         4. 处理完毕后将结果按照XML-RPC协议写入xml中并返回。

同样来回答问题：

1. 传输的标准格式是？
         标准格式的XML（可扩展标记语言：标记指计算机所能理解的信息符号，通过此种标记，     计算机之间可以处理包含各种的信息比如文章等）。
         2. 怎么样将请求转化为传输的流？
         将XML转化为流。
         3. 怎么接收和处理流？
         通过监听的端口获取到请求的流，转化为XML，并根据协议获取请求的信息，进行处理       并将结果写入XML中返回。
         4. 传输协议是？
         Http。

Binary-RPC

Binary-RPC看名字就知道和XML-RPC是差不多的了，不同之处仅在于传输的标准格式由XML转为了二进制的格式。

同样来回答问题：

1. 传输的标准格式是？
         标准格式的二进制文件。
         2. 怎么样将请求转化为传输的流？
         将二进制格式文件转化为流。
         3. 怎么接收和处理流？
         通过监听的端口获取到请求的流，转化为二进制文件，根据协议获取请求的信息，进行         处理并将结果写入XML中返回。
         4. 传输协议是？
         Http。

SOAP

SOAP原意为SimpleObject Access Protocol，是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议，可以认为SOAP是XML RPC的高级版，两者的原理完全相同，都是http+XML，不同的仅在于两者定义的XML规范不同，SOAP也是Webservice采用的服务调用协 议标准，因此在此就不多加阐述了。

CORBA

Common ObjectRequest Broker Architecture（公用对象请求代理[调度]程序体系结构），是一组用来定义“分布式对象系统”的标准，由OMG(Object Menagement Group)作为发起和标准制定单位。CORBA的目的是定义一套协议，符合这个协议的对象可以互相交互，不论它们是用什么样的语言写的，不论它们运行于什么样的机器和操作系统。
CORBA在我看来是个类似于SOA的体系架构，涵盖可选的远程通信协议，但其本身不能列入通信协议这里来讲，而且CORBA基本淘汰，再加上对 CORBA也不怎么懂，在此就不进行阐述了。

JMS

JMS呢，是实现java领域远程通信的一种手段和方法，基于JMS实现远程通信时和RPC是不同的，虽然可以做到RPC的效果，但因为不是从协议级别定义的，因此我们不认为JMS是个RPC协议，但它确实是个远程通信协议，在其他的语言体系中也存在着类似JMS的东西，可以统一的将这类机制称为消息机制，而消息机制呢，通常是高并发、分布式领域推荐的一种通信机制，这里的主要一个问题是容错。

来看JMS中的一次远程通信的过程：

1. 客户端将请求转化为符合JMS规定的Message；
2. 通过JMS API将Message放入JMS Queue（点对点）或Topic（发布/订阅）中；
3. 如为JMS Queue，则发送中相应的目标Queue中，如为Topic，则发送给订阅了此Topic的JMS Queue。
4. 处理端则通过轮训JMS Queue，来获取消息，接收到消息后根据JMS协议来解析Message并处理。

回答问题：

1. 传输的标准格式是？
         JMS规定的Message。
         2. 怎么样将请求转化为传输的流？
         将参数信息放入Message中即可。
         3. 怎么接收和处理流？
         轮训JMS Queue来接收Message，接收到后进行处理，处理完毕后仍然是以Message的         方式放入Queue中发送或Multicast。
         4. 传输协议是？
         不限。