java的事件模式在圖形界面領(lǐng)域的事件模式已經(jīng)有很多文章介紹，但是在服務器端我們會碰到更多的事件模式，在這里給大家總結(jié)一下：

事件直接驅(qū)動模式
事件模式的第一個要求就是性能的要求，需要直接而且快，Command模式是必須經(jīng)常使用的，主要適合于迅速處理 前臺的命令，Command模式往往是系統(tǒng)架構(gòu)的重要部分，也是流程控制的主要模式。

Command模式經(jīng)常Java的Reflect一起使用，因為系統(tǒng)的事件處理系統(tǒng)是處于動態(tài)變化的，隨著功能要求擴展，就可能有動態(tài)變化事件處理響應系統(tǒng)，以Struts中action為例，我們知道，StrUCts的一個主要配置文件是struts-config.xml 如下：

<struts-config>
　　<action-mappings>
　　　　<action path="/login" type="com.javaPRo.struts.LoginAction"/>
　　　　<action path="/logout" type="com.javapro.struts.LogoutAction"/>
　　</action-mappings>
</struts-config>

它實際是個command和event的映射關(guān)系，通過這個配置文件，運行時動態(tài)裝載相應的Action，完成Command模式， 我們檢查LoginAction代碼，就可以看出Command模式的基本特征：

public final class LoginAction extends Action {
　　public ActionForward execute(ActionMapping mapping,
　　　　ActionForm form, HttpServletRequest request, HttpServletResponse response)
　　　　throws Exception {
　　　　　　　　.................
　　}
}

很明顯，典型的Command模式需要有一個接口.接口中有一個統(tǒng)一的方法，這里統(tǒng)一的方法就是execute;

比如我們有個實時系統(tǒng)，客戶段向服務器發(fā)出不同編碼代號，意味著不同的請求，不同的請求有不同的Handler進行 處理，Handler接口是:

public class Handler{

　　public byte[] handleRequest();

}

不同性質(zhì)的處理過程繼續(xù)這個Handler接口，如負責進入系統(tǒng)的處理過程

public class EnterHandler implements Handler{

　　public byte[] handleRequest(){
　　//具體業(yè)務處理
　　......
　　}

}

調(diào)用Handler時是:

//從cache中獲取這個requestId對應的Handler
Handler handler = (Handler)cache.get(new Integer(reqId));
//調(diào)用handler的統(tǒng)一方法handleRequest()
byte[] outInf = handler.handleRequest();

以上是常用的一個事件驅(qū)動模式。它的特點是靠一個事件直接啟動對應的事件處理器。

Chain of Responsibility職責鏈模式也應該屬于這類，當事件到達后，讓這個事件在我們提供的一批處理器中逐個挑選適合的處理器進行處理，這個模式缺點是顯然的，性能喪失在逐個挑選 上，一般不推薦使用，這個模式適合在我們無法預知發(fā)生的事件內(nèi)容時使用，因為不知道發(fā)生事件的具體情況， 我們就無法在程序運行前事先為其指派相應的處理器，只能靠運行時，事件自己去摸索“撞運氣”。

監(jiān)控式事件模式
監(jiān)控式事件模式就不同于事件直接驅(qū)動模式，它是借助第三者來監(jiān)控和觸發(fā)事件，這類事件的特點是： 有一個觀察者置身事外在定期獨立運行著，我們將我們要監(jiān)聽的事件向這個觀察者注冊，這樣觀察者就 代替我們來監(jiān)聽這個事件，應用客戶端通過觀察者來獲得事件狀況。

應用客戶端有三種與觀察者交互的方式：1.直接融合 2.推方式 3.拉方式。

直接融合就是說應用客戶端自己就是觀察者，兩者融合，這樣無疑應用客戶端獲得的觸發(fā)時間是最快的；

推方式就是觀察者一旦偵測到事件發(fā)生，立即將事件Push推到應用客戶端；拉方式類似收取郵件，應用客戶端在需要時才從觀察者拉取事件。

