远程调用由于遭到网络通讯的约束，所以往往不能完全的支持编程言语的一切特性。比如C言语函数中的指针类型参数，就无法经过网络传递出去。因此远程调用的函数定义，能用言语中的什么特性，不能用什么特性，是需求在设计方案是规则上去的。

这种规则假设太严厉，会影响运用者的易用性;假设太普遍，则能够招致远程调用的功用低下。如何去设计一种方式，把编程言语中的函数，描画成一个远程调用的函数，也是需求思索的成绩。很多方案采用了配置文件这种通用的方式，而另外一些方案可以直接在源代码中外面加特殊的注释。

普通来说，编译型言语如C/C++只能采用源代码依据配置文件生成的方案，虚拟机型言语如C#/JAVA可以采用反射机制结合配置文件(设置是在源代码中用特殊注释来替代配置文件)的方案，假设是脚本言语就更复杂，有时分连配置文件都不需求，由于脚本本人就可以充任。总之远程调用的接口要满足怎样的约束，也是一个需求细心思索的成绩。

3. 用什么办法来完成网络通讯

远程调用最重要的完成细节，就是关于网络通讯。用何种通讯方式来承载远程调用的成绩，细化上去就是两个子成绩：用什么样的效劳顺序提供网络功用?用什么样的通讯协议?

远程调用系统可以本人直接对TCP/IP编程来完成通讯，也可以委托一些其他软件，比如Web效劳器、音讯队列效劳器等等……也可以运用不同的网络通讯框架，如Netty/Mina这些开源框架。通讯协议则普通有两层：一个是传输协议，比如TCP/UDP或许高层一点的HTTP，或许本人定义的传输协议;另外一个是编码协议，就是如何把一个编程言语中的对象，序列化和反序列化成为二进制字节流的方案，盛行的方案有JSON、Google Protocol Buffer等等，很多开发言语也有本人的序列化方案，如JAVA/C#都自带。以上这些技术细节，应该选择运用哪些，直接关系到远程调用系统的功用和环境兼容性。

以上三个成绩，就是远程调用细叱必须思索的中心选型。依据每个方案所面对的约束不同，他们都会在这三个成绩上做出取舍，从而顺应其约束。但是如今并不存在一个“万能”或许“通用”的方案，其缘由就是：在如此复杂的一个系统中，假设要照顾的特性越多，需求付出的成本(易用性代价、功用开支)也会越多。

下面，我们可以研讨下业界现存的各种远程调用方案，看他们是如何在这三个方面做平衡和选择的。

业界方案举例

1. CORBA

CORBA是一个“陈旧”的，雄心勃勃的方案，他试图在完成远程调用的同时，还完成跨言语的通讯的义务，因此其复杂水平是最高的，但是它的设计思想，也被后来更多的其他方案所学习。在通讯对象的定位上，它运用URL来定义一个远程对象，这是在互联网时代十分容易接受的。其对象的内容则限定在C言语类型上，并且只能传递值，这也是十分容易了解的。为了能让不同言语的顺序通讯，所以就必需要在各种编程言语之外独立设计一种仅仅用于描画远程接口的言语，这就是所谓的IDL：Interface Description Language 接口描画言语。

用这个办法，你就可以先用一种超然于一切言语之外的言语来定义接口，然后运用工具自动生成各种编程言语的代码。这种方案关于编译型言语简直是独一选择。CORBA并没有对通讯成绩有任何商定，而是留给详细言语的完成者去处置，这也许是他没有普遍盛行的缘由之一。

实践上CORBA有一个十分著名的承袭者，他就是Facebook公司的Thrift框架。Thrift也是运用一种IDL编译生成多种言语的远程调用方案，并且用C++/JAVA等多种言语残缺的完成了通讯承载，所以在开源框架中是特别有召唤力的一个。Thrfit的通讯承载还有个特点，就是能组合运用各种不同的传输协议和编码协议，比如TCP/UDP/HTTP配合JSON/BIN/PB……这让它简直可以选择任何的网络环境。

Thrift的模型相似下图，这里有的stub表示“桩代码”，就是客户端直接运用的函数方式顺序;skeleton表示“骨架代码”，是需求顺序员编写详细提供远程效劳功用的模板代码，普通对模版做填空或许承袭(扩展)即可。这个stub-skeleton模型简直是一切远程调用方案的标配。

2. JAVA RMI

JAVA RMI是JAVA虚拟机自带的一个远程调用方案。它也是可以运用URL来定位远程对象，运用JAVA自带的序列化编码协议传递参数值。在接口描画上，由于这是一个仅限于JAVA环境下的方案，所以直接用JAVA言语的Interface类型作为定义言语。用户经过完成这个接口类型来提供远程效劳，同时JAVA会依据这个接口文件自动生成客户端的调用代码供调用者运用。他的底层通讯完成，还是用TCP协议完成的。在这里，Interface文件就是JAVA言语的IDL，同时也是skeleton模板，供开发者来填写远程效劳内容。而stub代码则由于JAVA的反射功用，由虚拟机直接包办了。

这个方案由于JAVA虚拟机的支持，运用起来十分复杂，完全按照标志的JAVA编程办法就可以轻松处置成绩，但是这也仅仅能在JAVA环境下运转，限制了其适用的范围。鱼与熊掌不可兼得，易用性和适用性往往是相互抵触的。这和CORBA/Thrift追求最大范围的适用性有很大的差别，也招致了两者在易用性上的不同。

3. Windows RPC

Windows中对RPC支持是比较早和比较完善的。首先它经过GUID来查询对象，然后运用C言语类型作为参数值的传递。由于Windows的API主要是C言语的，所以关于RPC功用来说，还是要用一种IDL来描画接口，最后生成.h和.c文件来消费RPC的stub和skeleton代码。而通讯机制，由于是操作系统自带的，所以运用内核LPC机制承载，这一点还是对运用者来说比较方便的。但是也限制了只能用于Windows顺序之间做调用。

4. WebService & REST

(责任编辑：admin)