先搞懂為什麼要有這一章：本機呼叫的方便，遠端全部沒有

在一台電腦裡，你的程式呼叫一個函式（function）再自然不過：寫下 f(x) 就好。但在分散式系統裡，程式碼被拆到不同電腦、不同處理程序（process）上跑，它們之間沒有共用的記憶體，只能靠網路互傳訊息。

問題是：直接操作網路訊息——打包、送出、等回覆、解包——非常瑣碎又容易出錯。於是工程師發明了一層中介軟體（middleware），蓋在底層的IPC（sockets、訊息傳遞、多播）之上，提供更友善的「遠端呼叫」抽象。

這整章要講的，就是這位「祕書」到底怎麼運作——而且她有三種等級的服務方式，一種比一種貼心。

直接讀原文，旁邊就是白話

這是本章開場，作者親自定義了這三種典範分別是什麼、彼此什麼關係。原文放左邊，白話導讀放右邊——先讀懂原文的氣口，再看整段在說什麼。

先定位：這位「祕書」站在整個通訊堆疊的哪一層？

電話線路本身（底層 IPC）當然還是得靠 UDP、TCP 實際把封包送出去，但你的應用程式從來不直接碰它——中間永遠隔著中介軟體這一層。點下面的方塊，看看每一層各管什麼。

招牌互動：三張卡，看懂誰疊在誰上面

把三種典範想成「交辦事情」的進化——一種比一種讓你少操心。

同樣是「遠端呼叫」，什麼時候該挑哪一種？

三種典範不是「新的比舊的好」，而是解決不同層次的問題。挑錯層次，不是白費工夫，就是自找麻煩。

小試身手

抓住這三層的關係，你就摸到整章的骨架了。來兩題：

先認識三個動作：整個協定就靠它們撐起來

上一站我們看到訊息傳遞是分散式系統唯一的溝通方式。這一站要落地：client-server 之間最基本的對話樣式，就是請求-回覆協定（request-reply protocol）。

正常情況下，這種通訊是同步的（synchronous）：client 送出請求後會阻塞（block），站在原地等，直到 server 的回覆回來才繼續往下跑。它也可以是可靠的——因為 server 的回覆本身，就等於是對 client 的一份「確認收到」。

整個協定靠三個基本動作互相接力：

直接讀原文，旁邊就是白話

這是課本描述請求-回覆協定最核心的幾句話——先講同步阻塞的性質，再講三個動作怎麼互相銜接。原文放左邊，白話導讀放右邊。

一封請求／回覆訊息，長什麼樣

請求與回覆訊息通常包含這些欄位——這是它們的「身分證」格式：

招牌互動：一次完整對話，外加「訊息遺失」分支

下面演給你看兩段劇情。第一段是順利的三步對話：doOperation → getRequest → sendReply。第二段是訊息半路搞丟時，逾時、重送、用 requestId 過濾重複執行的補救戲。按「下一步」照順序看。

重送很方便，但操作被做兩次怎麼辦

你寄信請廠商出貨，過了約定時間還沒回音（逾時）。你不知道是你的信掉了，還是對方早出貨了、只是回函在路上丟了。保險作法是再寄一次——但若對方其實已經出貨，再寄一次可能害你收到兩批貨，這就是重複執行的風險。

解法主要有兩層：一是冪等操作（idempotent operation）——有些操作天生「做幾次都一樣」，例如把開關設成 ON，重複設一百次結果都是 ON；但「餘額加 10 元」就不是冪等的，做兩次就多加了。二是讓 server 自己記得誰問過什麼：

三種交換樣式：R、RR、RRA，該挑哪一種

面對通訊失敗，可依需求挑選不同的訊息交換樣式（Spector, 1982）——不是每次對話都需要一來一回。

小試身手

從三個基本動作、到逾時重送、再到三種交換樣式，來兩題檢查一下：

先講規則：你只看得到「菜單」，看不到「廚房」

寫程式時，模組之間要溝通，通常靠程序呼叫（procedure call），或是直接讀寫對方的變數。但在分散式系統裡，第二條路完全走不通——你的程式跑在一台機器，對方的變數在另一台機器的記憶體裡，你伸手也摸不到。

所以每個模組都要有一份明確的服務介面（service interface）——它只列出「有哪些程序可以呼叫、參數是什麼型別」，完全不揭露這些程序內部到底怎麼寫。這正是用介面寫程式（programming with interfaces）的精神：使用者只管介面這層抽象，不必也不能過問實作細節。

用介面寫程式在分散式系統裡還有一個額外的好處：你甚至不必知道對方用什麼語言、什麼平台實作，這正是駕馭異質性（heterogeneity）的關鍵一步。但分散式的本質也反過來限制了介面能長什麼樣子——這就是下一段要講的。

