Rpc,Rmi,Soap

  Rpc(远程过程调用)被设计为在应用程序之间通信的平台中立的方式，他不会理会操作系统以及语言之间的差异，所以Rpc支持多种语言。而Rmi(Remote method Invocation)只支持Java写的应用程序。另外Rmi调用远程过程方法，允许方法返回Java对象以及基本数据类型，而Rpc不支持对象的概念，传送到RPC服务的消息由外部数据表示(External Data Representation,XDR)语言表示，这种语言抽象了字节序类和数据类型结构之间的差异。只有由XDR定义的数据类型才能被传递，RPC不允许传递对象。可以说RMI是面向对象方式的Java RPC。RMI和RPC之间最主要的区别在于方法是如何被调用的。在RMI中，远程接口调用每个远程方法都有方法签名，如果一个方法在服务器上执行，但是没有匹配的签名被添加到这个远程接口上，那么这个新方法就不能被RMI客户方所调用。在RPC中，当一个请求到达RPC服务器的时候，这个请求就包含了一个参数集和一个文本值，通常形成 classname.methodname的形式，这就向RPC服务器表明，被请求的方法在为“classname”的类中，名叫“methodname”。然后RPC服务器就会去搜索与之对应匹配的类和方法，并把它作为那种方法参数类型的输入，这里的参数类型是与RPC请求中的类型是匹配的，一但匹配成功，这个方法就被调用了，其结果被编码后返回客户方。

  RPC(Remote Procedure call,远程过程调用)是建立在Socket之上的。越底层，代码越复杂，灵活性越高，效率越高；越上层，抽象封装的越好，代码越简单，效率越差。Socket和PRc的区别就说明了这一点。

RPC作为普遍的C/S开发方法,开发效率高效,可靠.但RPC方法的基本原则是－－以模块调用的简单性忽略通讯的具体细节,以便程序员不用关心C/S之间的通讯协议,集中精力对付实现过程.这就决定了 RPC生成的通讯包不可能对每种应用都有最恰当的处理办法,与Socket方法相比,传输相同的有效数据,RPC占用更多的网络带宽.、

RPC的结构原理及其调用机制

如前所述RPC其实也是种C/S的编程模式，有点类似C/S Socket 编程模式，但要比它更高一层。当我们在建立RPC服务以后，客户端的调用参数通过底层的RPC传输通道，可以是UDP，也可以是TCP（也即TI-RPC—无关性传输），并根据传输前所提供的目的地址及RPC上层应用程序号转至相应的RPC应用程序服务端，且此时的客户端处于等待状态，直至收到应答或Time Out超时信号。当服务器端获得请求消息，则会根据注册RPC时告诉RPC系统的例程入口地址，执行相应的操作，并将结果返回至客户端。

当一次RPC调用结束后，相应线程发送相应的信号，客户端程序才会继续运行。

在这个过程中，一个远程过程是有三个要素来唯一确定的：程序号、版本号和过程号。

程序号是用来区别一组相关的并且具有唯一过程好的远程过程。一个程序可以有一个或几个不同的版本，而每个版本的程序都包含一系列能被远程调用的过程，通过版本的引入，使得不同版本下的RPC能同时提供服务。每个版本都包含有许多可供远程调用的过程，每个过程则有其唯一标示的过程号

基于RPC的应用系统开发

通过以上对RPC原理的简介后，我们再来继续讨论如何来开发基于RPC的应用系统。

一般而言在开发RPC时，我们通常分为三个步骤：

a、 定义说明客户/服务器的通信协议:这里所说的通信协议是指定义服务过程的名称、调用参数的数据类型和返回参数的数据类型，还包括底层传输类型（可以是UDP或TCP），当然也可以由RPC底层函数自动选择连接类型建立TI-RPC。最简单的协议生成的方法是采用协议编译工具，常用的有Rpcgen，我会在后面实例中详细描述其使用方法。

b、  开发客户端程序。

c、  开发服务器端程序。

