大家都知道，MVC架构模式是经典通用的，具体应用中采用这种模式是简单清晰的，分层为控制层、业务层、表现层。SOA架构，面向服务的架构。比如具体应用实现方式有比如ssh（spring,struts,hibernate）。apache mina架构也可以分层为服务层(IoService,Ioacceptor)、过滤器、处理器、业务处理层。但是看到mina发布服务的方式，一个acceptor绑定一个ip和端口，再绑定一个业务处理器handler，然后这个业务处理功能作为一个服务发布给客户端调用。那么具体的应用，往往包含很多业务模块，让这个服务器统一处理。如果按照mina这个模式，是不是要一个业务处理模块发布一套handler，acceptor，绑定一个ip和端口。会很复杂。请教一下，mina能否实现一个统一的服务接口方式，如服务器绑定一个ip和端口，采用一个acceptor，绑定多个业务处理模块的handler，给客户端按业务模块提供不同的接口url（最好restful风格的webservice），然后客户端访问这个ip和端口，根据不同的请求url就可以访问，得到到不同的业务模块的功能处理并响应了。
建议的架构组件mina+restlet，大家探讨一下能否实现呢？
建议的架构组件mina+restlet，大家探讨一下能否实现呢？
同时建议楼主再深入点理解一下HTTP报文中url的作用，然后结合报文中交易码，分析一下；
最后建议楼主不要狭义的理解handler，handler只是个Java类，编成什么样子，就有什么样的功能，它可以作为接入、可以作为控制，也可以简单的实现为业务处理的交易类
DemuxingIoHandler类实现多处理器的，能否给出例子代码看看，伪码也行。
比如我想让一个服务器提供的io服务是：上传文件（upFile），下载文件(downFile)。那么是不是需要建立的处理类UpFileIoHandler,DownFileIoHandler，将这2个handler绑定到这个服务器上，客户端就可以访问相应的服务对应的处理了。
DemuxingIoHandler是根据上送的消息类型，进行转发的，换句话说不同的消息会转发至不同的处理类（注：MessageHandler的实现类，而不是IoHandler的实现类）。但说句实话，建议仔细理解最后那句话。
我认为mina主要实现的是nio，那么在业务应用中如果有nio的业务，我们把它包装成一种服务，处理不同的业务类型(或者说消息类型)，比如：业务类型为上传文件（upFile），下载文件(downFile)。对应的的处理类为UpFileIoHandler,DownFileIoHandler，那么我们采用DemuxingIoHandler类提供的功能转发处理相应的业务类型。
具体实现不知道有没有可以参考的范例？
探索中
用例场景：聊天，客户端与服务端交互的一种聊天对话
实现框架业务组件包括(从服务端到客户端的顺序,用类名表示)：
应用基础组件：restlet组件（Component，Application)
资源层组件：restlet的Resource(ChatDatasNioResource)
服务组件：service(ChatDataServiceNio)
Nio处理组件：过滤器(ChatDataFilter)、服务端Nio处理(SendChatDataServerIoHandler)，客户端Nio处理(SendChatDataClientIoHandler)
持久化组件：dao(ChatDataNio)
实体组件：持久化实体entity(ChatDataEntity),表示层实体model(ChatDataVo)
客户端组件：传统客户端(awt实现界面)，web页面（jsp+servlet）
以上处理，在业务调用时是逐层调用的MVC模式。但目前不足的是实现的服务端Nio处理(SendChatDataServerIoHandler)，是采用一个业务模块服务启动一个ip和端口，如果再增加业务模块就需要再增加启动另一个ip和端口，不知能否采用楼上仁兄说的DemuxingIoHandler，实现统一一个ip和端口，来处理不同的业务模块，如果这样就更完善了，大家给点建议，评价一下吧。
比如http的请求头通常为:
GET /path/index.jsp?name=hello HTTP/1.1
xxx
这种格式
在mina中,你可以定义自己的filter来解析这种协议,然后handler再根据协议的具体内容进行转发,最后到达具体的业务处理handler