JDK 1.4的None Blocking I/O是監(jiān)控式事件模式的典型實現(xiàn)，Selector顯然是一個監(jiān)控I/O的第三者，當有外部事件進來，通過 調(diào)用Slector.select方法可以獲得外部事件，從而進行處理，可參考我的本欄文章。

監(jiān)控式事件模式適合使用在觸發(fā)性質(zhì)的場合，比如數(shù)據(jù)庫后端觸發(fā)器 界面觸發(fā) I/O觸發(fā) 狀態(tài)改變觸發(fā)等。

我們以一個信件觸發(fā)為例，這其實是個Observer應用例子:

比如用戶提請服務器計算一個數(shù)據(jù)，假如用戶同時要求將計算結(jié)果向自己信箱發(fā)一封，那么我們看如何設(shè)計？ 按照通常思維，這是一個次序問題，先在內(nèi)存中計算數(shù)據(jù)，然后將結(jié)果發(fā)送到他的信箱，最后返回結(jié)果到用戶端， 我們知道信件的發(fā)送是耗時的，因此，有可能網(wǎng)絡(luò)的原因造成信件發(fā)送很慢，這是用戶就一直等不到他的計算結(jié)果， 很顯然，我們使用監(jiān)控式事件模式來解決，讓發(fā)信的事件由監(jiān)控者去完成，只要需要時觸發(fā)就可以了：

public class Computer extends Observable{

　　public Computer(){
　　　　//將sendMailObserver設(shè)定為本類的觀察者。
　　　　addObserver(new sendMailObserver());
　　}

　　.......

　　public void compute(String input,boolean needEmail,String email){

　　　　//計算操作
　　　　.........

　　　　if (needEmail){

　　　　　　//設(shè)置變化點
　　　　　　 setChanged();
　　　　　　//假如需要發(fā)送email，我們把email地址作為參數(shù)傳送過去
　　　　　　 notifyObservers(email);

　　　　}　　　
　　}

｝

我們再來看監(jiān)控觀察者代碼是如何寫的？

public class sendMailObserver implements Observer{

　　public void update(Observable obj,Object email){

　　　　if (email instanceof String){

　　　　　　sendMail(email);

　　　　}

　　}

}
這樣服務器在執(zhí)行compute方法時，就沒有發(fā)送郵件的等待，一直接繼續(xù)執(zhí)行。

監(jiān)控式事件模式和事件直接驅(qū)動模式可以在一個系統(tǒng)一起使用，外界信號通過事件直接驅(qū)動模式啟動系統(tǒng)處理模塊， 系統(tǒng)處理模塊處理過程中，可以通過監(jiān)控式事件模式來觸發(fā)其它后臺任務。這樣一個架構(gòu)非常適合實時處理系統(tǒng)。

既然事件處理模式是眾多應用系統(tǒng)的基本模式，那么應該可以形成一個框架標準，JMX的notification Model就是這樣一個架構(gòu)設(shè)計。

JMX Notification Model
我們知道，JMX是提供了一種對MBean資源執(zhí)行控制和配置的治理機制，但這只是復雜的，分布式的系統(tǒng)中的一部分， 還有需要資源能夠感應狀態(tài)改變或者特定事件變化的機制，這就是JMX Notification Model。 在JMX Notification Model中均可以實現(xiàn)"事件直接驅(qū)動模式"和"監(jiān)控式事件模式"，這取決于你的應用需求。

JMX Notification Model答應MBean通過調(diào)用notifications廣播事件，接受者只要注冊為一個listerner， JMX的 MBean notification model 將會激活這個listerner注冊一次，然后將一直接受到 來自廣播者發(fā)出的各種事件。

事件模式有三個角色，第一個是事件發(fā)出者producer 然后是事件接受者Consumer,第三個 是要傳輸?shù)氖录MX notification model也是這樣分別依靠下列組件來實現(xiàn)這三個角色：

