MINA 的基礎(chǔ)架構(gòu)

下圖是 MINA 的架構(gòu)圖，

在 圖中的模塊鏈中，IoService 便是應(yīng)用程序的入口，相當(dāng)于我們前面代碼中的 IoAcceptor，IoAcceptor 便是 IoService 的一個(gè)擴(kuò)展接口。IoService 接口可以用來添加多個(gè) IoFilter，這些 IoFilter 符合責(zé)任鏈模式并由 IoProcessor 線程負(fù)責(zé)調(diào)用。而 IoAcceptor在 ioService 接口的基礎(chǔ)上還提供綁定某個(gè)通訊端口以及取消綁定的接口。在上面的例子中，我們是這樣使用 IoAcceptor的：

IoAcceptor acceptor = new SocketAcceptor();

相當(dāng)于我們使用了 Socket 通訊方式作為服務(wù)的接入，當(dāng)前版本的 MINA 還提供了除 SocketAccepter 外的基于數(shù)據(jù)報(bào)文通訊的 DatagramAccepter 以及基于管道通訊的 VmPipeAccepter。另外還包括串口通訊接入方式，目前基于串口通訊的接入方式已經(jīng)在最新測(cè)試版的 MINA 中提供。你也可以自行實(shí)現(xiàn) IoService 接口來使用自己的通訊方式。

而在上圖中最右端也就是 IoHandler，這便是業(yè)務(wù)處理模塊。相當(dāng)于前面例子中的 HelloHandler 類。在業(yè)務(wù)處理類中不需要去關(guān)心實(shí)際的通訊細(xì)節(jié)，只管處理客戶端傳輸過來的信息即可。編寫 Handler 類就是使用 MINA 開發(fā)網(wǎng)絡(luò)應(yīng)用程序的重心所在，相當(dāng)于 MINA 已經(jīng)幫你處理了所有的通訊方面的細(xì)節(jié)問題。為了簡(jiǎn)化 Handler 類，MINA 提供了 IoHandlerAdapter 類，此類僅僅是實(shí)現(xiàn)了 IoHandler 接口，但并不做任何處理。

一個(gè) IoHandler 接口中具有如下一些方法（摘自 MINA 的 API 文檔）：

前面我們提到 IoService 是負(fù)責(zé)底層通訊接入，而 IoHandler 是負(fù)責(zé)業(yè)務(wù)處理的。那么 MINA 架構(gòu)圖中的 IoFilter 作何用途呢？答案是你想作何用途都可以。但是有一個(gè)用途卻是必須的，那就是作為 IoService 和 IoHandler 之間的橋梁。IoHandler 接口中最重要的一個(gè)方法是 messageReceived，這個(gè)方法的第二個(gè)參數(shù)是一個(gè) Object 型的消息，總所周知，Object 是所有 Java 對(duì)象的基礎(chǔ)，那到底誰來決定這個(gè)消息到底是什么類型呢？答案也就在這個(gè) IoFilter 中。在前面使用的例子中，我們添加了一個(gè) IoFilter 是 new ProtocolCodecFilter(new TextLineCodecFactory())，這個(gè)過濾器的作用是將來自客戶端輸入的信息轉(zhuǎn)換成一行行的文本后傳遞給 IoHandler，因此我們可以在 messageReceived 中直接將 msg 對(duì)象強(qiáng)制轉(zhuǎn)換成 String 對(duì)象。

而 如果我們不提供任何過濾器的話，那么在 messageReceived 方法中的第二個(gè)參數(shù)類型就是一個(gè) byte 的緩沖區(qū)，對(duì)應(yīng)的類是 org.apache.mina.common.ByteBuffer。雖然你也可以將解析客戶端信息放在 IoHandler 中來做，但這并不是推薦的做法，使原來清晰的模型又模糊起來，變得 IoHandler 不只是業(yè)務(wù)處理，還得充當(dāng)協(xié)議解析的任務(wù)。

MINA自身帶有一些常用的過濾器，例如LoggingFilter（日志記錄）、BlackListFilter（黑名單過濾）、CompressionFilter（壓縮）、SSLFilter（SSL加密）等。