概述

目前的分布式架构主要由corba和JavaEE搭建，JavaEE优点是跨平台，开发成本低周期短，不需要学习IDL语言；CORBA的优点是服务器响应速度更快。决定这些架构优缺点的，主要就是通信方式。

在分布式服务框架中，一个最基础的问题就是远程服务是怎么通讯的。在Java领域中有很多可实现远程通讯的技术：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等，这些名词之间到底是些什么关系呢，它们背后到底是基于什么原理实现的呢，了解这些是实现分布式服务框架的基础知识，而如果在性能上有高的要求的话，那深入了解这些技术背后的机制就是必须的。

基本原理
要实现网络机器间的通讯，首先得来看看计算机系统网络通信的基本原理，在底层看，网络通信需要做的就是将流从一台计算机传输到另外一台计算机，基于传输协议和网络IO来实现，传输协议：http、tcp、udp等，都是基于Socket为某类应用场景而扩展出的传输协议，网络IO，主要有bio、nio、aio三种方式，所有的分布式应用通讯都基于这个原理而实现，只是为了应用的易用性，各种语言通常都会提供一些更为贴近应用易用的应用层协议。

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

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

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

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

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

RPC

Remote Procedure Call，RPC使用C/S方式，基于TCP协议，发送请求到服务器，等待服务器返回结果。优点是跨语言跨平台，C端、S端有更大的独立性，缺点是不支持对象，不支持异步调用，无法在编译器检查错误，只能在运行期检查。
它是早期的支持分布式一种，缺点：RPC是面向过程的远程调用，不支持面向对象，不支持异步调用。

WebService

WS提供的服务是基于web容器的，底层使用HTTP协议，类似一个远程的服务提供者，是一种请求应答的机制，跨系统跨平台。通过一个servlet提供服务。
首先客户端从服务器得到WS的WSDL，同时在客户端声称一个代理类(Proxy Class) 这个代理类负责与WS服务器进行Request 和Response 当一个数据（XML格式的）被封装成SOAP格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析，然后对事物进行处理，处理结束以后再对这个计算结果进行SOAP包装，然后把这个包作为一个Response发送给客户端的代理类(Proxy Class)，同样地，这个代理类也对这个SOAP包进行解析处理，继而进行后续操作。这就是WS的一个运行过程。
WS大体上分为5个层次:

HTTP传输信道
XML的数据格式
SOAP封装格式
WSDL的描述方式
UDDI UDDI是一种目录服务，企业可以使用它对Webservices进行注册和搜索

RMI

Remote Method Invocation，RMI 采用stubs 和 skeletons 来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的，通过该机制RMI就好比它是本地工作，采用tcp/ip协议，客户端直接调用服务端上的一些方法。JRMP是Java特有的，基于流的协议，完成一个对象的Java到Java的远程调用；IIOP是CORBA对象请求代理之间交流的协议，Java中使得程序可以和其他语言的CORBA实现互操作性的协议，和JRMP互补。
优点：强类型，编译期可检查错误，支持分布式对象、跨平台，stubs/skeletons机制；
缺点：只能基于JAVA语言，客户机与服务器紧耦合；

JMS

Java Messaging Service，JMS的客户端之间可以通过JMS进行异步的消息传输，支持两种消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即点对点和发布订阅模型。
优点：支持异步通信、消息produce和recept松耦合。

EJB

Enterprise Java Bean，JavaEE规范之一，描述分布式应用程序需要解决的问题，例如事务处理、安全、日志、分布式等。
EJB是按照java服务器接口定义的java类，可以理解为一个特殊的java类，放在容器里容器可以帮助该类管理事务、分布式、安全等，一般小的程序不会用到，只有大型分布式系统才会用到EJB，EJB是一个java类或是一个组件，颗粒较小，这也是与Webservice的区别之一，可以被其它一个或多个模块调用。
包含三种类型的Bean，可以通过注释JPA一个规范来标记，其中有一种Bean，叫MDB，消息驱动bean，其通信机制涉及JMS协议。
EJB可以进行远程调用，但是不能够跨语言，EJB是同步调用。
EJB异步调用指的是EJB的MDB异步通信。

JNDI

