In addition, there is a need to look for something that could help me, the author, to write down an application which implements many commands, preferably in a appealing way, where each piece of service could be isolated from the rest of the application.
The demultiplexer is a device with a single input and many outputs. Its role is to select the output line according to context rules. This approach is also implemented within Apache Mina for writing decoders, handlers and encoders. Apache Mina’s demux package includes: DemuxingIoHandler, DemuxingProtocolDecoder and the DemuxingProtocolEncoder.
Filters are used for several purposes: I/O logging, performance
tracking, thread pooling, overload control, blacklists, and so on. In a
specific case I once had to configure two filters. One for the user
authentication, and the other for thread pooling. Once a user is logged
in, the authentication filter removes itself from the client session
filter list, while substituting one transforming the raw input into
The TCP server must implements a proprietary protocol. It is a simple
ASCII protocol for exchanging commands. Such command lengths are
undefinable. They, however, are a sequence of characters much like
SMTP. Therefore, the CumulativeProtocolDecoder class
is extended enabling it to gather input through the end of command. It
is then left to us to parse of the bytes and create a simple Java Bean.
Post the operation, the bean is transferred through the filter chain to
One of the IoHandler
implementations drew my attention while I was looking for something
resembling the Command Pattern. Each message coming from clients means a
specific action, and I find it so tedious writing a single Handler that
switches operations by the type of the incoming request. An elegant
solution is provided by DemuxingIoHandler that posts the requests toward
the corresponding handler. The handlers have to implement the MessageHandler<E>,
the generic type defined will be the object’s class that the
DemuxingIoHandler will submit to the handler, and register themselves
invoking addReceivedMessageHandler(Class<E> type, MessageHandler<? super E> handler).
The asynchronous nature of Mina allows to handle a huge number of
clients by an handful set of threads. A further decoupling between I/O
and business logic may be done by the ExecutorFilter, which is in charge
of the messages after the NioProcessor.
The transformation component works in a reverse way compared to the decoder: it serialises the POJO response coming from the handler process, to the output stream, toward the client. Likewise the handlers, it is possible to delegate its own encoder for each response object, but why not to send the IoBuffer straightly from the handler that elaborates the request? Separation of concerns might be the answer. The handler receives a command, a java bean, then it is processed and the handler returns an object for response, a POJO. It’s up to the encoder to transform the abstract response to a concrete message through the agreed TCP protocol.