Thursday, September 16, 2010

To be or not to be GWT?

With the current project that I’m working on, I had to work out some GWT stuff to get specific UI level requirements done. In fact I’m not 100% convinced the way it was done that started pinching me to explore more about it.

This is the first time I touched GWT in real live project development. Being java developer for a long time, I have never come across this much of complexity at the UI level especially when you have been dealing with latest technologies and tools. Basically this system has several layers of wrappers before it really feed with back end calls. Also it contains an in-house written configurable UI Binder that uses xml file to configure the UI. According to my understanding this was done to make reusable and scalable UI level components. But I’m not sure if a software house should invest this much of resources to make front end reusable and scalable as these front end tools can be easily replaced by a new technology that is yet to be arrived in near future. As of now, with GWT 2.0 there is a UI Binder feature which allows you to configure your UI in xml files. In fact I found out that smart-client offers you same kind of configurable UI. So all effort they put to make UI configurable is in vain with this kind of releases. Another disadvantage I see is the expertise required to develop the front end. Front end development supposed to be something different so that it requires different mindset with creativity. Obviously GWT development requires experienced java developers, not the creative designers :). So are we doing Swing development for the web? I really feel someone should have considered writing a tool to convert swing applications in to GWT type of front end applications which could have added more value, considering the power it brings to the web applications. There are number of cool features that you can enjoy with GWT based front end, providing an end to the all time headache "browser compatibility".

In my readings, I came across Flex which has similar kind of UI dynamic binding scripts but something easier to deal with. There are so many pros and cons with both GWT and Flex. There is a good comparison here
- More readings.
- Loading speed comparison

Wednesday, May 19, 2010

ESB competition,This is how it began...

"Ultra ESB", another class product from a Sri Lankan has been released. They've published the results of the Round 4 benchmark testing. Its interesting to wait and see how vendors such as Mule, BEA, WSO2 reacts on this. http://esbperformance.org/wiki/ESB_Performance_Testing

Thursday, November 26, 2009

Lets make the web a better place


Speed of the web matters everyone who browse over the internet. Internet has come a long way to reach the level of speed that possess today. Still it demands a better and better speed to make possible many great things that are restricted due to slow internet speed. Google has put a step forward to solve this for the world. It’s a great effort, as people who build the web we all should contribute. Please refer: http://code.google.com/speed/articles/

Thursday, November 19, 2009

Caching Service

While I was working on my last assignment, there was a need for implementing good caching solution for the company. This has been a long time headache as we did not utilize proper caching mechanism to cache our frequently used data. Only single component that we were using had many draw backs and it was so much restricted cache reservation details only. The highly coupled nature of that component sometime made trouble shooting a nightmare for developers. As I was assigned to work on new searching component, with my refactoring cycles I had to remove most of the highly coupled back-end logics ultimately existing component became obsolete. Therefore I started working on new component and designed it in such a way where we can use it as a service.

This Caching Service has been developed to facilitate data caching needs required not only by our system, but also any JEE based system. When talking about Caching service, a framework is essential to build and govern the infrastructure of it. Therefore I came up with a framework that accommodates existing caching needs with extensibility in mind.


This is a very powerful framework that can be used to implement new caching mechanisms from the scratch or it can be used as an interface for 3rd party caching engine (MemCache, JbossCache, OSCache … etc). It has a user friendly monitoring interface with functionality rich including the flushing results, flush contains by systems connected, view particular requests, delete particular request … etc.

The beauty of this is it has a central control over all systems connected to caching engine and you can govern them individually. You can have multiple systems connected to multiple caching engines, but you can govern and monitor them in a central location. You are free to add new caching solutions written by your own or you can plug new caching engines that use the same set of operations.

I have an idea of sharing something same as this framework to the open source community let’s see what kind of improved version I can come up with.

Wednesday, November 18, 2009

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.

Sunday, November 15, 2009

It's a place to be ... The Apache Asia Roadshow 2009


The Apache Asia Roadshow 2009 is scheduled to hit Colombo from the 3rd - 5th of December. The layout of the Roadshow would be a two day conference and a one-day hackathon/ unconference at the beach. If you are interested in anything Apache related then this is the place to be