為 RMI 實現類 Jini 服務發現機制（上）

打破 RMI 硬編碼 URL 限制，引入 Jini 風格服務發現

傳統 RMI（遠程方法調用）要求客戶端預先知道服務提供者的完整 URL（如 rmi://host:port/ServiceName），這造成了部署與維護的不便。Jini 技術則透過發現機制讓客戶端無需知曉服務位置，自動獲取服務代理。本文將展示如何為現有 RMI 系統實現一套類 Jini 的發現機制，使客戶端擺脫硬編碼 URL 的束縛。

為何不直接使用 Jini？

雖然 Jini 提供完整的服務發現框架，但許多企業已擁有大量基於 RMI 的成熟系統。在 Jini 成為主流前，為這些系統提供優雅的遷移路徑具有現實意義。本文目標是為 RMI 服務器賦予類 Jini 的發現能力，同時保持其獨立運行特性。

RMI 與 Jini 查找機制對比

RMI 查找

客戶端必須指定服務位置：

Translator service = (Translator) Naming.lookup("rmi://theHost/SpanishTranslator");

Jini 查找

客戶端透過 ServiceDiscoveryManager 依介面類型查找服務，無需指定位置：

Class[] classes = new Class[]{Translator.class};
ServiceTemplate tmpl = new ServiceTemplate(null, classes, null);
ServiceDiscoveryManager mgr = new ServiceDiscoveryManager(null, null);
ServiceItem item = mgr.lookup(tmpl, null);
Translator service = (Translator) item.service;

Jini 模型的核心優勢在於位置透明化——客戶端不需關心服務部署在何處。

類 Jini RMI 發現機制設計

使用介面

Translator service = (Translator) RMIDiscovery.lookup(Translator.class, "Spanish");

其中 clazz 為服務介面，id 為區分同介面不同實例的唯一標識。

核心協議：多播 UDP + 單播 TCP/IP

借鑑 Jini 發現機制：

• 客戶端：向多播組發送 UDP 查詢封包，並在本地 ServerSocket 監聽單播回應。
• 服務端：監聽多播地址，收到有效查詢後透過單播 TCP 連線回傳遠程 Stub。

發現協議細節

客戶端指定 介面類別 + 唯一 ID 來識別目標服務實例，支援多實例並行部署。服務端每個 RMI 服務器即充當自身的查找服務，無需獨立註冊中心。

下篇將深入實作細節，包括多播監聽器、單播分發器、Stub 傳輸與安全性考量。