Currently the technologies involved are:
On the server:
- Spring framework, iBatis, ehcache, Quartz, Velocity, and eventually the servlet container (not yet decided.. but the development is obviously done using Tomcat).
On the client:
- GWT and a few velocity pages.
The novelty for me is the use of GWT (Google Web Toolkit). I've already mentioned my frustration in developing client side code especially using http-based web client. The time spent on the page design messing around with jsp tag, html and css styling seems to me as a big wasted time and effort. That's why in my professional life I'm usually involved muck closer to the back end where my expertise is more profitable for the client.
Now with the advent of GWT, client side component is no longer restricted to thin and dumb page presenting the view/model already prepared on the server. A lot can happen on the client with the capability to hold on great deal of state information and business logic. And this magic is done without adopting Javascript and sacrificing the strongly-typed property of Java.... the toolkit does the Java-->Javascript conversion for you!!!
So far I'm quite pleased with the toolkit as it practically eliminate the need to write any html markup... however all styling still depends on css. I'm probably half-way there for the client part and only have a single html page with just a few lines of markup html code.
The server integration is done through RPC call (done asynchronously à la AJAX style) with servlet on the server end. A great deal of design effort is done by keeping the server scalability as a top priority. Because the application will target the web public at large, most design decisions are affected by this, e.g.
- Keeping minimal state on the server. As a matter of fact, with the help of GWT most state is kept locally while the server only keeping a session token (cache in memory) to identify valid client connection. This will avoid issues involved when relying on HttpSession object (to hold client state information within servlet container) such as server affinity and more importantly larger memory footprint per connecting session.
- Data is cached both on the client side and on the server side. Because some data is not mission critical, the client keeps some data content (limited size) and the server keeps all data content in cache eliminating the need to hitting the database back-end during most client request.
- The cache server data content is refreshed at fixed interval of time which is configurable depending on the data volume and the database query extraction time
- The cache server data content is kept in a de-serialized GWT form, avoiding the need to serialize the payload of server response at each client request.
I'm confident to be able to put a beta version of the application before the end of year... stay tuned!
Martin
Posts
