所谓远程，就是指网络上另外一个位置，那么网络地址就是必须要输入的部分。在TCP/IP网络下，IP地址和端口号代表了运行中程序的一个入口。所以指定IP地址和端口是发起远程调用所必需的。
然而，一个程序可能会运行很多个功能，可以接收多个不同含义的远程调用。这样如何去让用户指定这些不同含义的远程调用入口，就成为了另外一个问题。当然最简单的是每个端口一种调用，但是一个IP最多支持65535个端口，而且别的网络功能也可能需要端口，所以这种方案可能会不够用，同时一个数字代表一个功能也不太好理解，必须要查表才能明白。
所以我们必须想别的方法。在面向对象的思想下，有些方案提出了：以不同的对象来归纳不同的功能组合，先指定对象，再指定方法。这个想法非常符合程序员的理解方式，EJB就是这种方案的。一旦你确定了用对象这种模型来定义远程调用的地址，那么你就需要有一种指定远程对象的方法，为了指定对象，你必须要能把对象的一些信息，从被调用方（服务器端）传输给调用方（客户端）。
最简单的方案就是客户端输入一串字符串作为对象的“名字”，发给服务器端，查找注册了这个“名字”的对象，如果找到了，服务器端就会用某种技术“传输”这个对象给客户端，然后客户端就可以调用他的方法了。当然这种传输不可能是把整个服务器上的对象数据拷贝给客户端，而是用一些符号或者标志的方法，来代表这个服务器上的对象，然后发给客户端。
如果你不是使用面向对象的模型，那么远程的一个函数，也是必须要定位和传输的，因为你调用的函数必须先能找到，然后成为客户端侧的一个接口，才能调用。针对“远程对象”（这里说的对象包括面向对象的对象或者仅仅是 函数）如何表达才能在网络上定位；以及定位成功之后以什么形式供客户端调用，都是“远程调用”设计方案中第一个重要的问题。
2 . 函数的接口形式应该如何表示远程调用由于受到网络通信的约束，所以往往不能完全的支持编程语言的所有特性。比如C语言函数中的指针类型参数，就无法通过网络传递出去。因此远程调用的函数定义，能用语言中的什么特性，不能用什么特性，是需要在设计方案是规定下来的。
这种规定如果太严格，会影响使用者的易用性；如果太宽泛，则可能导致远程调用的性能低下。如何去设计一种方式，把编程语言中的函数，描述成一个远程调用的函数，也是需要考虑的问题。很多方案采用了配置文件这种通用的方式，而另外一些方案可以直接在源代码中里面加特殊的注释。
一般来说，编译型语言如C/C++只能采用源代码根据配置文件生成的方案，虚拟机型语言如C#/JAVA可以采用反射机制结合配置文件（设置是在源代码中用特殊注释来代替配置文件）的方案，如果是脚本语言就更简单，有时候连配置文件都不需要，因为脚本自己就可以充当。总之远程调用的接口要满足怎样的约束，也是一个需要仔细考虑的问题。
3. 用什么方法来实现网络通信远程调用最重要的实现细节，就是关于网络通信。用何种通信方式来承载远程调用的问题，细化下来就是两个子问题：用什么样的服务程序提供网络功能？用什么样的通信协议？
远程调用系统可以自己直接对TCP/IP编程来实现通信，也可以委托一些其他软件，比如Web服务器、消息队列服务器等等……也可以使用不同的网络通信框架，如Netty/Mina这些开源框架。通信协议则一般有两层：一个是传输协议，比如TCP/UDP或者高层一点的HTTP，或者自己定义的传输协议；另外一个是编码协议，就是如何把一个编程语言中的对象，序列化和反序列化成为二进制字节流的方案，流行的方案有JSON、Google Protocol Buffer等等，很多开发语言也有自己的序列化方案，如JAVA/C#都自带。以上这些技术细节，应该选择使用哪些，直接关系到远程调用系统的性能和环境兼容性。
以上三个问题，就是远程调用系统必须考虑的核心选型。根据每个方案所面对的约束不同，他们都会在这三个问题上做出取舍，从而适应其约束。但是现在并不存在一个“万能”或者“通用”的方案，其原因就是：在如此复杂的一个系统中，如果要照顾的特性越多，需要付出的成本（易用性代价、性能开销）也会越多。
下面，我们可以研究下业界现存的各种远程调用方案，看他们是如何在这三个方面做平衡和选择的。
业界方案举例 1. CORBA