JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Software Design  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to postflat modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 POSA2: Reactor [精華]
popcorny

Jakarta 2%

版主

發文: 752
積分: 20
於 2003-09-30 16:31 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Introduction
Reactor是一個Architectural pattern。目的是讓一個event-driven的應用程式,能夠把產生的事件解多工(demultiplex)並且分派(dispatch)到對應的service做處理。

As Known as
Dispatcher, Notifier

Context
此pattern是應用在event-driven的應用程式。在其中,應用程式可能同時間接收到不同client的service requests,但是卻要同步地(synchronously)且循序地(serially)處理他們。
(註: 這裡的synchorously及serially是相對於asynchronously,也就是同步的呼叫。在同步的呼叫中,caller一定要等callee完成處理後,才能繼續下一個動作,因此才又會是serially。反觀asynchronously process,caller不必要等待callee完成處理就可以做下一個動作)

Problem
Event-driven的應用程式(尤其是server程式)必須要能夠同時處理很多client所產生的service request。而所有的event可以用indication event(如CONNECT及READ)來做區別。但是在處理這些event之前,event-driven的應用程式必須要先把這些indication
event做解多工(demultiplex)跟分派(dispatch)到對應的service。要解決這個問題,我們必須要有以下四個必須考量到的問題
1. 應用程式不應該block在某一個indication event而導致無法處理其他的event,這會導致效能大大的下降。
2. 為了能夠有較好的throughput,任何不必要的context switching, synchronization, data movement都應該要避免。
3. 若未來要整合新的service或是改善暨有的service,所需要花的功夫應該越少越好。
4. 撰寫Service的程式碼中,應該完全不會理會到底層複雜的multi-threading或是synchronization部分的機制。

Solution
用Synchronous的方式去等待來自不同的event source(如connected socket handles)的indication event,並且整合了demultiplex跟dispatch的機制在其中。除此之外,我們把有關demultiplex跟dispatch的機制以及application-specific處理event的邏輯分離。

更詳細的說,我們把處理某個indication event的邏輯看成是一個service,而此service必須實作成一個"event handler",並且註冊在一個稱為"reactor"的元件當中。"reactor"透過"synchronous event demultiplexer"來等待某個indication event的發生。當indication event產生時,則回傳給reactor,並且找到對應的"event handler"用同步的方式dispatch給它做對應的處理。

Static


Participants and Responsibilities
Handle and Handle Set
-Handle代表的是一個event source。
-Handle Set代表的是一組handles。

Synchronous Event Demultiplexer
-提供block waiting,直到在handle set中有任何event的發生
-指示說某個operation可以被呼叫而且不會有任何的blocking

Event Handler
-定義一個處理indication event的共有介面

Concrete Event Handler
-Event Handler的實作,根據程式的邏輯來處理event。

Reactor
-可以register或remove一個event handler
-管理handle set
-執行application的event loop。

Dynamics


1. 首先Main Program先向Reactor註冊Event Handler
2. 而Reactor會呼叫Synchronous Event Demultiplexer的select此blocking method。
3. 當一個或多個event source有任何indication event產生時,select會回傳。
4. 針對產生的event分派給對應的的event handler。

Consequences
此pattern在很多的場合都會看到蹤跡,最常見的就是non-blocking io的select此method,有寫過berkeley socket的人應該很有感覺。但是更不一樣的是此pattern把處理某個event的邏輯抽離出來,委託給應用程式去實作,這是一種"inversion of control"的一種實現。

在java中,J2SE 1.4開始也有了select此method的支援,
分別是用到
java.nio.channles.Selector
java.nio.channels.SelectableSocket
java.nio.channels.SelectionKey
有關實作此pattern的細節可以參考Doug Lea的投影片
http://www.javaworld.com.tw/jute/post/view?bid=12&id=12075&sty=1&tpg=1&age=0

至於此pattern最大的兩個優點我認為是
Coarse-grained concurrency control:
此pattern用一個thread(或process)去處理很多個concurrency,這會大大的減少thread的產生,以及避免複雜的synchronization。

Separartion of concerns:
此pattern把底層demultiplex跟dispatch的機制,跟application-specific service implemenation完全的抽離。如此可以減少application本身的複雜度,同時也增加了整個架構的重複使用性。

但是也有一些缺點
Non-pre-emptive:
若某個handler把thread佔去去做一個很花時間的動作,那整個系統的效能將會被拖垮。此問題可以把task委託給其他thread處理而獲得解決。

Complexity of debugging and testing:
這個問題主要來自reactor pattern是使用"inversion of control",所以的event handler都是透過callback的方式被喚起,所以無法從頭到尾追蹤錯誤的來源。除此之外,若兩個event之間有State的關係,此種程式會更難撰寫。


popcorny edited on 2003-09-30 16:35
reply to postreply to post
話題樹型展開
人氣 標題 作者 字數 發文時間
6479 [精華] POSA2: Reactor popcorny 3552 2003-09-30 16:31
4708 Re:POSA2: Reactor popcorny 0 2003-09-30 16:32
5105 Re:POSA2: Reactor popcorny 8 2003-09-30 16:32
» JWorld@TW »  Software Design

reply to postflat modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8