远程消息
和其他语言一样，Objective-C语言最初设的设计也是针对在同一地址空间中执行的单一进程而设计的。
然而，在面向对象的模型中，通信是运行时在相对自我包含的单元之间通过消息的方式来进行的。这种方式看起来很适合进程间的通讯。因此，不同地址空间中的对象互发消息或者是执行同一任务的不同线程之间互发消息都是不难想象的。
例如，在典型的服务器-客户端交互时，客户端可以向服务器端的指定对象发送请求，而服务器端可以向指定的客户端发送通知或者其他所需的信息；或者是在交互式应用程序中，执行一条用户命令时，可能需要大量的计算。程序可以简单地显示一个对话框，告诉用户程序忙中，请等待；也可以将运算工作交给次一级的任务来完成，而主要程序可以继续接受用户的输入。两个任务中的对象可以通过Objective-C中的消息机制来进行通讯。
分布式的对象
远程消息机制要求Objective-C的运行时能够在不同地址空间的对象之间建立链接、识别发送给远程地址空间中发送的消息，并把数据发送到不同的地址空间中。同时，还要运行时能够协调两个任务中独立的机制；运行时必须一直保有消息，直到远端接收方能够响应该消息为止。
Cocoa中就包含有对运行时的这种重要的扩展机制，那就是分布式对象架构。使用分布式对象，我们就可以向别的任务中的对象发送消息，或者是在同一任务的不同线程中执行消息对应的方法（当在同一任务的不同线程间发送远程消息的时候，系统对这些线程的处理和不同任务中的线程是一样的）。注意：Cocoa中的分布式对象系统是构建在运行时系统之上的，并没有改变Cocoa中对象的基本行为。
在发送远程消息之前，应用程序必须首先和远端接收者之间建立链接。建立链接相当于是程序中为远端的对象在自己的地址空间中建立的代理（Proxy）。然后，程序就可以通过代理和远端的对象进行通信了。代理此时就代表了远端对象，代理自身是没有自己的标识的。应用程序可以把代理就看成是远端的对象；在大多数情况下，代理就是远端对象。
图13-1就展示了远程消息。其中对象A和对象B通过代理进行通信，发送给对象B的消息被放置在队列中，直到对象B可以处理他们为止：
消息的发送者和接收者是在不同的任务中的，其调度也是相互独立的。因此在发送者发送消息的时候并不能确保接收者正好就处于空闲可以接收消息的状态。因此，到达接收者的消息会被放置到队列中，在接收者方便的时候会对其进行处理。
其中的代理并不能代替远程对象来处理消息，也不需要访问其对应的类。他并不是远端接收者的一个副本，他只是远端对象的一个轻型的替代品。从某种意义上来讲，代理是透明的；他只是接收发送者的消息，将之传递给消息的接收者并负责他们之间的通讯。他的主要功能是为别的地址空间中的对象提供一个本地的地址。然而，代理并不是完全透明的。例如，通过代理并不能直接设置或者读取对象的实例变量。
远端的接收者通常都是匿名的。他的类型是驻留在远端程序中的。发送消息的程序不需要知道接收者的程序是怎么设计的以及其中使用到了哪些类。发送程序也不必使用与接收方相同的类，只需要知道远端接收方可以响应什么消息即可。
基于上述的因素，接收远端消息的对象必须通过正式的协议来将自己的接口广而告之。发送方和接收方都要声明该协议 —— 他们都引入相同的协议声明。由于远端对象必须遵守该协议，因此接收程序必须声明他。发送方则是通过声明协议来告诉编译器他所发送的消息。这是因为他可能使用了conformsToProtocol:方法和@protocol()指令来对远端接收者进行检测。发送方不必实现协议中的任何方法。他之所以需要声明该协议只是因为是他发起消息给远端的接收者。
在文档“基础框架参考”和《分布式对象编程话题》中都谈到了分布式对象架构，其中包括类NSProxy和NSConnection。
