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的潛在性能。
