GWT for RIA – boon for Java (dev)lovers

Recently, I have been working on porting Struts, uPortal based legacy application to GWT. This work was initiated a year back to replace unappealing, non-responsive and slow user interface. Other requirement was to make client side technology stack lighter. Presence of lots of client side technologies (Struts, uPortal, JSP, Tag libraries, Java Script, Configuration files, CSS, XSLT) made it cumbersome to implement simple UI changes.

After initial analysis, we were clear on requirement of more AJAX effect across application. It was further evident that AJAX framework should be preferred rather than writing AJAX "by hand". After evaluating some AJAX frameworks, we decided to go with GWT. Other frameworks like DOJO and YUI library are good in adding AJAX effect to existing application but they did not solve some problems related to fat architecture and big technology stack.

One of the primary reasons for going with GWT was its unique approach to develop complete application: client side, server side using Java. GUI development with GWT APIs is similar to Swing development and it is refreshing to forget JSP, JavaScript, and Struts and write everything using Java. I am very happy with experience so far and we have vastly improved presentation layer while retaining service layer.

With GWT, AJAX front-end is written in Java that gets compiled into highly optimized Java Script. Developers need not write Java Script while end users are provided with dynamic and standards-compliant AJAX experience. On deployment, JavaScript gets downloaded on the browser thus releasing the server side from handling presentation stuff.

I am overwhelmed by many developer friendly features of GWT. Usage of Java in presentation layer facilitates applying design patterns and creating reusable widget library. GWT approach for history management, internationalization, and service layer interaction is easy to understand and implement. I felt spoilt by choice of available tools, default support for all browsers and ability to debug AJAX in Hosted mode. I also noticed intangible benefits like elimination of training on multiple technologies, reduced dependence on technology experts, and reduced development cycle.

I have heard arguments that Flex is a better RIA choice than GWT. I think this may be because of lack of availability of all widgets in GWT. GWT does inherently provide lots of cool widgets but it is possible to use third party widget libraries if they are not sufficient. We used GWT-EXT, a very rich widget library.

I found some essential features i.e. lack of multiple module support, lazy loading of modules missing that may make GWT misfit for huge enterprise applications. I also faced some problems due lack of emulators for Java packages used in existing server side code.  Good thing is that there are workarounds available to solve these problems. I strongly recommend GWT if you are developing midsize application and need desktop-like look-n-feel.

Should I retire my application?

Application software as a product has very short shelf life. In a typical product, one goes through conceptualize, construct, QA, bug fixing cycle and one fine day it goes LIVE. Suddenly, there is mayhem with customers digging out issues QA never found, demanding features never signed off but are critical, reporting issues not reproducible in staging / development.

Eventually everything settles down with issues either fixed or workarounds provided. There are happy customers getting business benefits supported by happy developers providing enhancements for life. Right? Wrong after a lull period everyone starts complaining again.

Customers complain they are not getting required benefits from application; new features are breaking existing components. Technical supports guys complain that the workarounds are irritating; components just freeze at peak load. Developers complain it takes ages to deliver simple enhancements. And the list goes on.

Hence start talks of retiring and rebuilding application from scratch. Since everyone is unhappy it should be easy to decide in favor of retiring legacy application. Right? Wrong; I have never found it easy to retire a running application. I always find it better to rebuild specific components incrementally.

I find it tough to take a decision on retiring application and suppose everyone faces similar dilemma. Every situation is unique and decision will differ from project to project and client to client. I have a checklist of items to look for while deciding to retire or rebuild an application. I hope it would be helpful to someone making similar decision:

Desktop to web application

You have a desktop application developed couple of years back for target customers. There is great feedback and everyone is telling you about its great potential and how you should reach out. You learn about benefits of SaaS offerings but cannot move forward since application is not web enabled.

It is easy to decide to move to web enabled application but complexity arrives with possible choices. I worked on a project where client had a swing based desktop application that needed to be web enabled. We mulled on options to make it either browser based using Applet – Servlet communication / JWS or make it complete web application by rewriting complete solution using MVC framework. In that case we decided to go with JWS route since client was unsure of quantum of benefits and wanted to go live soon with minimal cost.

Problems with one layer

You have an application with multi-tiered architecture and majority of problems are reported in one layer. In this case we need to make a decision to improve or retire-rebuild this layer.

I worked on an application where problems were specific to Presentation layer. In that case, we replaced Struts, uPortal based presentation layer with GWT based web2.0 enabled presentation layer. You can read more about my experience in an earlier post here.

 

 

Home-grown solutions to standard technologies

Initially in my career, I worked on couple of very successful products developed with homegrown architecture. MVC frameworks like Struts were not readily available and many companies have come up with their own version.

One of these was a hugely popular insurance product suite. There were many requests for customization and enhancements. But, because of certain inherent flaws in core architecture, enhancements were either taking long time or were deferred. It was decided to rewrite product with WebWork, Hibernate and Spring. It turned out to be very good decision and helped in making product more popular. This was a big decision taken after careful consideration but there are simple cases. I recently worked on a project where we easily replaced home-grown wrapper component on Quartz with Quartz integration provided by Spring.

Redundant / over-designed features

Occasionally there are features in product never or rarely used. This leads to problems while implementing enhancements. Dependencies need to be fixed and tested in these seldom used features. Maintenance cost is skewed and money is being spent on useless stuff. In some cases, it may make sense to remove or simplify these components.

I worked in maintenance of a project with a component to show workflow change notifications on dashboard and to send them via email. Component served its purpose but had very complex subscription logic, notification control features with many options. Lots of issues were reported from production and most cases were due to lack of understanding. We redesigned this component and removed whole lots of complexity (and code) making component much easier to use.

Non availability of resources

There are products with no problem apart from the fact that they are built on technology for which there are not enough developers available. This leads to resource dependencies and it becomes very difficult to maintain application even if enhancement part is left. Sometimes,  in these cases it may make sense to shift gradually to newer technologies.

Modernizing application

Sometimes there are modern concept out there in market you just cannot ignore. For example, many application have been migrating to Service Oriented Architecture or OSGi off late. 

 

I covered some scenarios but know there are many left. It would always be difficult to retire an application and in each case proper cost benefit analysis needs to be done. Sometimes, retiring-rebuilding may look better option but on probing further it may emerge that existing component can be improved.

I worked on a text search component in a recruitment application. It took hours and sometimes days to index resumes and other documents. Customers and technical support was unhappy and initially it looked like worth rewriting. But the product has just started getting real customers and it was decided to wait. It worked with some minor fixes and workarounds for more than a year when it was eventually rewritten when more information was available and other components were being modified. I told you every situation is different and there are no hard and fast rules.

[End]