RPC、RMI与MOM与组播 通信原理

远程过程调用（RPC）：

即对远程站点机上的过程进行调用。当站点机A上的一个进程调用另一个站点机上的过程时，A上的调用进程挂起，B上的被调用过程执行，并将结果返回给调用进程，使调用进程继续执行【B上的被调用过程的参数和执行结果在调用和被调用进程之间是通过消息传递来实现的，表现为C/S关系】

为实现不同站点机上的RPC，调用和被调用进程各方都要保留一个用于存放过程参数和执行结果的运行栈，分别称为客户和服务器的存根，为各自不同地址空间上的运行提供支持。

实现步骤【对外是透明的】：

1.调用客户存根，填参数。

2.客户存根打包参数消息，调用客户机操作系统。

3.客户机操作系统向远程服务器操作系统发送消息，客户进程等待返回结果。

4.服务器操作系统接收参数消息并伟给服务器存根。

5.服务器存根解包参数消息，启动服务器进程。

6.服务器进程执行完成，将结果填入给服务器存根。

7.服务器存根打包结果消息，调用服务器操作系统。

8.服务器操作系统发送结果消息到客户机操作系统。

9客户机操作系统接收结果消息，并传给客户进程。

10.客户存根解包结果消息，返回给客户进程。

进程方法调用（RMI）：

它可以被看作是RPC的Java版本。但是传统RPC并不能很好地应用于分布式对象系统。而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用。客户要访问一个远程对象时，首先要与该对象进行绑定，对象引用包含足够的信息实现实现这种对象绑定，绑定的结果就是在进程的地址究竟内生成一个对象代理。对象代理的界面与对象本身的界面完全一样。【多数情况下这种绑定是由系统自动完成的，对用户是透明的】

工作原理：方法调用从客户对象经占位程序（Stub)、远程引用层(Remote Reference Layer)和传输层（Transport Layer）向下，传递给主机，然后再次经传 输层，向上穿过远程调用层和骨干网（Skeleton），到达服务器对象。 占位程序扮演着远程服务器对象的代理的角色，使该对象可被客户激活。 远程引用层处理语义、管理单一或多重对象的通信，决定调用是应发往一个服务器还是多个。传输层管理实际的连接，并且追追踪可以接受方法调用的远程对象。服务器端的骨干网完成对服务器对象实际的方法调用，并获取返回值。返回值向下经远程引用层、服务器端的传输层传递回客户端，再向上经传输层和远程调用层返回。最后，占位程序获得返回值。【客户进程在访问一个分布式对象之前，首先要在该进程的局部地址空间内生成一个该对象的代理，对象代理可作为客户进程的局部对象使用，其功能类似于RPC中的客户存根，可以将客户的访问请求和参数打包成消息，发送给服务器，由服务器方相应的存根解包消息后调用对应方法】序列化和反序列化

实现步骤：

 1、生成一个远程接口 

 2、实现远程对象(服务器端程序) 

 3、生成占位程序和骨干网(服务器端程序) 

 4、编写服务器程序 

 5、编写客户程序 

 6、注册远程对象 

 7、启动远程对象

缺点：RPC和RMI都要求调用方和被调用方的进程处于执行状态。如果被调用过程或者对象所处的站点处于停机或故障状态，则RMI或RPC调用失败。

面向消息的通信：

为克服RMI和RPC的上述缺点，其采用持久通信模式，在发送方发送消息时，不要求接收方进程正在运行；在接收方进程接收消息时，不要求发送方进程也在工作。应用A需要发送一个消息给位于不同站点机的另一个应用B，首先调用消息队列接口将该消息发给与之相连的通信服务器，放入消息队列A，再由队列管理器将引消息通过底层网络发送给与接收方站点机相连接的通信服务器，放入消息队列B。在接收方，应用B调用消息队列接口从本地的队列B中取得消息。

面向消息的中间件：MOM 指的是利用高效可靠的消息传递机制【消息队列】进行平台无关的数据交流，是一种持久异步通信系统，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可在分布环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM 中间件产品有IBM 的MQSeries、BEA 的MessageQ 、Apache的ActiveMQ等。

消息中间件一般有两种传递模型：点对点模型（PTP）和发布-订阅模型（Pub/Sub）。
1. 点对点模型（P2P）
点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发动到由某个名字标识的特定消费者。这个名字实际上对应于消息服务中的一个队列（Queue），在消息传动给消费者之前它被存储在这个队列中。队列可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。
2 发布-订阅模型（Pub/Sub）【基于组播的通信方式】
发布-订阅模型用称为主题（topic）的内容分层结构代替了PTP 模型中的惟一目的地，发送应用程序发布自己的消息，指出消息描述的是有关分层结构中的一个主题的信息。希望接收这些消息的应用程序订阅了这个主题。订阅包含子主题的分层结构中的主题的订阅者可以接收该主题和其子主题发表的所有消息。

组播通信：
【广播】一个进程将消息发往系统中的所有进程【组播】一个进程同时将消息发往一个进程组中的每个成员

组播通信优点：发送方只需要一次消息的组播发送，而不是要求发送方多次反复发地执行消息发送操作。进程组中的进程可以固定，也可以动态组织，进程组可动态加入一个新的进程，或者删除一个进程组成员。

组播适用场景：组播是分布式系统进程协同工作的一种需求

1.基于容错目的，分布式系统的一组服务器提供相同的一个服务，客户方请求服务时，系统将该服务请求组播给这些服务器组的每个成员，并执行相同的服务操作。【即使服务器组有一个或多个服务器失效，客户方请求仍能产生满意的结果】

2.基于数据存储的安全性考虑，数据备份是最经常使用的方法，即相同的一组数据同时存储在若干个不同的服务器上。为保证数据备份的数据一致性，当一个服务器上存储的数据发生改变时，就要将这种改变的信息组播到其它各个服务器，对数据进行及时更新。

3.在提供事件机制的分布式系统中，当事件发生时，就要将事件通知组播给与该事件相关的所有进程，激发并执行相应的动作。

IP组播是一种最简单的组播实现方式，只能通过UDP得到。与基于IP的P2P数据通信一样，不能保证组播消息能全部准确无误地到达组中每个进程。

发布/订阅系统（Pub/Sub）基于事件的协同机制。用户在使用事件前，必须分别注册进程为事件的提供者或者使用者，进程以这两种角色参与事件通信。提供者和使用者之间通过事件服务器传递事件。事件的提供者将事件发送给事件服务器，事件的使用者在使用事件之前必须在事件服务器注册其订阅条件，表示对系统中的某些事件感兴趣，而事件服务器则保证将所发布的事件及时组播给所有对之感兴趣的事件使用者。在发布/订阅系统中，事件的提供者称为发布者（Publisher），事件的使用者称为订阅者（Subscriber），发布者和订阅者统称为客户，事件服务器称为事件代理（Event Broker EB），负责事件在各客户之间的连接和发送。所有客户连接到事件代理上，既可作为事件的发布者，也可作为事件的订阅者。

发布/订阅系统（Pub/Sub）支持推和拉两种协同工作模式。推模式由事件发布者产生事件，主动推送事件到事件代理，然后由事件代理推送事件到事件订阅者。

拉模式由事件订阅者主动请求发布者产生事件，事件代理等待订阅者的事件请求到来，然后再请求事件发布者产生事件并发布到事件代理。

【两种模式区别：推模式中的事件订阅者是被动地等待事件到来，而拉模式中的订阅者则是主动地请求事件。】

参考自【网络分布计算与软件工程第二版冯玉琳等著】