Make Things Simple

Walzing with the Tech crunch

The economic crisis we’re currently going through is teaching some lessons to the Western countries, in particular to the Anglo-Saxons, that our grandparents know pretty much, although it seems we’ve forgotten the past years in this  financial bubble. The debt has several pros: allows building, buying, investing and, when properly managed, might ensure a safe return and a fair growth of the economy. However, the debt has an outstanding bad side: it must be paid back.  It might be postponed, rolled over, shifted to other (more or less conscious) subjects, and its dreadful effects would be identified as bankrupt, credit-crunch, real estate bubble and recession.

With a view to the software applications, a similar observation might be rightful in terms of ‘state of health’, which point to a family of properties that the software should have to be easy changeable, so it could respond quickly to the requirements evolution. A software that doesn’t enjoy good health is the one that has become fossilised to the original architecture, keeping it as is as possible, never revisited in the light of technological innovations and functional updates, but just patched with improvised and unconvincing surgery.

It’s suffering what it could be defined as inability to bear the debt built up over time, but in this case we’re not dealing with financial debt, this is the technical debt. Even though the term ‘technical debt’ sounds strange, it’s related to the financial fellow in many ways, and it is widespread in software development. The saying according to which economy is based on credit (debt) finds support also in the software world.

Developers who are reading know well what I am talking about. You’re assigned to work in such XYZ firm from next Monday for at least 3 months, and when you’ll start this new task you’ll be instructed about what to do.

The workout mainly consists of implementing new features on top of the customer’s solid rock application, a very remarkable system built some years ago for serving peculiar needs.

So far, it has worked well, the owners said, you may just make it worse than it is now. Later on, you have no choice but to agree with them.

Expanding or changing the set of features without re-factoring looks like seeding a crop without ploughing the land before, if the system’s authors didn’t predict such an amendment. The harvest could be lost, couldn’t it?

You’ll be asked to complete your job updating the old system and keeping the structure as it is, avoiding to break the fragile balance among components. 

Just for you information, consultants were called few months ago for a similar task. They added such a mess into the code that you have to spend most of your time to figure out what they wanted to do than working effectively on new things. Maybe the customer were disappointed by their way to conduct the development and now it’s your turn.

Thus, in addition to the new enhancements, you should fix what your precursors did. 

This subject is hard to handle and quite unpleasant in particular when the customer doesn’t want to hear talking about re-factoring unless it doesn’t delay the delivery, which is almost impossible, so the scheduled task proceeds as expected.

In short, it looks like going for a walk over the broken glasses swearing you won’t be injured.

Using the post’s subject, it looks like getting into debt again for covering the old one, just for adding short term solutions when too many of these have been applied in the past.

Looking back at the past, I’m realising how this kind of intervention is predominant on the amount of works done, that I don’t know how much time I would have to wait unemployed if I wanted to work only into brand new projects…

Sometimes I’d define myself as a debt collector, and I find it uncomfortable as a lawyer or a doctor would feel against a criminal prosecution or a rescue surgery: it’s an exploitation of other’s misfortunes. It might be painful, but we make the customer feel better.

Powered by Apache Mina

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.