設計模式是經驗的文檔化。它是對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述。更通俗的來說，它是一個問題/解決方案對。一旦我們掌握了設計模式，就等於擁有了一支強有力的專家隊伍。它甚至能夠使面向對象的新手利用前人的經驗找出職責明確的類和對象，從而獲得優雅的解決方案。由於設計模式也是重構的目標，如果在設計的初期適當地引入設計模式，可以減少重構的工作量。
但是，我們也不能陷入模式的陷阱，爲了使用模式而去套模式，那樣會陷入形式主義。我們在使用模式的時候，一定要注意模式的意圖（intent），而不要過多的去關注模式的實現細節，因爲這些實現細節在特定情況下，可能會發生一些改變。不要頑固地認爲設計模式一書中的類圖或實現代碼就代表了模式本身。
下面，我們來討論一下爲什麼要在分佈式、多層系統中使用Observer模式。
多層體系結構（multi-tier architecture）：
三層體系結構是多層體系結構中最簡單的一種，它一般包括：
- 表示層(presentation)－窗口、報表-
- 業務邏輯層(business logic)－管理業務過程的任務和規則。它又可以細分爲領域對象層（代表領域概念）和服務層（提供數據庫交互、安全性、打印報表）。
- 存儲層(storage)－持久化存儲機制。如數據庫服務器等。
圖一：三層體系結構
而Java 2平臺企業版（J2EE）是一種利用Java 2平臺來簡化諸多與多級企業解決方案的開發、部署和管理相關的複雜問題的體系結構。它是開放的、基於標準的平臺，用以開發、部署和管理N層結構、面向Web的，以服務器爲中心的企業級應用。
爲了支持領域對象的複用，並且使領域對象的接口變更所帶來的影響最小化。我們將領域層（模型）和表示層（視圖）相分離。
採用模型－視圖模式的意義在於：
- 支持聚合度更高的模型定義，使模型的定義可以集中在領域過程的定義，而不是圖形界面上。
- 允許將模型和用戶界面並行開發。
- 使用戶界面的需求變化對領域層所造成的影響最小化。
- 允許建立與一個現有的領域層對象相連接的新視圖，同時不影響領域層。
- 允許一個模型同時有多個視圖，例如使用SVG和表格。
- 允許模型層獨立於用戶界面層執行。
而這恰恰與Observer模式的意圖相吻合。因此我們有必要跨層來實現Observer模式。
其實，在應用中更多的是採用MVC框架來架構整個企業應用的。在MVC框架中，Model和View之間存在着依賴關係，是Observer模式的典型應用。當然MVC框架還包括其它模式如Composite模式和Strategy模式。在J2EE平臺中，我們可以把Web Tier（包括Jsp和servelet和JavaBean）看作是表示層，EJB Tier看作是領域層。而controller可能跨距Web Tier和 EJB Tier。
在Java類庫中採用Java.util.Observable類和Java.util.Observer接口來實現Observer模式，它們在單個的Java VM.中運行的很好，但如果想在EJB中使用它們就會有一些問題。這正如我們引言中提到的，模式的具體實現在特定情況下，可能會發生一些改變。
值傳遞：
在Java RMI中要求所有的參數和返回類型是JAVA的基本類型或實現Java.io.Serilizable的對象。串行化對象通過值傳遞（又名拷貝傳遞），而不是引用傳遞，這意味着在某一層中串行化對象的更並不自動影響到其它的對象。
遠程引用傳遞：
對於EJB對象而言，它由兩個接口（home接口和remote接口）和一個類組成。容器會根據ejb規範來生成實現上面兩個接口的類（我們分別稱爲xxxEJBHome對象和xxxEjbObject對象）。在較多的容器的實現方案中，xxxEJBHome對象使用了factory模式來創建xxxEjbObject對象；xxxEjbObject對象則採用proxy模式，作爲xxxBean的代理類。在生成以上兩個對象的同時，容器會從部署文件中讀取關於安全、事務、持久性等服務並在xxxEjbObject對象和xxxEJBHome對象中添加以上服務的代碼。而且xxxEJBHome對象和xxxEjbObject對象都是分佈式對象，我們在此只討論xxxEjbObject對象。所謂分佈式對象，從本質上來講，分爲3個部分：object
server、skeleton、stub。其中object server和skeleton位於服務器端，而stub位於客戶端。Object server負責實現業務邏輯，skeleton負責marshal和unmarshal方法簽名。
圖二：分佈式對象
顯然，EJB的客戶（調用EJB的對象）可以是任何對象，包括EJB和一般的Java類甚至是用任何語言寫的corba客戶端。
從EJB的客戶視角來看的話，我們只能看到一個home接口、一個remote接口（對於實體bean的話，還可以看見一個主鍵類，而bean類對客戶是不可見的）。但我們從上面的論述，我們可以知道，對於remote接口中地方法調用，實際上是多態地調用XXX_Stub類。即XXX_Stub對象對客戶具有可見性（但這種可見性是透明的，即客戶不知道這種可見性的存在）。由於，XXX_Stub對象和Object Server實現了相同的接口，並且Object server真正實現了業務邏輯。所以，當在客戶端調用XXX_Stub對象的方法時候，XXX_Stub對象通過socket通信機制將方法簽名傳給XXX_Skeleton對象，XXX_Skeleton對象在去委託Object Server完成業務處理邏輯。因此，Object Server本身發生了改變。我們稱XXX_Stub對象是Object Server對象的遠程引用，並認爲當分佈式對象作爲參數傳遞的時候，是通過引用傳遞的（會產生副作用�D�D即改變參數對象），只不過這種引用是遠程引用。可以參見本文的示範代碼，瞭解遠程引用。
爲了說明問題，我們從一個簡單例子開始着手：假設一個或多個位於web tier層的、可以序列化(serilizable)的Java類，想要從位於EJB tier層的一個或多個實體bean中獲取數據（它們可能是分佈在不同EJB SERVER中）。可以把web tier層的Java類看成是一個分佈式異構數據源的聯合視圖。顯然，它們之間存在着依賴關係，而且這兩個方面要相互獨立（位於不同的tier），並且當一個對象改變的同時，不知道具體又多少個對象有待改變。因此，我們決定用OBSERVER模式來實現這個問題。把bean作爲observer，把Entity Bean作爲Subject。參照圖三Observer設計模式
圖三：Observer設計模式
這樣，就會使起observer作用的Java類對起subject作用的entity bean中具有參數可見性，而且由於它們可以位於不同的機器上，所有我們要爲Java類實現serilizable接口，從而使它可以在網絡上傳遞。看上去似乎非常完美，但不幸的是：在運行的時候，我們發現客戶端並不能自動更新。究其原因，我們發現，原來Java類是通過值傳遞的，即entity bean中有一個Java類的拷貝，它對拷貝進行修改，但不會影響原來的Java類。
但如果我們在另外一種情況下，把entity bean作爲observer，而使Java類作爲subject，由於Java類擁有entity bean的遠程引用，當subject產生事件的時候，會通知entity bean的遠程引用作相應的改動。此時與Java類位於不同tier的entity bean的發生了真正的改動，從而實現了事件通知範型的observer模式。另外，爲了使observer可以觀察多個subject，entity bean要擁有observer對象，而這些observer對象（Java類）通過值傳遞被序列化到entity bean中，而且這種序列化是深度序列化。由於observer只是準備從subject中提取數據，而不是改變subject的數據，所有這時候的值傳遞是可行的。但是，由於EJB規範的要求，所有商務方法都要拋出java.rmi.RemoteException,所以單純的從java類庫提供的Observer接口繼承是不行的。具體的細節可以參見ejb observer pattern文檔（參考 EJBObserverPattern）。
注意：文檔中的附帶程序在JB5.0+BAS4.5中會出現corba marshal的問題，如果你只是爲了實現一個subject對應多個observer，而且是subject將所有的數據推給observer的話，可以將EJBObserver接口中的update（EJBObservable observable，Object args）改爲update（EJBObservable observable，Object args），這樣可以使程序在JB5.0+BAS4.5集成運行環境中通過。
消息系統允許分開的未耦合的應用程序之間可靠地異步通信。它使消息產生者和使用者之間的關係是一種"松耦合"的關係。對於使用者，它不在乎誰產生了消息，產生者是否仍在網絡上以及消息是什麼時候產生的。這就允許建立動態的，可靠的和靈活的系統。整個的子系統能被修改而不會影響系統的其他部分。其實，領域層和表示層的分離的目的也就在於此。
在消息系統中，通常有兩種消息類型：1）發佈/訂閱（publish/subscribe）。發佈/訂閱消息系統支持一個事件驅動模型，消息產生者和使用者都參與消息的傳遞。產生者發佈事件，而使用者訂閱感興趣的事件，並使用事件。產生者將消息和一個特定的主題(Topic)連在一起，消息系統根據使用者註冊的興趣，將消息傳給使用者。2）點對點（Peer to peer）。在點對點的消息系統中，消息分發給一個單獨的使用者。它維持一個"進入"消息隊列。消息應用程序發送消息到一個特定的隊列，而客戶端從一個隊列中得到消息。
在消息系統中，我們可以通過JMS和消息驅動Bean（Message-Driven Bean），用來實現應用程序各個部件之間的異步消息傳遞。 對於Observer模式而言，我們會優先地選用發佈/訂閱（publish/subscribe）模型。在編寫事件的生產者和事件的消費者代碼的時候，我們可以直接使用JMS API來編寫Producer和Consumer，但是如果事件的消費者位於EJB Tier時，最好採用消息驅動Bean（Message- Driven Bean）。因爲消息驅動Bean通常配置成是一個特別的主題（topic）或隊列的客戶端，作爲消息的使用者。它大大地簡化了創建一個JMS使用者，創建和配置一個JMS消息使用者這些功能都交由EJB容器來做了。開發人員只需簡單地實現消息驅動Bean的接口，配置給EJB服務器，用來創建一個接收消息的商業邏輯部件。另外，當事件的消費者同時有多個，我們可以使用MDB Facade模式來實現Observer模式。
圖四：MDB facade模式
MDB Facade模式實際上是Session Bean Facade模式的一個變種，因爲MDB從本質上來說非常類似於一個無狀態的Session Bean，只不過MDB沒有remote接口和home接口。圖四的MDB Facade模式也可以和Session Bean Facade模式結合起來使用,即一個MDB作爲多個Session Bean的Facade，一個Session Bean作爲多個Entity Bean的Facade。從而實現消息的傳遞。
代碼細節可以參照本文的示範代碼，它在BEA weblogic中運行通過。
我們使用模式的時候，一定要注意模式的意圖（intent），而不要過多的去關注模式的實現細節，因爲這些實現細節在特定情況下，可能會發生一些改變。在Java類庫中採用Java.util.Observable類和Java.util.Observer接口來實現Observer模式，它們在單個的Java VM.中運行的很好，但如果想在EJB中使用它們就會有一些問題。本文主要討論了在分佈式、多層的J2EE平臺中如何通過EJB Observer Pattern和JMS來實現Observer模式。