設計模式是經驗的文檔化，核心在於理解其「意圖」而非死守類圖。在分散式、多層 J2EE 系統中，Observer 模式用於解耦模型層（EJB）與視圖層（Web Tier），支援多視圖同步、並行開發、需求變更隔離。但 Java 標準庫的 Observable/Observer 設計用於單一 JVM，直接套用至 EJB 會遭遇序列化與遠端參考傳遞的根本衝突。
實作 Serializable 的物件以「複製傳遞」方式在層間流動。Entity Bean 持有 Web 層物件的副本，修改副本不影響原物件 — 這是典型 Observer 實作失效的主因。
EJB 物件由 Home/Remote 介面與 Bean 類組成，容器產生 Stub（客戶端 Proxy）與 Skeleton（伺服端）。Stub 透過 Socket 將方法簽名傳給 Skeleton，再委派 Object Server 執行邏輯。此機制下，遠端介面參數傳遞實為「遠端參考傳遞」，修改會反映至伺服端真實物件。
Web 類實作 Serializable 作為 Observer，Entity Bean 為 Subject。執行時 Entity Bean 持有 Observer 副本，通知副本無法更新原始 Web 物件。
Web 類持有 Entity Bean 遠端參考（Stub），事件發生時通知 Stub，真實 Entity Bean 獲更新。Observer 物件序列化傳入 Entity Bean 僅供讀取資料，值傳遞語意正確。但需注意：EJB 業務方法必須拋出 RemoteException，標準 Observer 介面需調整。
JMS 發布/訂閱模天然符合 Observer 意圖：鬆耦合、非同步、動態訂閱。結合訊息驅動 Bean（MDB）作為消費者，容器自動管理 JMS 連線、交易、並發，開發者僅需實作 onMessage()。
單一 MDB 作為多個 Session Bean 的 Facade，Session Bean 再作為多個 Entity Bean 的 Facade，構建分層訊息路由。MDB 本質為無狀態 Session Bean 變體，無 Remote/Home 介面，配置為特定 Topic/Queue 客戶端。
在 J2EE 實作 Observer 模式，關鍵不在於複製教科書類圖，而在於深入理解分散式參數傳遞語意、EJB 容器服務模型、JMS 訊息語意。正確選擇：單機用標準庫、同步遠端用反轉角色 EJB 方案、非同步解耦用 JMS/MDB。掌握模式意圖，因地制宜調整實作細節，才能構建健壯、可擴展的企業級應用。