Java Naming and Directory Interface，Java命名与目录接口，包含两个服务，命名服务将名称和对象联系起来，用名称访问对象；目录服务是一种命名服务，在这种服务里，对象不但有名称，还有属性。
使用JNDI，一个J2EE应用程序可以存储和动态获取任何类型的命名Java对象。因为JNDI不依赖于任何特定的执行，应用程序可以使用 JNDI访问各种命名目录服务，包括现有的诸如LDAP、NDS、DNS、NIS、COS命名和RMI注册等服务。这使得J2EE应用程序可以和传统的应用程序和系统共存。

JNDI分为三部分，应用程序编程接口（API）和服务供应商接口（SPI），前者Java应用程序访问各种命名和目录服务，开发上层应用的程序员就不必去关心底层具体的技术细节，后者则是设计来供任意一种服务的供应商（也包括目录服务供应商）使用，这一层一般由供应商去完成。

对比

EJB与JMS

都是JavaEE的规范，EJB的一种类MDB实现JMS规范，实现JMS规范的不止有EJB的MDB，比如ActiveMQ也是。

WebService与EJB

都实现分布式应用调用：

通信协议不一样，EJB采用rmi-iiop协议（防火墙会阻止），WS利用HTTP协议传输数据（防火墙不会阻止）
WS主要关注于解决异构系统、不同语言系统通信，关注分布式服务开发、着手点要高、站的角度高，而EJB可以看做是分布式编程平台，通过容器和组件，简化程序开发、调试和部署等，它关注的是分布式组件开发，粒度小
WS可以看做是异构系统、异构语言系统间通信的一个标准，而EJB只属于J2EE规范的一部分

RPC与RMI

RPC和RMI之间的一个重要差别是RPC用快速而不够可靠的UDP协议，RMI用低速而可靠的TCP/IP协议。

RPC 跨语言，而 RMI只支持Java。
RMI 调用远程对象方法，允许方法返回 Java 对象以及基本数据类型，而RPC 不支持对象的概念，传送到 RPC服务的消息由外部数据表示 (External Data Representation, XDR) 语言表示，这种语言抽象字节序类和数据类型结构之间的差异。只有由 XDR 定义的数据类型才能被传递，RMI 是面向对象方式的 Java RPC。
在方法调用上，RMI中，远程接口使每个远程方法都具有方法签名。如果一个方法在服务器上执行，但是没有相匹配的签名被添加到这个远程接口上，那么这个新方法就不能被RMI客户方所调用。

在RPC中，当一个请求到达RPC服务器时，这个请求就包含一个参数集和一个文本值，通常形成“classname.methodname”的形式。

JMS与RMI

JMS服务，对象是在物理上被异步从网络的某个JVM 上直接移动到另一个JVM上（是消息通知机制）
而RMI对象是绑定在本地JVM 中，只有函数参数和返回值是通过网络传送的（是请求应答机制）。
RMI一般都是同步的，当Client调用Server的方法时，需要等到对方的返回，才能继续执行Client端，这个过程调用本地方法感觉上是一样。
JMS，一般只是一个点发出一个Message到Message Server，发出之后一般不会关心谁消费这个message。
一般RMI应用是紧耦合，JMS应用相对来说是松散耦合应用。

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 provider（就是JMS的各种实现产品）都解决异构问题。

RMI与JNDI

RMI是一个能够建立一个N层应用，扩展中间层，将属于不同应用的分布对象包容起来，使用跨过中间层来共享数据和逻辑，能真正实现分布式的解决方案。通过它能够在运行时，通过网络发现不同机器的服务程序，并对应用间的通信进行管理，能确保像本地一样使用远程对象。在RMI中使用rmiregistry时存在一定的问题，rmiregistry只是用作测试基于RMI的应用程序的一种方法，当停止并重新启动rmiregistry时，需要中心注册其中的所有对象，针对这种情况，一般会使用JNDI为远程对象使用一个命名和目录服务，使用LDAP来保存远程对象。RMI只是一种远程对象访问的接口规范，遵循此规范的对象可被远程访问，但是要使用rmi的服务注册程序注册之后才能够被远程调用。JNDI是Java命名和目录服务访问接口，通过JNDI，可以访问已经在命名和目录服务器中注册的服务对象，因此可以把RMI对象注册在LDAP命名目录服务器中，然后使用JNDI对远程对象进行访问和调用各个对象。