遠程過程調用（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）支持推和拉兩種協同工作模式。推模式由事件發布者產生事件，主動推送事件到事件代理，然后由事件代理推送事件到事件訂閱者。

拉模式由事件訂閱者主動請求發布者產生事件，事件代理等待訂閱者的事件請求到來，然后再請求事件發布者產生事件并發布到事件代理。

【兩種模式區別：推模式中的事件訂閱者是被動地等待事件到來，而拉模式中的訂閱者則是主動地請求事件。】

參考自【網絡分布計算與軟件工程第二版馮玉琳等著】