引言：

設(shè)計模式是經(jīng)驗(yàn)的文檔化。它是對被用來在特定場景下解決一般設(shè)計問題的類和相互通信的對象的描述。更通俗的來說，它是一個問題/解決方案對。一旦我們掌握了設(shè)計模式，就等于擁有了一支強(qiáng)有力的專家隊伍。它甚至能夠使面向?qū)ο蟮男率掷们叭说慕?jīng)驗(yàn)找出職責(zé)明確的類和對象，從而獲得優(yōu)雅的解決方案。由于設(shè)計模式也是重構(gòu)的目標(biāo)，如果在設(shè)計的初期適當(dāng)?shù)匾朐O(shè)計模式，可以減少重構(gòu)的工作量。

但是，我們也不能陷入模式的陷阱，為了使用模式而去套模式，那樣會陷入形式主義。我們在使用模式的時候，一定要注意模式的意圖（intent），而不要過多的去關(guān)注模式的實(shí)現(xiàn)細(xì)節(jié)，因?yàn)檫@些實(shí)現(xiàn)細(xì)節(jié)在特定情況下，可能會發(fā)生一些改變。不要頑固地認(rèn)為設(shè)計模式一書中的類圖或?qū)崿F(xiàn)代碼就代表了模式本身。

下面，我們來討論一下為什么要在分布式、多層系統(tǒng)中使用Observer模式。

回頁首

多層體系結(jié)構(gòu)（multi-tier architecture）：

三層體系結(jié)構(gòu)是多層體系結(jié)構(gòu)中最簡單的一種，它一般包括：

1. 表示層(presentation)－窗口、報表-
2. 業(yè)務(wù)邏輯層(business logic)－管理業(yè)務(wù)過程的任務(wù)和規(guī)則。它又可以細(xì)分為領(lǐng)域?qū)ο髮樱ù眍I(lǐng)域概念）和服務(wù)層（提供數(shù)據(jù)庫交互、安全性、打印報表）。
3. 存儲層(storage)－持久化存儲機(jī)制。如數(shù)據(jù)庫服務(wù)器等。

而Java 2平臺企業(yè)版（J2EE）是一種利用Java 2平臺來簡化諸多與多級企業(yè)解決方案的開發(fā)、部署和管理相關(guān)的復(fù)雜問題的體系結(jié)構(gòu)。它是開放的、基于標(biāo)準(zhǔn)的平臺，用以開發(fā)、部署和管理N層結(jié)構(gòu)、面向Web的，以服務(wù)器為中心的企業(yè)級應(yīng)用。

為了支持領(lǐng)域?qū)ο蟮膹?fù)用，并且使領(lǐng)域?qū)ο蟮慕涌谧兏鶐淼挠绊懽钚』?。我們將領(lǐng)域?qū)樱Ｐ停┖捅硎緦樱ㄒ晥D）相分離。

采用模型－視圖模式的意義在于：

1. 支持聚合度更高的模型定義，使模型的定義可以集中在領(lǐng)域過程的定義，而不是圖形界面上。
2. 允許將模型和用戶界面并行開發(fā)。
3. 使用戶界面的需求變化對領(lǐng)域?qū)铀斐傻挠绊懽钚』?/li>
4. 允許建立與一個現(xiàn)有的領(lǐng)域?qū)訉ο笙噙B接的新視圖，同時不影響領(lǐng)域?qū)印?/li>
5. 允許一個模型同時有多個視圖，例如使用SVG和表格。
6. 允許模型層獨(dú)立于用戶界面層執(zhí)行。

而這恰恰與Observer模式的意圖相吻合。因此我們有必要跨層來實(shí)現(xiàn)Observer模式。

其實(shí)，在應(yīng)用中更多的是采用MVC框架來架構(gòu)整個企業(yè)應(yīng)用的。在MVC框架中，Model和View之間存在著依賴關(guān)系，是Observer模式的典型應(yīng)用。當(dāng)然MVC框架還包括其它模式如Composite模式和Strategy模式。在J2EE平臺中，我們可以把Web Tier（包括Jsp和servelet和JavaBean）看作是表示層，EJB Tier看作是領(lǐng)域?qū)?。而controller可能跨距Web Tier和 EJB Tier。

在Java類庫中采用Java.util.Observable類和Java.util.Observer接口來實(shí)現(xiàn)Observer模式，它們在單個的Java VM.中運(yùn)行的很好，但如果想在EJB中使用它們就會有一些問題。這正如我們引言中提到的，模式的具體實(shí)現(xiàn)在特定情況下，可能會發(fā)生一些改變。

回頁首

值傳遞還是遠(yuǎn)程引用傳遞？

值傳遞： 
在Java RMI中要求所有的參數(shù)和返回類型是JAVA的基本類型或?qū)崿F(xiàn)Java.io.Serilizable的對象。串行化對象通過值傳遞（又名拷貝傳遞），而不是引用傳遞，這意味著在某一層中串行化對象的更并不自動影響到其它的對象。

