Mina通信初步
1、Mina通信框架简介
Mina整体框架：
2、Mina通信流程
3、Mina特性
MINA是一个简单的却有功能丰富的网络应用程序框架， 它提供如下特性：
为各种传输类型提供一套统一的API
通过Java NIO实现 TCP/IP & UPD/IP通信
通过RXTX实现串口通信（RS232）
VM内部管道通信
你可以实现自己的通信方式
通过Filter接口实现扩展点；类似与Servlet的Filter
低级和高级的API
低级：使用ByteBuffer
高级：用户自定义的消息对象和编码
可以自由定制的线程模型
单线程
一个线程池
多个线程池（例如 SEDA）
利用Java5的SSLEngine实现的开箱即用的SSL,TLS, StartTLS功能
过载保护 和 带宽限制
通过Mock对象可以进行单体测试
通过JMX管理服务器
通过StreamIoHandler支持基于流的I/O
可以整合进PicoContainer和Spring等常用容器
很容易从Netty迁移过来。
4、常见通信框架对比
以MINA、Cindy、QuickServer为例。
从功能上看，Mina、Cindy、QuickServer实现的功能也基本差不多，都是封装基本的网络IO操作，暴露事件接口供二次开发。
Mina需要继承IOHandlerAdapter类或ProtocolHandlerAdapter类，从该类中继承各事件方法实现业务操作。 Cindy也需要继承SessionHandlerAdapter具体类，跟Mina类似。QuickServer则需要实现接口 ClientEventHandler实现业务功能。这些类和接口提供的事件大致雷同：Connected，Closed，Received，Sent， Timeout等等。
Mina和Cindy使用了nio，而QuickServer则同时支持blockingIO和nio，需要进行配置选择（一个遗憾就 是QuickServer的nio模式下竟然不支持Timeout事件）。Mina实现中有一个很好的设计就是剥离IO层和Protocol层，作者的用 意是想在IO层实现对IO的处理，在Protocol实现对业务的处理，很好的一个分层思想。QuickServer则是一个大杂烩，把各种IO处理封装 在 BasicClientHandler中，里面还混杂了blockingIO、NIO等操作。
额外功能上，Mina和Cindy都可以 支持一个进程中开启多个服务端口进行不同处理，而QuickServer则不行。不过QuickServer提供了另外一个非常实用的功能-管理服务端 口，通过其设定的一些指令查询服务器的状态、控制服务器等。此功能成为最后选择的最大优势。其他例如IP过滤的功能在QuickServer中只需要进行 配置即可。
这次没对这三个服务器在性能上进行比较。以后再找机会完成:-)
从代码质量上来看，无疑Mina和Cindy占了 上风，QuickServer的分层实在不咋样。Mina和Cindy有不少相似的地方。而QuickServer的目的与其有所不同，集成许多方便的功 能，甚至还加入数据库连接池的功能（感觉作者有点无聊了）。最后的循证其实还是选了个最实用的工具，的确减少不少的工作量。此后还遇到一些二进制的问题就 不表了。
MINA is a good framwork
作者：fisher
Netty2的作者TrustinLee在为Apache LDAP项目所作的通讯基础框架MINA中显示了在通讯框架方面雄厚的实力，MINA是迄今为止我见过在java领域最好的通讯基础件，看得出，他通过Netty2的经验积累加上对ACE等传统大型框架的理解之后，在制作MINA的一开始就确定了一个近似于完美的架构，同时，我在RoadMap中看到MINA与Spring、JMX和OSGI的结合计划，虽然不知道什么时候能够完成，但光看这个RoadMap已经很让人激动了。
在MINA的服务绑定上，一开始就使用了serviceRegistry类这种中控型的注册绑定方式，看得出他对OSGI有一定研究并已决意向其靠拢。
而借鉴于ACE的Accepter和Connector结构使得Session的使用更加方便，同时分为IO层和Protocol两层的通讯基础件也是使得使用变得很方便。
最后要提一下的是作者使用的FilterChain式结构来加载Filter，使得很多非通讯核心问题得以从基础件中剥离出来，甚至连线程池模式都可以使用Filter来指定，虽然自己制作的线程池要想结合到MINA中需要一些额外的努力，但是仍然极大的增加了框架的灵活性。
MINA vs. QuickServer
作者：fisher
First for all, QuickServer is licensed as LGPL, and MINA as ASL.
从我个人角度而言，去年看过QuickServer的源码，我在项目中采用的每一个框架或类库都会做综合评价，通常不会是一个原因导致我采用或没有采用某个库或框架，具体最后没有采用QuickServer的原因忘记了，但是当时给我的总体感觉是，QuickServer虽然很方便，但不会让我在架构上得到新的好处。而它最大的优点则是，支持JDK1.3（如果没记错的话），另外就是License的问题
下面看一看来自TrusinLee的评论：
Thank for the information about another network application framework. I found a few differences:
Ø QuickServer supports blocking mode. (MINA supports only non-blocking mode, but you can make your operation block at your will.)
Ø QuickServer provides GUI-based admin. (MINA doesn't have one yet, but will have full JMX support soon, which is a standard.)
Ø QuickServer uses java.util.logging. (MINA uses SLF4J, which is a safe replacement of commons-logging.)
Ø QuickServer uses its own XML settings. (MINA provides Spring framework integration instead.)
Ø QuickServer can specify maximum number of clients allowed. (MINA can do this using a filter, but not implemented by default. Of course, this will be implemented as an overload prevention filter.)
Ø QuickServer team has one crew. (MINA has three crews.)
Ø QuickServer project started in 2003. (MINA started in 2005.)
Ø QuickServer has a difference event handler interface from MINA. (You'll have to compare it by yourself. IMHO, MINA has one simple enough handler which covers all QuickServer provides.)
Ø QuickServer doesn't support UDP at all. (MINA does)
Ø QuickServer doesn't support client-side API at all. (MINA does)
Ø QuickServer integrated authentication and text protocol in its core. (MINA didn't and they are considered as a cross-cutting concern that a filter should take care of. IMHO, MINA is more extensible here.)
Cindy2.x比MINA性能好是可以预见的，原因在于MINA提供的ByteBuffer和FilterChain。
Cindy3.x源代码我没有看，所以不好评价。
关于MINA的效率问题，在MINA的maillist中也被提出，似乎有相应的issue正要被加入到它的Issue Tracker中。
Cindy3.x才刚刚开始，我认为多给Crmky一些时间，他一定可以将架构设计的更好。
MINA在设计上也有少许问题，他的IoFilterChain将FilterManager和FilterChain合而为一，在看其代码的时候会觉得很乱。另外，为了保证包的顺序，一个IoSession上的Handler在上一次read调用没有返回前，是不会被再次调用的。我认为MINA的基础架构在1.0和1.1版本之间还会变化，以适应新加入的configuration方式。另外，MINA会产生一些内存垃圾，我用profiler检查过MINA，似乎是SocketIoProcessor中的某个计数器在不停的产生2byte的什么东东（记不太情了），不过似乎Trustin也注意到这个问题了，最近他说会在1.0release之后改善效率和内存的问题。
Mina整体框架：
2、Mina通信流程
3、Mina特性
MINA是一个简单的却有功能丰富的网络应用程序框架， 它提供如下特性：
为各种传输类型提供一套统一的API
通过Java NIO实现 TCP/IP & UPD/IP通信
通过RXTX实现串口通信（RS232）
VM内部管道通信
你可以实现自己的通信方式
通过Filter接口实现扩展点；类似与Servlet的Filter
低级和高级的API
低级：使用ByteBuffer
高级：用户自定义的消息对象和编码
可以自由定制的线程模型
单线程
一个线程池
多个线程池（例如 SEDA）
利用Java5的SSLEngine实现的开箱即用的SSL,TLS, StartTLS功能
过载保护 和 带宽限制
通过Mock对象可以进行单体测试
通过JMX管理服务器
通过StreamIoHandler支持基于流的I/O
可以整合进PicoContainer和Spring等常用容器
很容易从Netty迁移过来。
4、常见通信框架对比
以MINA、Cindy、QuickServer为例。
从功能上看，Mina、Cindy、QuickServer实现的功能也基本差不多，都是封装基本的网络IO操作，暴露事件接口供二次开发。
Mina需要继承IOHandlerAdapter类或ProtocolHandlerAdapter类，从该类中继承各事件方法实现业务操作。 Cindy也需要继承SessionHandlerAdapter具体类，跟Mina类似。QuickServer则需要实现接口 ClientEventHandler实现业务功能。这些类和接口提供的事件大致雷同：Connected，Closed，Received，Sent， Timeout等等。
Mina和Cindy使用了nio，而QuickServer则同时支持blockingIO和nio，需要进行配置选择（一个遗憾就 是QuickServer的nio模式下竟然不支持Timeout事件）。Mina实现中有一个很好的设计就是剥离IO层和Protocol层，作者的用 意是想在IO层实现对IO的处理，在Protocol实现对业务的处理，很好的一个分层思想。QuickServer则是一个大杂烩，把各种IO处理封装 在 BasicClientHandler中，里面还混杂了blockingIO、NIO等操作。
额外功能上，Mina和Cindy都可以 支持一个进程中开启多个服务端口进行不同处理，而QuickServer则不行。不过QuickServer提供了另外一个非常实用的功能-管理服务端 口，通过其设定的一些指令查询服务器的状态、控制服务器等。此功能成为最后选择的最大优势。其他例如IP过滤的功能在QuickServer中只需要进行 配置即可。
这次没对这三个服务器在性能上进行比较。以后再找机会完成:-)
从代码质量上来看，无疑Mina和Cindy占了 上风，QuickServer的分层实在不咋样。Mina和Cindy有不少相似的地方。而QuickServer的目的与其有所不同，集成许多方便的功 能，甚至还加入数据库连接池的功能（感觉作者有点无聊了）。最后的循证其实还是选了个最实用的工具，的确减少不少的工作量。此后还遇到一些二进制的问题就 不表了。
MINA is a good framwork
作者：fisher
Netty2的作者TrustinLee在为Apache LDAP项目所作的通讯基础框架MINA中显示了在通讯框架方面雄厚的实力，MINA是迄今为止我见过在java领域最好的通讯基础件，看得出，他通过Netty2的经验积累加上对ACE等传统大型框架的理解之后，在制作MINA的一开始就确定了一个近似于完美的架构，同时，我在RoadMap中看到MINA与Spring、JMX和OSGI的结合计划，虽然不知道什么时候能够完成，但光看这个RoadMap已经很让人激动了。
在MINA的服务绑定上，一开始就使用了serviceRegistry类这种中控型的注册绑定方式，看得出他对OSGI有一定研究并已决意向其靠拢。
而借鉴于ACE的Accepter和Connector结构使得Session的使用更加方便，同时分为IO层和Protocol两层的通讯基础件也是使得使用变得很方便。
最后要提一下的是作者使用的FilterChain式结构来加载Filter，使得很多非通讯核心问题得以从基础件中剥离出来，甚至连线程池模式都可以使用Filter来指定，虽然自己制作的线程池要想结合到MINA中需要一些额外的努力，但是仍然极大的增加了框架的灵活性。
MINA vs. QuickServer
作者：fisher
First for all, QuickServer is licensed as LGPL, and MINA as ASL.
从我个人角度而言，去年看过QuickServer的源码，我在项目中采用的每一个框架或类库都会做综合评价，通常不会是一个原因导致我采用或没有采用某个库或框架，具体最后没有采用QuickServer的原因忘记了，但是当时给我的总体感觉是，QuickServer虽然很方便，但不会让我在架构上得到新的好处。而它最大的优点则是，支持JDK1.3（如果没记错的话），另外就是License的问题
下面看一看来自TrusinLee的评论：
Thank for the information about another network application framework. I found a few differences:
Ø QuickServer supports blocking mode. (MINA supports only non-blocking mode, but you can make your operation block at your will.)
Ø QuickServer provides GUI-based admin. (MINA doesn't have one yet, but will have full JMX support soon, which is a standard.)
Ø QuickServer uses java.util.logging. (MINA uses SLF4J, which is a safe replacement of commons-logging.)
Ø QuickServer uses its own XML settings. (MINA provides Spring framework integration instead.)
Ø QuickServer can specify maximum number of clients allowed. (MINA can do this using a filter, but not implemented by default. Of course, this will be implemented as an overload prevention filter.)
Ø QuickServer team has one crew. (MINA has three crews.)
Ø QuickServer project started in 2003. (MINA started in 2005.)
Ø QuickServer has a difference event handler interface from MINA. (You'll have to compare it by yourself. IMHO, MINA has one simple enough handler which covers all QuickServer provides.)
Ø QuickServer doesn't support UDP at all. (MINA does)
Ø QuickServer doesn't support client-side API at all. (MINA does)
Ø QuickServer integrated authentication and text protocol in its core. (MINA didn't and they are considered as a cross-cutting concern that a filter should take care of. IMHO, MINA is more extensible here.)
Cindy2.x比MINA性能好是可以预见的，原因在于MINA提供的ByteBuffer和FilterChain。
Cindy3.x源代码我没有看，所以不好评价。
关于MINA的效率问题，在MINA的maillist中也被提出，似乎有相应的issue正要被加入到它的Issue Tracker中。
Cindy3.x才刚刚开始，我认为多给Crmky一些时间，他一定可以将架构设计的更好。
MINA在设计上也有少许问题，他的IoFilterChain将FilterManager和FilterChain合而为一，在看其代码的时候会觉得很乱。另外，为了保证包的顺序，一个IoSession上的Handler在上一次read调用没有返回前，是不会被再次调用的。我认为MINA的基础架构在1.0和1.1版本之间还会变化，以适应新加入的configuration方式。另外，MINA会产生一些内存垃圾，我用profiler检查过MINA，似乎是SocketIoProcessor中的某个计数器在不停的产生2byte的什么东东（记不太情了），不过似乎Trustin也注意到这个问题了，最近他说会在1.0release之后改善效率和内存的问题。