RPC的设计问题

对于RPC,一直以来都不是很理解,今晚准备跟着《分布式系统概念与设计》再看一遍。
先理解三个概念:
1. 接口编程--RPC推动的编程风格
2. 和RPC关联的调用语义
3. 透明性的关键问题和它如何与远程过程调用相关联


【RPC的设计问题】接口编程
大多数现代编程语言提供了把一个程序组织成一系列能彼此通信的模块的方法。模块之间的通信可以依靠模块间的过程调用,或者直接访问另外一个模块中的变量来实现。为了控制模块之间可能的交互,必须为每一个模块定义显示的接口,模块接口指定可供其他模块访问的过程和变量。实现后的模块就隐藏了除接口以外的所有信息。只要模块的接口保持相同,模块的实现就可以随意改变而不影响到模块的使用者。
分布式系统的接口:在分布式程序中,模块能够运行在不同的进程中。在客户/服务器模型中,每个服务器提供一个客户端可用的方法集合。例如,文件服务器能够提供读、写文件的方法。“服务接口”(service interface)这个术语涉及服务器提供的过程的说明、定义每个过程参数的格式。
在分布式编程中使用接口有很多好处,这都源于接口和实现之间重要的分离:
1. 对于任何形式的模块化编程,程序员只需要关心服务接口提供的抽象而不需要去关注它们的实现细节。
2. 推演(潜在的异构)分布式系统,程序员也无需知道编程语言或者实现服务(在分布式系统中管理异构性的重要一步)的底层平台。
3. 只要接口(外部视图)保持不变,实现可以改变,所以该方法自然地支持软件的演化。更确切来说,接口也能改变只要保持和原版本相互兼容。
服务接口的定义受分布式底层的基础设施的影响:
1. 对于运行在某个进程中的客户模块去访问另外一个进程中模块的变量是不可能的。因此,服务接口不能指定到变量的直接访问。注意,CORBA IDL接口能指定属性,这看起来打破了该规则。虽然不能直接地访问该属性,但是可以通过自动添加到接口中的一些getter和setter过程来访问。
2. 在本地过程调用中使用的参数传递机制(例如传递值和传递引用)不适用于调用者和过程在不同的进程中的情况。尤其是不支持传递引用。而在分布式程序中,模块接口的过程规范用input或output来描述参数,或有时都给出描述。input参数通过发送请求消息中的参数值传递到远程服务器,然后将它们作为参数提供给在服务器上执行的操作。在应答消息中返回的output参数被作为调用的结果或改变调用环境中相应的变量的值。当某个参数同时作为输入/输出参数时,那么在请求和应答消息中都必须传送它的值。
3. 本地和远程模块的另外一个不同是,一个过程的地址对于一个远程过程是无效的。因此,地址不能作为参数和远程模块的调用结果被返回。
这些约束对于接口规范的定义语言有很重要的影响,下面将讨论。
接口定义语言:RPC机制可以集成到某种编程语言中,只要该语言包含适当的定义接口的表示法,并允许将输入和输出参数映射成该语言中正常使用的参数。当一个分布式应用的所有部分都是用同一种语言编写时,这种方法非常有效。因为它允许程序员用一种语言(例如Java)实现本地调用和远程调用,所以这种方法也很方便。
然而,许多现有的有用的服务是用C++和其他语言编写的。为了满足远程访问的需要,允许程序采用包括Java在内的各种语言进行编写是非常有益的。接口定义语言(Interface definition languages,IDL)允许以不同语言实现过程以便相互调用。IDL提供了一个定义接口的表示法,接口中操作的每个参数可以在类型中声明之外附加输入输出类型说明。

    推荐阅读