引言：

設計模式是經驗的文檔化。它是對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述。更通俗的來說，它是一個問題/解決方案對。一旦我們掌握了設計模式，就等于擁有了一支強有力的專家隊伍。它甚至能夠使面向對象的新手利用前人的經驗找出職責明確的類和對象，從而獲得優雅的解決方案。由于設計模式也是重構的目標，如果在設計的初期適當地引入設計模式，可以減少重構的工作量。

但是，我們也不能陷入模式的陷阱，為了使用模式而去套模式，那樣會陷入形式主義。我們在使用模式的時候，一定要注意模式的意圖（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即改變參數對象），只不過這種引用是遠程引用。可以參見本文的示范代碼，了解遠程引用。

回頁首

在J2EE中實現Observer模式的典型錯誤

為了說明問題，我們從一個簡單例子開始著手：假設一個或多個位于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集成運行環境中通過。

回頁首

使用JMS在J2EE中實現Observer模式

消息系統允許分開的未耦合的應用程序之間可靠地異步通信。它使消息產生者和使用者之間的關系是一種"松耦合"的關系。對于使用者，它不在乎誰產生了消息，產生者是否仍在網絡上以及消息是什么時候產生的。這就允許建立動態的，可靠的和靈活的系統。整個的子系統能被修改而不會影響系統的其他部分。其實，領域層和表示層的分離的目的也就在于此。

在消息系統中，通常有兩種消息類型：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模式。

總結

以上是生活随笔為你收集整理的Observer模式在J2EE中的实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。