直接讀原文，旁邊就是白話

書上這幾句話，講的是「跨程序」這個事實，會反過來限制介面能規定什麼、不能規定什麼。

語言不一樣，還能點同一份菜單嗎？

如果 client 和 server 都用同一種語言寫（例如全都用 Java），介面可以直接用那個語言定義。但真實世界常常是 client 用 Python、server 用 C++——這時候就需要一套介面定義語言（IDL）：語言中立，只負責把「有哪些程序、參數是 in 還是 out」講清楚，不綁定任何一種程式語言。

以 CORBA IDL 為例，這是課本給的範例：

struct Person {
  string name;
  string place;
  long year;
};

interface PersonList {
  readonly attribute string listname;
  void addPerson(in Person p);
  void getPerson(in string name, out Person p);
  long number();
};

招牌互動：一次 RPC 呼叫，裡面到底發生了什麼

RPC 想讓你「像呼叫本機函式一樣」呼叫遠端程序，魔法全藏在幾個自動產生的元件裡。按「下一步」，跟著一次呼叫，從 client 一路走到 server、再走回來。

這些「打包／分派」的苦工，通常不用手寫

client stub、server stub 與 dispatcher，都可以由介面編譯器從介面定義自動產生，程式設計師不必手寫——畢竟每個程序都要重複做「打包、送出、解包」這件事，交給機器生成既省事又不容易出錯。

本機呼叫恰好一次，遠端呼叫呢？

本機程序呼叫的語意很單純：exactly once（恰好一次），除非當機，否則每個程序剛好執行一次。但遠端呼叫的請求或回覆訊息會遺失、server 會當機——沒辦法輕易保證恰好一次。於是書上用三種容錯措施，組合出三種不同的呼叫語意：

動手配配看：呼叫語意配上對應的容錯措施

把下面三種呼叫語意，拖到它對應的容錯措施組合上。配完按「對答案」。

小試身手

從介面、stub、dispatcher 到呼叫語意，這一站的骨架都在這了。來兩題：

把物件搬到不同程序，會冒出什麼新問題？

物件導向程式，說穿了就是一群物件互相呼叫彼此的方法。每個物件有自己的資料、自己的方法，透過物件參考互相存取。現在把這些物件實體分散到不同程序、甚至不同電腦——這就是分散式物件。

只要方法呼叫跨越了程序或電腦的邊界，就是遠端方法呼叫（RMI）；還留在同一程序內的呼叫，就只是本機方法呼叫。一句話：物件沒變，只是呼叫的距離變遠了，但這一變，麻煩就全冒出來了。

分散式物件模型的核心概念，就靠兩件事撐起來：一個能被跨程序找到的遠端物件，加上一張指名「哪些方法可以被外人呼叫」的遠端介面——就像該員工的「對外服務窗口清單」：外人只能請他做清單上列出的事，他內部還在忙什麼雜事，外人碰不到。相對地，一般沒有遠端介面的本機物件，就像不對外的內部員工，只有同辦公室的人才能直接找他。

直接讀原文，旁邊就是白話

這幾句話界定了「遠端物件」與「遠端介面」這兩個分散式物件模型的地基。原文放左邊，白話導讀放右邊。

設計遠端物件時，幾個你會踩到的坑

知道「遠端介面」跟「遠端物件」還不夠，實作起來還有幾個反直覺的細節：

招牌互動：一次呼叫，到底繞了多遠

client 呼叫「看起來」是本機物件的 B，其實這通呼叫在背後繞了一大圈。按「下一步」，跟著這通呼叫走一遍完整路徑。

proxy 是自動生的，但也有它罷工的時候

dispatcher（分派器）與skeleton（骨架）不是手寫的——由介面編譯器自動產生，Java RMI 的 RMI 編譯器就是從遠端物件的類別直接生出 proxy、dispatcher、skeleton。

但靜態 proxy 有一個前提：client 在編譯期就要知道那個遠端介面長什麼樣。萬一不知道呢？比方說一個共享白板系統，要能顯示「編譯時還不存在的新圖形」——這種情況就得靠動態呼叫（dynamic invocation）：不再靠靜態產生的 proxy，而是用通用的 doOperation 形式，client 直接把遠端參考、方法名稱、參數包好送出去。沒有 proxy 方便，但能應付「設計時根本無法預期」的介面。

還有兩個實務細節值得記住。第一，server 通常為每個遠端呼叫配一條執行緒，避免一個呼叫卡住另一個——這意味著遠端物件的實作者必須自己處理並行存取下的狀態安全。第二，長壽的物件不必一直佔著執行中的程序：被動（passive）物件只是「方法實作＋封裝過的狀態」，需要時才由 activator 把它啟動（activation）成可被呼叫的主動（active）物件——就像平時休眠、有客人上門才開張的店面，Java RMI 就支援這種 activatable 物件。

