Service
fireServiceEvent()
WhiteBoardService whiteBoardWindow
processRequest() processResponse()
WhiteBoardWindow
connect() disconnect()
has
board
receiveHandler[]
Canvas graphics
addOutputStream() paint()
ReceiveHandler run()
功能描述如下：
WhiteBoardService：
主要是負責電子白板建立及關閉的協定處理。
WhiteBoardWindow：
負責使用者視窗界面，產生管理ReceiveHandler，產生 管理資料管線及視窗事件聆聽。
ReceiveHandler：
開啟繪圖資料聆聽埠，加以聆聽，並剖析資料使成有意 義的繪圖資訊。
Canvas：
此類別與java.awt.Canvas並無相關，負責聆聽滑鼠事件及繪 圖。
4.7.2 建立，運作及關閉
(1) 建立
首先由某同一視訊會議參與者啟動電子白板，該參與者 的WhiteBoardService將對其它參與者建立輸入管線並 送出CREATE Request，如下圖。
圖 4.7.2.1 建立電子白板
CREATE Request CREATE Request
CREATE Request
A B
C D
視訊會議
其它參與者收到CREATE Request後，利用請求內的參數建立 與參與者A的輸出管線，建立與A的輸入管線並將管線參數加入回 應OK內，然後開始向除了A以外的參與者發出INVITE Request，
如下圖。
圖 4.7.2.2 建立電子白板
上圖只畫出某一參與者的情況，其它參與者(B、D)雷同，在 送出INVITE Request前，先對該INVITE Request的接受者建立輸 入管線，同樣的，將管線參數加入請求中，由於每位參與者皆如此 做，最後網狀的管線分佈圖將被建立起來，如下圖。
圖 4.7.2.3 電子白板網狀管線分佈圖 INVITE INVITE
OK 0x04
A B
C D
視訊會議
A B
C D
視訊會議
使用網狀分佈的好處是資料的傳送速率較集中管理再行轉傳 drawLine()
mouseDragged()
:Canvas :Graphics2D
:OutputStream
使用者拖曳每一像素都會將上面的流程會執行一次，也就是說 在正常的使用下，可能一秒內就執行七八十次，這也是整個電子白 板系統中，較為困難的部份，如何避免上一次流程尚未完成就進行 下一次流程而造成資料封包的重疊，因此，必須淢少以上流程的時 間，不能使用昂貴的運作，所以電子白板使用陣列儲存資料輸出串 流，能預先載入的動作及資料即預先載入，使用bit shift運算代替 乘法等，否則即使有Java語言的同步化保護，也會造成延遲導至使 用上的不順暢。
圖 4.7.2.5 遠端繪圖 (3) 關閉
電子白板的關閉由視訊會議中的某一參與者發啟，送出BYE Request至每一參與者，當電子白板系統收到BYE Request即關閉 視窗界面及資料串流，然後回應BYE Response，以下是遠端關閉 的UML順序圖。
notify() drawLine()
processRequest()
onRemoteClose()
sendReponse() close()
:Canvas :ReceiveHandler :InputStream
:WhiteBoardService :WhiteBoardWindow :InputPipe
4.7.3 討論
電子白板未來可能改進之處有：
(1) 不依賴視訊會議系統，任兩使用者可隨時建立電子白板會 議。
(2) 任一參與者關閉電子白板，其參與者的電子白板也不需一 併關閉，改為其它方式告知某參與者己關閉電子白板，最後剩 一位參與者使用電子白板時才被迫關閉。
(3)在電子白板開啟後，新加入的參與者無法參與電子白板會 議。