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封装格式
4. WSDL的描述方式
5. UDDI UDDI是一种目录服务，企业可以使用它对Webservices进行注册和搜索
RMI （Remote Method Invocation）
RMI 采用stubs 和 skeletons 来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的，通过该机制RMI就好比它是本地工作，采用tcp/ip协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于JAVA语言，客户机与服务器紧耦合；
JRMP是Java持有的，基于流的协议，完成一个对象的Java到Java的远程调用；IIOP是CORBA对象请求代理之间交流的协议，Java中使得程序可以和其他语言的CORBA实现互操作性的协议，和JRMP互补。
优点：支持分布式对象、跨平台，stubs/skeletons机制；缺点：不能跨语言。
JMS（Java Messaging Service）
JMS是Java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。JMS支持两种消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即点对点和发布订阅模型。
优点：支持异步通信、消息produce和recept松耦合。
EJB(enterprise java bean)
ejb是java EE 中的一个规范，该规范描述了分布式应用程序需要解决的问题，例如事务处理、安全、日志、分布
式等，而同时呢，sun公司也实现了自己定义的这一个标准，相当于自己颁布一个标准然后，又给出了实现供别人使
用，实现以很多API的方式提供给用的人。
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的架构中可以看出，JNDI分为三部分，应用程序编程接口（API）和服务供应商接口（SPI），前者Java应用程序访问各
种命名和目录服务，开发上层应用的程序员就不必去关心底层具体的技术细节，后者则是设计来供任意一种服务的供应商（也包括
目录服务供应商）使用，这一层一般由供应商去完成。
对比学习
EJB与JMS的关系
它们其实是没有多大关系的，它们都是java EE的规范，ejb的一种类MDB实现了JMS规范，当然是先JMS规范的
不止有ejb的mdb，比如apache ActiveMQ也是
Web service与EJB
对这两个常常有点迷惑人，因为他们都实现了分布式应用调用，虽然他们很相似但是还是有很多区别的，首先通
信协议是不一样的，ejb采用rmi-iiop协议，Web service利用http协议传输数据，优点常识的都知道http协议支持的较广
泛，从这点来看Web Service层次要高一些、俗话说站得高看得远。
Webservice主要关注于解决异构系统、不同语言系统通信，其关注的是分布式服务开发、着手点要高、站的角度高，
而ejb可以看做是分布式编程平台，通过容器和组件，简化了程序开发、调试和部署等它关注的是分布式组件开发，粒
度小。
Web service可以看做是异构系统、异构语言系统间通信的一个标准，而ejb只属于J2EE规范的一部分。
ejb底层用rmi-iiop协议进行通信，防火墙会阻止；web service是基于http协议进行通信，防火墙不会阻止。
几者的区别与联系
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请求中的类型是匹配的。一旦匹配成功，这个方法就被调用了，其结果被编码后返回客户方。
JMS和RMI
采用JMS 服务，对象是在物理上被异步从网络的某个JVM 上直接移动到另一个JVM 上（是消息通知机制）
而RMI 对象是绑定在本地JVM 中，只有函数参数和返回值是通过网络传送的（是请求应答机制）。
RMI一般都是同步的，也就是说，当client调用Server的一个方法的时候，需要等到对方的返回，才能继续执行
client端，这个过程调用本地方法感觉上是一样的，这也是RMI的一个特点。
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就没考虑非java的东西。但是好在现在大多数的jms provider（就是JMS的各种实现产品）都解决了异构问
题。相比WebService的跨平台各有千秋吧。
RMI与JNDI
RMI是一个能够建立一个N层应用，扩展中间层，将属于不同应用的分布对象包容起来，使用跨过中间层来共享
数据和逻辑，能真正实现分布式的解决方案。通过它能够在运行时，通过网络发现不同机器的服务程序，并对应用间
的通信进行管理，能确保像本地一样使用远程对象。在RMI中使用rmiregistry时存在一定的问题，rmiregistry只是用作
测试基于RMI的应用程序的一种方法，当停止并重新启动rmiregistry时，需要中心注册其中的所有对象，针对这种情
况，一般会使用JNDI为远程对象使用一个命名和目录服务，使用LDAP来保存远程对象。RMI只是一种远程对象访问
的接口规范，遵循此规范的对象可被远程访问，但是要使用rmi的服务注册程序注册之后才能够被远程调用。JNDi是
Java命名和目录服务访问接口，通过JNDI，可以访问已经在命名和目录服务器中注册的服务对象，因此，可以把rmi
对象注册在Ldap命名目录服务器中，然后使用ＪＮＤＩ对远程对象进行访问和调用
各个对象都有侧重点，作为架构师（技术选型）、性能优化都需要基本知识给予强大的理论支持，各有千秋，充
分结合项目的实际情况做出选择。