A. NotificationBroadcaster接口, 事件廣播發(fā)出者， 這個接口答應監(jiān)聽者在需要發(fā)出的notification中注冊他們感愛好的事件。
B. 通用事件(Notification)，這是我們要傳輸?shù)氖录?Notification事件能被直接使用，也能成為子類，這些都依靠于隨同事件傳輸?shù)男畔ⅰ?通過使用通用事件類型，監(jiān)聽者將能接受來自廣播者所有類型的事件。
C. NotificationListener接口, 事件監(jiān)聽者或者接受者， 用于接受來自廣播者的任何notification信號。
D. NotificationFilter接口, 這個接口為notification的監(jiān)聽者提供一個對發(fā)出事件的過濾器。
E. NotificationEmitter 接口, 擴展了NotificationBroadcaster接口，當刪除監(jiān)聽者時答應更多的控制功能。

只要是MBean，就既可以成為notification的發(fā)布廣播者，也可以成為notification的監(jiān)聽者接受者，或者同時兩者都可以。

Attribute Change Notifications
Attribute Change Notifications是一種非凡的notification, 任何時候MBean屬性attribute 被修改，外界能夠被通知到。

在JMX架構(gòu)中，MBean能夠在屬性attribute變化發(fā)生時，發(fā)出通知，關(guān)于診斷屬性變化的機制以及觸發(fā) 通知事件并不屬于JMX規(guī)定部分，每個MBean可以有自己獨立的實現(xiàn)方式。

Timer Service
Timer Service觸發(fā)器是在規(guī)定的日期和事件發(fā)出通知，它能夠一一個恒定的間隙不斷重復發(fā)出通知， 通知可以發(fā)往所有注冊為接受timer通知的對象，Timer Service也是一個可治理的MBean，答應應用系統(tǒng)設(shè)置 一個可配置的調(diào)度程度。

Monitoring
通過使用monitoring service，一個或多個MBean屬性將按規(guī)定間隔時間被監(jiān)視， 對于被觀察的Mbean,監(jiān)視器monitor將從它上面獲得一個值，叫derived gauge，這個derived gauge可以是 被觀察屬性的原值，也可以是一個數(shù)字性屬性連續(xù)被觀察值之差。

當derived gauge值滿足一系列條件時，每個monitor server將會發(fā)出一個特定類型的通知。 這些條件都是在monitor被初始化時設(shè)定的，也可以通過monitor MBean的治理接口動態(tài)設(shè)定。

根據(jù)MBean內(nèi)部屬性值類型有三種monitor:

A.CounterMonitor - 使用Java的整數(shù)類型來觀察屬性，有一個行為特征：
a. 總是大于或等于零.
b. 能自增.
c. 能回滾.

B.GaugeMonitor - 使用java的整數(shù)或浮點類型觀察屬性。象gauge(測量儀器) 要么上升　要么下降減少。

C StringMonitor - 使用String類型觀察屬性.

事件處理架構(gòu)
JMS是基于Socket的一種消息處理框架，原理類似于監(jiān)控式事件模式，但是JMS已經(jīng)把這種模式上升到架構(gòu)的高度。不同JVM間也依靠JMS消息可以實現(xiàn)事件系統(tǒng)（注重是系統(tǒng)，不簡單是一個小事件了）的觸發(fā)和激活。

從上面JMS的架構(gòu)圖可以看出事件三個角色Producer和Consumer以及事件信息本身Message．JMS就是在Producer和Consumer之間建立一個連接Connection．

JMS可實現(xiàn)同步或異步的事件觸發(fā)機制，分別是通過Poin to Point(拉方式)和Pubilsh/Subscibe(推方式)具體完成，在分布式計算環(huán)境中，異步機制是非常重要，可以起到解耦作用，因為分布環(huán)境中單點錯誤或通訊問題是經(jīng)常發(fā)生的，整個分布式系統(tǒng)不能總是依靠同步機制來可靠地傳遞事件或notification．

由此可見，事件處理模式從Java諸多架構(gòu)到我們具體應用程序，隨處可見，根據(jù)不同的應用需求選擇不同的事件處理模式，才能真正挖掘Java的潛在性能。