遠(yuǎn)程引用傳遞： 
對于EJB對象而言，它由兩個接口（home接口和remote接口）和一個類組成。容器會根據(jù)ejb規(guī)范來生成實(shí)現(xiàn)上面兩個接口的類（我們分別稱為xxxEJBHome對象和xxxEjbObject對象）。在較多的容器的實(shí)現(xiàn)方案中，xxxEJBHome對象使用了factory模式來創(chuàng)建xxxEjbObject對象；xxxEjbObject對象則采用proxy模式，作為xxxBean的代理類。在生成以上兩個對象的同時，容器會從部署文件中讀取關(guān)于安全、事務(wù)、持久性等服務(wù)并在xxxEjbObject對象和xxxEJBHome對象中添加以上服務(wù)的代碼。而且xxxEJBHome對象和xxxEjbObject對象都是分布式對象，我們在此只討論xxxEjbObject對象。所謂分布式對象，從本質(zhì)上來講，分為3個部分：object server、skeleton、stub。其中object server和skeleton位于服務(wù)器端，而stub位于客戶端。Object server負(fù)責(zé)實(shí)現(xiàn)業(yè)務(wù)邏輯，skeleton負(fù)責(zé)marshal和unmarshal方法簽名。

顯然，EJB的客戶（調(diào)用EJB的對象）可以是任何對象，包括EJB和一般的Java類甚至是用任何語言寫的corba客戶端。

從EJB的客戶視角來看的話，我們只能看到一個home接口、一個remote接口（對于實(shí)體bean的話，還可以看見一個主鍵類，而bean類對客戶是不可見的）。但我們從上面的論述，我們可以知道，對于remote接口中地方法調(diào)用，實(shí)際上是多態(tài)地調(diào)用XXX_Stub類。即XXX_Stub對象對客戶具有可見性（但這種可見性是透明的，即客戶不知道這種可見性的存在）。由于，XXX_Stub對象和Object Server實(shí)現(xiàn)了相同的接口，并且Object server真正實(shí)現(xiàn)了業(yè)務(wù)邏輯。所以，當(dāng)在客戶端調(diào)用XXX_Stub對象的方法時候，XXX_Stub對象通過socket通信機(jī)制將方法簽名傳給XXX_Skeleton對象，XXX_Skeleton對象在去委托Object Server完成業(yè)務(wù)處理邏輯。因此，Object Server本身發(fā)生了改變。我們稱XXX_Stub對象是Object Server對象的遠(yuǎn)程引用，并認(rèn)為當(dāng)分布式對象作為參數(shù)傳遞的時候，是通過引用傳遞的（會產(chǎn)生副作用?D?D即改變參數(shù)對象），只不過這種引用是遠(yuǎn)程引用。可以參見本文的示范代碼，了解遠(yuǎn)程引用。

回頁首

在J2EE中實(shí)現(xiàn)Observer模式的典型錯誤

為了說明問題，我們從一個簡單例子開始著手：假設(shè)一個或多個位于web tier層的、可以序列化(serilizable)的Java類，想要從位于EJB tier層的一個或多個實(shí)體bean中獲取數(shù)據(jù)（它們可能是分布在不同EJB SERVER中）?？梢园褀eb tier層的Java類看成是一個分布式異構(gòu)數(shù)據(jù)源的聯(lián)合視圖。顯然，它們之間存在著依賴關(guān)系，而且這兩個方面要相互獨(dú)立（位于不同的tier），并且當(dāng)一個對象改變的同時，不知道具體又多少個對象有待改變。因此，我們決定用OBSERVER模式來實(shí)現(xiàn)這個問題。把bean作為observer，把Entity Bean作為Subject。參照圖三Observer設(shè)計模式

這樣，就會使起observer作用的Java類對起subject作用的entity bean中具有參數(shù)可見性，而且由于它們可以位于不同的機(jī)器上，所有我們要為Java類實(shí)現(xiàn)serilizable接口，從而使它可以在網(wǎng)絡(luò)上傳遞。看上去似乎非常完美，但不幸的是：在運(yùn)行的時候，我們發(fā)現(xiàn)客戶端并不能自動更新。究其原因，我們發(fā)現(xiàn)，原來Java類是通過值傳遞的，即entity bean中有一個Java類的拷貝，它對拷貝進(jìn)行修改，但不會影響原來的Java類。

但如果我們在另外一種情況下，把entity bean作為observer，而使Java類作為subject，由于Java類擁有entity bean的遠(yuǎn)程引用，當(dāng)subject產(chǎn)生事件的時候，會通知entity bean的遠(yuǎn)程引用作相應(yīng)的改動。此時與Java類位于不同tier的entity bean的發(fā)生了真正的改動，從而實(shí)現(xiàn)了事件通知范型的observer模式。另外，為了使observer可以觀察多個subject，entity bean要擁有observer對象，而這些observer對象（Java類）通過值傳遞被序列化到entity bean中，而且這種序列化是深度序列化。由于observer只是準(zhǔn)備從subject中提取數(shù)據(jù)，而不是改變subject的數(shù)據(jù)，所有這時候的值傳遞是可行的。但是，由于EJB規(guī)范的要求，所有商務(wù)方法都要拋出java.rmi.RemoteException,所以單純的從java類庫提供的Observer接口繼承是不行的。具體的細(xì)節(jié)可以參見ejb observer pattern文檔（參考 EJBObserverPattern）。

