Heart of the system, Reservation search reengineered

I’ve concluded the new search component for Base system. This has been done in fully scalable manner which aligns with most of our future technical goals. It is important for everyone to understand the concept so we can make sure the new structure would not be affected with new requirements. In order to place the new component with existing structure, several re-factoring iterations were occupied within the same set of objects.

What did I do there?
This is actually very vital question to be answered. Because to the front interface this could be nothing more than retrieving results, may be in much stable manner. But there have been lots of exercises done to ensure the application structure, transaction management, concurrency and most importantly application extensibility. It is important to have an idea about the drawbacks we faced with previous structure.

• Highly coupled front end business logic

There were bulks of logics identified inside web application tier. These business logic have to be separated and reside inside server application in order to be aligned with the meaning of a layered architecture.

• Caching mechanism is tightly coupled with the web application

We had our caching component coupled so much with the web application. This kills the reusability of that component and there were no centralized controlling or monitoring capability.

• Server was not serving properly

We have used server application just to run particular application logic only. Sever had no control or idea about the application flow, it was only managed by the front tier. For example calling thread x and thread Y runs as two different processes. Finally it’s managed by the front tier application which we should have used to process UI tier functions.

I heavily used some refactoring methods to bring this structure to level where I can start re-designing.