沒人用了才回收：分散式垃圾回收怎麼運作

物件在遠端持續存在，要花記憶體。分散式垃圾回收的目標很單純：只要還有任何本機或遠端參考指向某物件，它就繼續活著；一旦沒有任何人再持有指向它的參考，就把它與佔用的記憶體回收掉。

Java 的做法以參考計數（reference counting）為基礎，跟本機垃圾回收器協同運作。每個 server 為自己的每個遠端物件維護一個holders 集合——記錄「哪些 client 程序持有指向它的遠端參考」，例如 B.holders 就是持有 B 之 proxy 的 client 集合。

萬一讀者搬家失聯，書永遠下不了架怎麼辦？

借閱名冊解決了「正常歸還」的情況，但問題來了：萬一某位讀者搬家失聯（client 程序當機），永遠不還書怎麼辦？名冊上的名字會永遠掛著，書永遠下不了架。

解法是租約（lease）：借書不是「無限期」，而是「借你到某個時間點」。租期從 client 發出 addRef 開始算，結束於時間到、或 client 主動發出 removeRef。到期不續借，館員就視同歸還，把名字劃掉；讀者若還想繼續借，必須在到期前主動續約。

小試身手

從遠端物件、proxy 呼叫鏈，到租約如何救回失聯 client 的資源——來兩題檢查一下：

先講規則：介面上要「老實承認」自己是遠端的

Java RMI 最厲害的地方，是把 Java 的物件模型直接延伸到分散式世界——你呼叫遠端物件的方法，語法跟呼叫本機物件幾乎一樣，連型別檢查都照樣管用。

但它並不打算把「這其實是遠端呼叫」這件事藏起來，反而刻意在介面上暴露分散式的本質，要求兩件事：

一、遠端介面要繼承 Remote（在 java.rmi 套件裡）；二、介面裡的每個方法都必須宣告 throws RemoteException——這等於在合約上白紙黑字寫明「這次呼叫可能因故無法送達」，逼呼叫者事先正視、處理遠端失敗，而不是天真地假設遠端呼叫一定跟本機呼叫一樣穩。

直接讀原文，旁邊就是白話

下面是課本定義兩個遠端介面 Shape、ShapeList 的原文片段，以及類別下載機制的說明。原文放左邊，白話導讀放右邊。

生活妙喻：傳一份影本，還是傳一把鑰匙？

Java RMI 傳參數時，分兩種截然不同的方式，課本用一個很生活化的畫面幫你分清楚。

實例拆解：共享白板的一次呼叫

用白板程式舉例最清楚。GraphicalObject 是可序列化、存放圖形狀態的一般物件；Shape、ShapeList 則是遠端介面。

public interface Shape extends Remote {
  int getVersion() throws RemoteException;
  GraphicalObject getAllState() throws RemoteException;
}

public interface ShapeList extends Remote {
  Shape newShape(GraphicalObject g) throws RemoteException;
  Vector allShapes() throws RemoteException;
  int getVersion() throws RemoteException;
}

Shape s = shapeList.newShape(myGraphicalObject);

這一行呼叫背後發生的事：myGraphicalObject 是一般可序列化物件，以值複製送到 server，server 端拿到的是一份新副本；server 用這份狀態建立一個型別為 Shape 的遠端物件，並把它的遠端物件參考回傳給 client。client 拿到的 s 之後每次呼叫（例如 s.getVersion()），都是真正打到 server 上那個物件的遠端呼叫。

Java 的招牌能力：類別自動下載

Java 設計上允許類別（class）從一個虛擬機下載到另一個虛擬機，這對遠端呼叫特別有用——接收端不一定要事先準備好每一個會用到的類別。

具體規則承接上一節的傳值／傳參考：如果接收端沒有某個「以值傳遞之物件」的類別，程式碼會自動下載；如果接收端拿到一個遠端參考，卻沒有對應 proxy 的類別，proxy 程式碼也會自動下載。

白板範例正好示範了這件事：假設一開始的 GraphicalObject 不支援文字，某個 client 自己寫了一個處理文字的子類別，把它的實例當參數丟給 server。這個新類別的程式碼會自動從那個 client 下載到 server，再下載到其他需要的 client——沒有人需要事先約好都裝這個類別。

招牌互動：看 RMIregistry 怎麼幫 client 找到 server

client 要呼叫遠端物件，得先拿到至少一個遠端物件參考——這第一個參考是怎麼來的？答案是 RMIregistry——Java RMI 的 binder，維護一張「名稱 → 遠端物件參考」的對應表。按「下一步」看 server 怎麼註冊、client 怎麼查到它。

小試身手

從介面規則、傳值傳參考，到 RMIregistry 的註冊查詢，來兩題檢查一下：