开发客户端和服务器端的程序时，RPC提供了我们不同层次的开发例程调用接口。不同层次的接口提供了对RPC不同程度控制。一般可分为5个等级的编程接口，接下来我们分别讨论一下各层所提供的功能函数。

具体开发使用的函数和方法就不写了，非java。

RPC:

RPC（Remote Procedure CallProtocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

工作原理　　运行时,一次客户机对服务器的RPC调用,其内部操作大致有如下十步：

　　1.调用客户端句柄；执行传送参数

　　2.调用本地系统内核发送网络消息

　　3.消息传送到远程主机

　　4.服务器句柄得到消息并取得参数

　　5.执行远程过程

　　6.执行的过程将结果返回服务器句柄

　　7.服务器句柄返回结果，调用远程系统内核

　　8.消息传回本地主机

　　9.客户句柄由内核接收消息

　　10.客户接收句柄返回的数据 

RMI目前使用Java远程消息交换协议JRMP（Java Remote MessagingProtocol）进行通信，但由于JRMP是专为Java对象制定的，因此，RMI对于用非Java语言开发的应用系统的支持不足。不能与用非Java语言书写的对象进行通信。

          xml-rpc 这种远程过程调用使用http作为传输协议，XML作为传送信息的编码格式。Xml-Rpc的定义尽可能的保持了简单，但同时能够传送、处理、返回复杂的数据结构。

远程调用协议效率比较：

1.直接调用

直接调用类似本地调用的所有耗时都接近0，说明程序处理几乎没有花费时间，记录的全部时间都是远程调用耗费的。

2.RMI调用

与设想的一样，RMI理所当然是最快的，在几乎所有的情况下，它的耗时都是最少的，特别是在数据结构复杂，数据量大的情况下，与其他协议的差距尤为明显。

3.Hession调用

Hession较RMI要慢20%左右，这只是在数据量特别大，数据结构特别复杂的时候才能体现出来，中等或少量数据的时候，hession并不比RMI慢。

Hession的好处是精简高效，可以跨语言使用，而且协议规范公开，我们可以针对任何语言对其协议进行开发实现。

目前已有实现的语言有：java, c++, .net, python, ruby。还没有delphi的实现。
另外，Hessian与WEB服务器结合非常好，借助WEB服务器的成熟功能，在处理大量用户并发访问时会有很大优势，在资源分配，线程排队，异常处理等方面都可以由成熟的WEB服务器保证。而RMI本身并不提供多线程的服务器。而且，RMI需要开防火墙端口，Hessian不用。

4.HttpInvoker调用

ttpInvoker调用
HttpInvoker是SpringFramework提供的JAVA远程调用方法，使用java的序列化机制处理对象的传输。从测试结果看，其效率还是可以的，与RMI基本持平。
不过，它只能用于JAVA语言之间的通讯，而且，要求客户端和服务端都使用SPRING框架。
另外，HttpInvoker 并没有经过实践的检验，目前还没有找到应用该协议的项目。

5.web service调用

 本次测试选用了apache的AXIS组件作为WEB SERVICE的实现，AXIS在WEB SERVICE领域相对成熟老牌。
为了仅测试数据传输和编码、解码的时间，客户端和服务端都使用了缓存，对象只需实例化一次。但是，测试结果显示，web service的效率还是要比其他通讯协议慢10倍。
如果考虑到多个引用指向同一对象的传输情况，web service要落后更多。因为RMI，Hessian等协议都可以传递引用，而web service有多少个引用，就要复制多少份对象实体。
Web service传输的冗余信息过多是其速度慢的原因之一，监控发现，同样的访问请求，描述相同的数据，web service返回的数据量是hessian协议的6.5倍。另外，WEB SERVICE的处理也很毫时，目前的xml解析器效率普遍不高，处理xml <-> bean很毫资源。从测试结果看，异地调用比本地调用要快，也从侧面说明了其毫时主要用在编码和解码xml文件上。这比冗余信息更为严重，冗余信息占用的只是网络带宽，而每次调用的资源耗费直接影响到服务器的负载能力。（MS的工程师曾说过，用WEB SERVICE不能负载100个以上的并发用户。）