注意：文檔中的附帶程序在JB5.0+BAS4.5中會出現(xiàn)corba marshal的問題，如果你只是為了實(shí)現(xiàn)一個subject對應(yīng)多個observer，而且是subject將所有的數(shù)據(jù)推給observer的話，可以將EJBObserver接口中的update（EJBObservable observable，Object args）改為update（EJBObservable observable，Object args），這樣可以使程序在JB5.0+BAS4.5集成運(yùn)行環(huán)境中通過。

回頁首

使用JMS在J2EE中實(shí)現(xiàn)Observer模式

消息系統(tǒng)允許分開的未耦合的應(yīng)用程序之間可靠地異步通信。它使消息產(chǎn)生者和使用者之間的關(guān)系是一種"松耦合"的關(guān)系。對于使用者，它不在乎誰產(chǎn)生了消息，產(chǎn)生者是否仍在網(wǎng)絡(luò)上以及消息是什么時候產(chǎn)生的。這就允許建立動態(tài)的，可靠的和靈活的系統(tǒng)。整個的子系統(tǒng)能被修改而不會影響系統(tǒng)的其他部分。其實(shí)，領(lǐng)域?qū)雍捅硎緦拥姆蛛x的目的也就在于此。

在消息系統(tǒng)中，通常有兩種消息類型：1）發(fā)布/訂閱（publish/subscribe）。發(fā)布/訂閱消息系統(tǒng)支持一個事件驅(qū)動模型，消息產(chǎn)生者和使用者都參與消息的傳遞。產(chǎn)生者發(fā)布事件，而使用者訂閱感興趣的事件，并使用事件。產(chǎn)生者將消息和一個特定的主題(Topic)連在一起，消息系統(tǒng)根據(jù)使用者注冊的興趣，將消息傳給使用者。2）點(diǎn)對點(diǎn)（Peer to peer）。在點(diǎn)對點(diǎn)的消息系統(tǒng)中，消息分發(fā)給一個單獨(dú)的使用者。它維持一個"進(jìn)入"消息隊列。消息應(yīng)用程序發(fā)送消息到一個特定的隊列，而客戶端從一個隊列中得到消息。

在消息系統(tǒng)中，我們可以通過JMS和消息驅(qū)動Bean（Message-Driven Bean），用來實(shí)現(xiàn)應(yīng)用程序各個部件之間的異步消息傳遞。 對于Observer模式而言，我們會優(yōu)先地選用發(fā)布/訂閱（publish/subscribe）模型。在編寫事件的生產(chǎn)者和事件的消費(fèi)者代碼的時候，我們可以直接使用JMS API來編寫Producer和Consumer，但是如果事件的消費(fèi)者位于EJB Tier時，最好采用消息驅(qū)動Bean（Message- Driven Bean）。因?yàn)橄Ⅱ?qū)動Bean通常配置成是一個特別的主題（topic）或隊列的客戶端，作為消息的使用者。它大大地簡化了創(chuàng)建一個JMS使用者，創(chuàng)建和配置一個JMS消息使用者這些功能都交由EJB容器來做了。開發(fā)人員只需簡單地實(shí)現(xiàn)消息驅(qū)動Bean的接口，配置給EJB服務(wù)器，用來創(chuàng)建一個接收消息的商業(yè)邏輯部件。另外，當(dāng)事件的消費(fèi)者同時有多個，我們可以使用MDB Facade模式來實(shí)現(xiàn)Observer模式。

MDB Facade模式實(shí)際上是Session Bean Facade模式的一個變種，因?yàn)镸DB從本質(zhì)上來說非常類似于一個無狀態(tài)的Session Bean，只不過MDB沒有remote接口和home接口。圖四的MDB Facade模式也可以和Session Bean Facade模式結(jié)合起來使用,即一個MDB作為多個Session Bean的Facade，一個Session Bean作為多個Entity Bean的Facade。從而實(shí)現(xiàn)消息的傳遞。

代碼細(xì)節(jié)可以參照本文的示范代碼，它在BEA weblogic中運(yùn)行通過。

回頁首

總結(jié)

我們使用模式的時候，一定要注意模式的意圖（intent），而不要過多的去關(guān)注模式的實(shí)現(xiàn)細(xì)節(jié)，因?yàn)檫@些實(shí)現(xiàn)細(xì)節(jié)在特定情況下，可能會發(fā)生一些改變。在Java類庫中采用Java.util.Observable類和Java.util.Observer接口來實(shí)現(xiàn)Observer模式，它們在單個的Java VM.中運(yùn)行的很好，但如果想在EJB中使用它們就會有一些問題。本文主要討論了在分布式、多層的J2EE平臺中如何通過EJB Observer Pattern和JMS來實(shí)現(xiàn)Observer模式。

關(guān)于作者