引言：

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

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

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

回頁(yè)首

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

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

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

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

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

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

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

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

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

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

回頁(yè)首

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

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

遠(yuǎn)程引用傳遞： 
對(duì)于EJB對(duì)象而言,，它由兩個(gè)接口（home接口和remote接口）和一個(gè)類組成,。容器會(huì)根據(jù)ejb規(guī)范來生成實(shí)現(xiàn)上面兩個(gè)接口的類（我們分別稱為xxxEJBHome對(duì)象和xxxEjbObject對(duì)象）。在較多的容器的實(shí)現(xiàn)方案中,，xxxEJBHome對(duì)象使用了factory模式來創(chuàng)建xxxEjbObject對(duì)象,；xxxEjbObject對(duì)象則采用proxy模式，作為xxxBean的代理類,。在生成以上兩個(gè)對(duì)象的同時(shí)，容器會(huì)從部署文件中讀取關(guān)于安全,、事務(wù),、持久性等服務(wù)并在xxxEjbObject對(duì)象和xxxEJBHome對(duì)象中添加以上服務(wù)的代碼,。而且xxxEJBHome對(duì)象和xxxEjbObject對(duì)象都是分布式對(duì)象，我們?cè)诖酥挥懻搙xxEjbObject對(duì)象,。所謂分布式對(duì)象,，從本質(zhì)上來講，分為3個(gè)部分：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的對(duì)象）可以是任何對(duì)象，包括EJB和一般的Java類甚至是用任何語(yǔ)言寫的corba客戶端,。

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

回頁(yè)首

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

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

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

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

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

回頁(yè)首

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

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

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

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

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

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

回頁(yè)首

總結(jié)

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

關(guān)于作者