Java的事件模式是動態響應系統重要的基礎，在圖形介面領域的事件模式已經有很多文章介紹，但是在伺服器端我們會碰到更多的事件模式，這裡本人試圖總結一下：

事件直接驅動模式

事件模式的第一個要求就是效能的要求，需要直接而且快，Command模式是必須經常使用的，主要適合於迅速處理 前臺的命令，Command模式往往是系統架構的重要部分，也是流程控制的主要模式。

Command模式經常Java的Reflect一起使用，因為系統的事件處理系統是處於動態變化的，隨著功能要求擴充套件，就可能有動態變化事件處理響應系統，以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的對映關係，通過這個配置檔案，執行時動態裝載相應的Action，完成Command模式， 我們檢查LoginAction程式碼，就可以看出Command模式的基本特徵：

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

很明顯，典型的Command模式需要有一個介面.介面中有一個統一的方法，這裡統一的方法就是execute;

比如我們有個實時系統，客戶段向伺服器發出不同編碼代號，意味著不同的請求，不同的請求有不同的Handler進行 處理，Handler介面是:

public class Handler{

　　public byte[] handleRequest();

}

不同性質的處理過程繼承這個Handler介面，如負責進入系統的處理過程

public class EnterHandler implements Handler{

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

}

呼叫Handler時是:

//從cache中獲取這個requestId對應的Handler
Handler handler = (Handler)cache.get(new Integer(reqId));
//呼叫handler的統一方法handleRequest()
byte[] outInf = handler.handleRequest();

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

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

監控式事件模式

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

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

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

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

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

監控式事件模式適合使用在觸發性質的場合，比如資料庫後端觸發器 介面觸發 I/O觸發 狀態改變觸發等。

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

比如使用者提請伺服器計算一個數據，如果使用者同時要求將計算結果向自己信箱發一封，那麼我們看如何設計？ 按照通常思維，這是一個次序問題，先在記憶體中計算資料，然後將結果傳送到他的信箱，最後返回結果到使用者端， 我們知道信件的傳送是耗時的，因此，有可能網路的原因造成信件傳送很慢，這是使用者就一直等不到他的計算結果， 很顯然，我們使用監控式事件模式來解決，讓發信的事件由監控者去完成，只要需要時觸發就可以了：

public class Computer extends Observable{

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

　　.......

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

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

　　　　if (needEmail){

　　　　　　//設定變化點
　　　　　　 setChanged();
　　　　　　//如果需要傳送email，我們把email地址作為引數傳送過去
　　　　　　 notifyObservers(email);

　　　　}　　　
　　}

｝

我們再來看監控觀察者程式碼是如何寫的？

public class sendMailObserver implements Observer{

　　public void update(Observable obj,Object email){

　　　　if (email instanceof String){

　　　　　　sendMail(email);

　　　　}

　　}

}
這樣伺服器在執行compute方法時，就沒有傳送郵件的等待，一直接繼續執行。

監控式事件模式和事件直接驅動模式可以在一個系統一起使用，外界訊號通過事件直接驅動模式啟動系統處理模組， 系統處理模組處理過程中，可以通過監控式事件模式來觸發其它後臺任務。這樣一個架構非常適合實時處理系統。

既然事件處理模式是眾多應用系統的基本模式，那麼應該可以形成一個框架標準，JMX的notification Model就是這樣一個架構設計。

JMX Notification Model

我們知道，JMX是提供了一種對MBean資源執行控制和配置的管理機制，但這只是複雜的，分散式的系統中的一部分， 還有需要資源能夠感應狀態改變或者特定事件變化的機制，這就是JMX Notification Model。 在JMX Notification Model中均可以實現"事件直接驅動模式"和"監控式事件模式"，這取決於你的應用需求。

JMX Notification Model允許MBean通過呼叫notifications廣播事件，接受者只要註冊為一個listerner， JMX的 MBean notification model 將會啟用這個listerner註冊一次，然後將一直接受到 來自廣播者發出的各種事件。

事件模式有三個角色，第一個是事件發出者producer 然後是事件接受者Consumer,第三個 是要傳輸的事件。JMX notification model也是這樣分別依靠下列元件來實現這三個角色：

A. NotificationBroadcaster介面, 事件廣播發出者， 這個介面允許監聽者在需要發出的notification中註冊他們感興趣的事件。
B. 通用事件(Notification)，這是我們要傳輸的事件。 Notification事件能被直接使用，也能成為子類，這些都依賴於隨同事件傳輸的資訊。 通過使用通用事件型別，監聽者將能接受來自廣播者所有型別的事件。
C. NotificationListener介面, 事件監聽者或者接受者， 用於接受來自廣播者的任何notification訊號。
D. NotificationFilter介面, 這個介面為notification的監聽者提供一個對發出事件的過濾器。
E. NotificationEmitter 介面, 擴充套件了NotificationBroadcaster介面，當刪除監聽者時允許更多的控制功能。

只要是MBean，就既可以成為notification的釋出廣播者，也可以成為notification的監聽者接受者，或者同時兩者都可以。

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

在JMX架構中，MBean能夠在屬性attribute變化發生時，發出通知，關於診斷屬性變化的機制以及觸發 通知事件並不屬於JMX規定部分，每個MBean可以有自己獨立的實現方式。

Timer Service
Timer Service觸發器是在規定的日期和事件發出通知，它能夠一一個恆定的間隙不斷重複發出通知， 通知可以發往所有註冊為接受timer通知的物件，Timer Service也是一個可管理的MBean，允許應用系統設定 一個可配置的排程程度。

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

當derived gauge值滿足一系列條件時，每個monitor server將會發出一個特定型別的通知。 這些條件都是在monitor被初始化時設定的，也可以通過monitor MBean的管理介面動態設定。

根據MBean內部屬性值型別有三種monitor:

A.CounterMonitor - 使用Java的整數型別來觀察屬性，有一個行為特徵：
a. 總是大於或等於零.
b. 能自增.
c. 能回滾.

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

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

事件處理架構

JMS是基於Socket的一種訊息處理框架，原理類似於監控式事件模式，但是JMS已經把這種模式上升到架構的高度。不同JVM間也依靠JMS訊息可以實現事件系統（注意是系統，不簡單是一個小事件了）的觸發和啟用。

從上面JMS的架構圖可以看出事件三個角色Producer和Consumer以及事件資訊本身Message．JMS就是在Producer和Consumer之間建立一個連線Connection．

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

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