監(jiān)控式事件模式
監(jiān)控式事件模式就不同于事件直接驅(qū)動(dòng)模式，它是借助第三者來監(jiān)控和觸發(fā)事件，這類事件的特點(diǎn)是： 有一個(gè)觀察者置身事外在定期獨(dú)立運(yùn)行著，我們將我們要監(jiān)聽的事件向這個(gè)觀察者注冊(cè)，這樣觀察者就 代替我們來監(jiān)聽這個(gè)事件，應(yīng)用客戶端通過觀察者來獲得事件狀況。
應(yīng)用客戶端有三種與觀察者交互的方式：1.直接融合 2.推方式 3.拉方式。
直接融合就是說應(yīng)用客戶端自己就是觀察者，兩者融合，這樣無疑應(yīng)用客戶端獲得的觸發(fā)時(shí)間是最快的。
推方式就是觀察者一旦偵測(cè)到事件發(fā)生，立即將事件Push推到應(yīng)用客戶端；拉方式類似收取郵件，應(yīng)用客戶端在需要時(shí)才從觀察者拉取事件。
JDK 1.4的None Blocking I/O是監(jiān)控式事件模式的典型實(shí)現(xiàn)，Selector顯然是一個(gè)監(jiān)控I/O的第三者，當(dāng)有外部事件進(jìn)來，通過 調(diào)用Slector.select方法可以獲得外部事件，從而進(jìn)行處理，可參考我的本欄文章。
監(jiān)控式事件模式適合使用在觸發(fā)性質(zhì)的場(chǎng)合，比如數(shù)據(jù)庫(kù)后端觸發(fā)器 界面觸發(fā) I/O觸發(fā) 狀態(tài)改變觸發(fā)等。
我們以一個(gè)信件觸發(fā)為例，這其實(shí)是個(gè)Observer應(yīng)用例子:
比如用戶提請(qǐng)服務(wù)器計(jì)算一個(gè)數(shù)據(jù)，如果用戶同時(shí)要求將計(jì)算結(jié)果向自己信箱發(fā)一封，那么我們看如何設(shè)計(jì)？按照通常思維，這是一個(gè)次序問題，先在內(nèi)
存中計(jì)算數(shù)據(jù)，然后將結(jié)果發(fā)送到他的信箱，最后返回結(jié)果到用戶端，我們知道信件的發(fā)送是耗時(shí)的，因此，有可能網(wǎng)絡(luò)的原因造成信件發(fā)送很慢，這是用戶就一直
等不到他的計(jì)算結(jié)果，很顯然，我們使用監(jiān)控式事件模式來解決，讓發(fā)信的事件由監(jiān)控者去完成，只要需要時(shí)觸發(fā)就可以了：
|
public class Computer extends Observable{
public Computer(){
//將sendMailObserver設(shè)定為本類的觀察者。
addObserver(new sendMailObserver());
}
.......
public void compute(String input,boolean needEmail,String email){
//計(jì)算操作
.........
if (needEmail){
//設(shè)置變化點(diǎn)
setChanged();
//如果需要發(fā)送email，我們把email地址作為參數(shù)傳送過去
notifyObservers(email);
}
}
｝
|
我們?cè)賮砜幢O(jiān)控觀察者代碼是如何寫的？
|
public class sendMailObserver implements Observer{
public void update(Observable obj,Object email){
if (email instanceof String){
sendMail(email);
}
}
}
|
這樣服務(wù)器在執(zhí)行compute方法時(shí)，就沒有發(fā)送郵件的等待，一直接繼續(xù)執(zhí)行。
監(jiān)控式事件模式和事件直接驅(qū)動(dòng)模式可以在一個(gè)系統(tǒng)一起使用，外界信號(hào)通過事件直接驅(qū)動(dòng)模式啟動(dòng)系統(tǒng)處理模塊， 系統(tǒng)處理模塊處理過程中，可以通過監(jiān)控式事件模式來觸發(fā)其它后臺(tái)任務(wù)。這樣一個(gè)架構(gòu)非常適合實(shí)時(shí)處理系統(tǒng)。
既然事件處理模式是眾多應(yīng)用系統(tǒng)的基本模式，那么應(yīng)該可以形成一個(gè)框架標(biāo)準(zhǔn)，JMX的notification Model就是這樣一個(gè)架構(gòu)設(shè)計(jì)。
JMX Notification Model
我們知道，JMX是提供了一種對(duì)MBean資源執(zhí)行控制和配
置的管理機(jī)制，但這只是復(fù)雜的，分布式的系統(tǒng)中的一部分， 還有需要資源能夠感應(yīng)狀態(tài)改變或者特定事件變化的機(jī)制，這就是JMX
Notification Model。 在JMX Notification
Model中均可以實(shí)現(xiàn)"事件直接驅(qū)動(dòng)模式"和"監(jiān)控式事件模式"，這取決于你的應(yīng)用需求。
JMX Notification
Model允許MBean通過調(diào)用notifications廣播事件，接受者只要注冊(cè)為一個(gè)listerner， JMX的 MBean
notification model 將會(huì)激活這個(gè)listerner注冊(cè)一次，然后將一直接受到 來自廣播者發(fā)出的各種事件。
事件模式有三個(gè)角色，第一個(gè)是事件發(fā)出者producer 然后是事件接受者Consumer,第三個(gè) 是要傳輸?shù)氖录MX notification model也是這樣分別依靠下列組件來實(shí)現(xiàn)這三個(gè)角色：
A. NotificationBroadcaster接口, 事件廣播發(fā)出者， 這個(gè)接口允許監(jiān)聽者在需要發(fā)出的notification中注冊(cè)他們感興趣的事件。
B. 通用事件(Notification)，這是我們要傳輸?shù)氖录?Notification事件能被直接使用，也能成為子類，這些都依賴于隨同事件傳輸?shù)男畔ⅰ?通過使用通用事件類型，監(jiān)聽者將能接受來自廣播者所有類型的事件。
C. NotificationListener接口, 事件監(jiān)聽者或者接受者， 用于接受來自廣播者的任何notification信號(hào)。
D. NotificationFilter接口, 這個(gè)接口為notification的監(jiān)聽者提供一個(gè)對(duì)發(fā)出事件的過濾器。
E. NotificationEmitter 接口, 擴(kuò)展了NotificationBroadcaster接口，當(dāng)刪除監(jiān)聽者時(shí)允許更多的控制功能。
只要是MBean，就既可以成為notification的發(fā)布廣播者，也可以成為notification的監(jiān)聽者接受者，或者同時(shí)兩者都可以。
Attribute Change Notifications
Attribute Change Notifications是一種特殊的notification, 任何時(shí)候MBean屬性attribute 被修改，外界能夠被通知到。
在JMX架構(gòu)中，MBean能夠在屬性attribute變化發(fā)生時(shí)，發(fā)出通知，關(guān)于診斷屬性變化的機(jī)制以及觸發(fā) 通知事件并不屬于JMX規(guī)定部分，每個(gè)MBean可以有自己獨(dú)立的實(shí)現(xiàn)方式。
Timer Service
Timer Service觸發(fā)器是在規(guī)定的日期和事件發(fā)出通知，它能夠一一個(gè)恒定的間隙不斷重復(fù)發(fā)出通知， 通知可以發(fā)往所有注冊(cè)為接受timer通知的對(duì)象，Timer Service也是一個(gè)可管理的MBean，允許應(yīng)用系統(tǒng)設(shè)置 一個(gè)可配置的調(diào)度程度。
Monitoring
通過使用monitoring
service，一個(gè)或多個(gè)MBean屬性將按規(guī)定間隔時(shí)間被監(jiān)視，
對(duì)于被觀察的Mbean,監(jiān)視器monitor將從它上面獲得一個(gè)值，叫derived gauge，這個(gè)derived gauge可以是
被觀察屬性的原值，也可以是一個(gè)數(shù)字性屬性連續(xù)被觀察值之差。
當(dāng)derived gauge值滿足一系列條件時(shí)，每個(gè)monitor server將會(huì)發(fā)出一個(gè)特定類型的通知。 這些條件都是在monitor被初始化時(shí)設(shè)定的，也可以通過monitor MBean的管理接口動(dòng)態(tài)設(shè)定。
根據(jù)MBean內(nèi)部屬性值類型有三種monitor:
A.CounterMonitor - 使用Java的整數(shù)類型來觀察屬性，有一個(gè)行為特征：
a. 總是大于或等于零.
b. 能自增.
c. 能回滾.
B.GaugeMonitor - 使用java的整數(shù)或浮點(diǎn)類型觀察屬性。象gauge(測(cè)量?jī)x器) 要么上升 要么下降減少。
C StringMonitor - 使用String類型觀察屬性.
事件處理架構(gòu)
JMS是基于Socket的一種消息處理框架，原理類似于監(jiān)控式事件模式，但是JMS已經(jīng)把這種模式上升到架構(gòu)的高度。不同JVM間也依靠JMS消息可以實(shí)現(xiàn)事件系統(tǒng)（注意是系統(tǒng)，不簡(jiǎn)單是一個(gè)小事件了）的觸發(fā)和激活。
從上面JMS的架構(gòu)圖可以看出事件三個(gè)角色Producer和Consumer以及事件信息本身Message．JMS就是在Producer和Consumer之間建立一個(gè)連接Connection．
JMS可實(shí)現(xiàn)同步或異步的事件觸發(fā)機(jī)制，分別是通過Poin to
Point(拉方式)和Pubilsh/Subscibe(推方式)具體完成，在分布式計(jì)算環(huán)境中，異步機(jī)制是非常重要，可以起到解耦作用，因?yàn)榉植辑h(huán)境
中單點(diǎn)錯(cuò)誤或通訊問題是經(jīng)常發(fā)生的，整個(gè)分布式系統(tǒng)不能總是依靠同步機(jī)制來可靠地傳遞事件或notification．
由此可見，事件處理模式從Java諸多架構(gòu)到我們具體應(yīng)用程序，隨處可見，根據(jù)不同的應(yīng)用需求選擇不同的事件處理模式，才能真正挖掘Java的潛在性能。