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

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

Command模式經(jīng)常Java的Reflect一起使用，因為系統(tǒng)的事件處理系統(tǒng)是處于動態(tài)變化的，隨著功能要求擴(kuò)展，就可能有動態(tài)變化事件處理響應(yīng)系統(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)系，通過這個配置文件，運(yùn)行時動態(tài)裝載相應(yīng)的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)，客戶段向服務(wù)器發(fā)出不同編碼代號，意味著不同的請求，不同的請求有不同的Handler進(jìn)行 處理，Handler接口是:

public class Handler{

　　public byte[] handleRequest();

}

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

public class EnterHandler implements Handler{

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

}

調(diào)用Handler時是:

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

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

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

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

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

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

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

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

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

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

比如用戶提請服務(wù)器計算一個數(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);

　　　　}

　　}

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

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

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

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

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

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

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

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

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

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

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

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

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

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