out of the way

The application being discussed has to behave in the following way: perform the client authentication, accomplish the request and response operations and forward notifications asynchronously to the client. The Mina framework fulfills these needs because it was created to be as much flexible and easy-fitting as possible to the most of the use cases. Mina is structured in several layers, that briefly they could be listed on those which concerning about: input parsing, execution of concatenated processes and serialisation of the related responses, if needed. The infrastructure take care of the I/O tricky affairs, while it lets you write upon it your business processes and handle the session lifecycles through simple callbacks, that you can manage within few codes. Majestic! I love it.

Furthermore, I was looking for something that could help me to write down the application which implements many commands, preferably in a good looking way, where each piece of service could be isolated from the rest of the application. Even this fancy of mine has found satisfaction at once.

The demultiplexer is a device with a single input and many outputs. Its role is to select the output line accordingly to the context rules. This pattern is also implemented in Apache Mina for writing decoders, handlers and encoders and I found it onto demux packages, they are: DemuxingIoHandler, DemuxingProtocolDecoder and the DemuxingProtocolEncoder.

Filters
They could be used for several purposes: I/O logging, performance tracking, thread pooling, overload control, blacklists and so on. In my case I configured two filters, one for the user authentication, and the other for thread pooling. Once the user is logged in, the authentication filter removes itself from the client session filter list, while adding the one which transforms the raw input into POJOs.
Decoder
The TCP server must implement a proprietary protocol, it’s a simple ASCII protocol for exchange commands, their length is undefined and the end point is a sequence of termination characters (likewise SMTP). Therefore, I extended the CumulativeProtocolDecoder class that gathers the input until the end of command, and leaves to us the parsing of the bytes and the creation of a simple Java Bean. After that, the bean is going to be driven to the filter chain to be executed.
Handler
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.
Encoder
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.