Quick solution for Spring & GWT integration

As promised in my last post, I'll describe here how I proceeded to integrate my service bean layer managed by the Spring container with the RPC mechanism offered by GWT.

GWT toolkit offers a custom servlet (RemoteServiceServlet) from which we can inherit in order to let client code calls server-side code asynchronously. The solution I implemented was to create a base Controller which simply extends the Google RemoteServiceServlet. See code below.
(I no longer has access to these files, so I just removed them for now)




By subclassing this new base Controller, all my service-bean classes become now GWT-RPC compatible. This simple solution has some drawback such as adding a compile-time dependency between my service-bean and the Spring framework/GWT, however that is just fine for my specific use-case. More clever solution could also make use of reflection in order to leave your service leaving the service-layer classes free of such dependency, however this will come at a price of more intense processing needs. For those interested see the GWT Server Library initiative.

However for me, this simple solution offered a very convenient caching mechanism to improve performance all client accessing these service-beans. Since I have some RPC service objects on the server layer for which result are cached to avoid the expensive database access hit. Because these result objects contain long object graphs (a few number of association at various depth level..), I also wished to avoid the GWT serialization process involved at every hit of these cached object graph. To achieve this, I wanted to store the GWT-serialized version
of my result objects instead of the normal de-serialized graph. The cache is planned to refresh itself at regular interval...

All my service-bean achieve this by optionally intercepting the RPC request (i.e. override the method 'processCall') and use the GWT-serialized value when available in cache (see example below).
(I no longer has access to these files, so I just removed them for now)




Martin

Web development

Up until my current project which uses GWT to develop a rich web client, I always followed the best practices in terms of Web development. I used to develop thin and dumb client view (e.g. jsp) which were fed and render based on data model objects and eventually sent back to the web client.

All web requests are taken care by some dedicated controller (or action in Struts parlance) that are responsible in analyzing the user request, delegating the request to the service layer (the core of the application where business rules usually sits), obtaining the return domain object from the service and preparing the response by selecting the proper view to be rendered and sent to client. Ok, that is a very brief and incomplete description of the MVC pattern adapted to the Web server and HTTP protocol. Although this design pattern may be overkill for smaller applications, the advantages (e.g. makes web applications that are easier to maintain and are logicially divided into layers that are inherently decoupled and whose focus are on very different software concern) usually outweight the additional learning curve and relative complexity.

A great deal of coding must be done on the controller aspect of the MVC. And a lot of this includes details originating from handling the request/response of the stateless HTTP protocol...which has very little to do with the main application business logic. If I'd have the choice, I'd rather spend this time developing and improving the business objects domain, the related business rules logic and the database model, i.e. my preferred subjects and expertise!


With the advent of AJAX Web 2.0 fat client, a great deal of the weight that used to sit on the web server shoulder implementing this MVC pattern has now moved toward the client sitting on the other side of the communication channel. Web clients now make asynchronous RPC (remote procedure call) to the server without having to deal with the of HTTP concern details (for example the RPC mechanism of the GWT API isolates client code these). They can also now handle their own session state by keeping and handling the data model locally.

The server can focus less on the "C" of the MVC, and more on the service core layer designed to enforce and apply all business rules logic. The client code can choose to implement the traditional MVC pattern, when its complexity justifies it.

In my current project, all web controller codes disappeared and my web application does not move anymore from one page to another (following subsequent user request), but rather change its unique page appearance (by replacing/changing section of page through DOM manipulation) followed by user action and RPC response from the server.

My next post will present the way I've implemented my RPC client code to talk directly to my service layer using the Spring Framework. Now, I need to get back to work!

Martin

my Web2.0 experience with GWT

My last month as a freelancer allowed me to have made quite important progress on my current project. I find it quite motivating since I'm the main analyst/designer/developer/tester and even business analyst (actually, I'm all alone on that one, so no one to blame or complain about;-). Technology wise, it's a perfect situation since I can freely chose all components based on design merit and no decision is based on political constraint of some sort.

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

La gang de Chicout!

Bon ce qui semblait anodin à l'époque relève maintenant de l'exploit: avec un petit groupe d'amis datant de l'époque du Séminaire de Chicoutimi, nous avons réussi à rester chums et garder contact à travers tout ce temps passé (ouch, près de 30 ans ou plus pour certains!!! ).

Les bases de cette amitié sont assez simples: on ne se doit rien et aucun reproche pour les manques de nouvelles ou absences plus ou moins prolongées... et le tout reposant sur un passé commun durant une période de vie assez agitée. Cette période demeure encore la source principale de nos discussions et anecdotes interminables.


Ca sera mon post le plus court car malheureusement on ne peut en dire beaucoup sans risquer d'entâcher et compromettre des vies d'adultes responsables ... quoique le risque d'en voir un tombé sur ce site reste faible!

Donc pour conclure voici deux clichés pris avec pas mal d'années, de kilos et d'enfants en plus:


Party d'une date quelconque mais assez lointaine :

Dernier party en date :

From photos_amis

Martin

Laurie and Mathias

I never spent too much time writing about my family here... naturally I tend to value more the time that I can spend with them instead of the time that I could write about them!

I just wanted to post a few pictures looking at my kids growing up. The thing that come into my mind looking at these pictures is: "Warning: Kids are less calm than they appear in photograph!"

But nevertheless we've got really two great kids, Laurie my daughter is now 5 and Mathias 3 years old and I'm confident that they'll continue making me a very proud dad!








Martin

That's it I'm changing career path!

I've eluded in my previous blog all my frustration concerning closed source software... and today I'm very happy that I finally decided to move on to a different career path: I'm quitting my job at IMS Health where for the last 4 years I've held various positions as BI developer, team leader, etc.

My goal will be to focus on doing more consultating type of work that will rely primarily on open source libraries/framework to deliver high-quality application. During the last few years, I've been lucky enough to get some external contract which made use of these libraries. And I really appreciated the possibilities that OSS can offer:

• in terms of quality of source code which helps to increase the quality of the application to build as well as your productivity
  
• but also in terms of the education opportunities it gives to increase your expertise and knowledge as a software developer

This career move almost coincides with our plan to return back to Europe... my wife and I have finally decided to go back in Switzerland by the end of this year or early next year. More on this on a future post...

What will I do for the these 4 months left to 2007? Well, I'm very anxious to continue a personal project that I started a few months ago like a fun 'passe-temps', but now is starting to occupy too much time in my mind and I need to get rid of it ... meaning putting it online asap.

Enough said for now, I need to get back to work.

Martin

OSS, the future of software development?

Came across this interview the other day from Lars Trieloff... "I believe that in ten years OS will be the predominant business model in the software industry". I usually tend to be quite wary and skeptical about these sort of long-term prognostics, especially in such a dynamic and rapid growth industry as the IT industry. However, Open Source to me is really the most effective way to produce complex piece of software. Without re-iterating the most cited advantages of this de-centralized approach, I'd just like to comment on a more personal experience.

At the office we are stuck with proprietary closed source software (no for long though.. more on this in a future post). As expected with software we hit a few limitations (read bugs) that were quite difficult to find a workaround or a graceful solution... all we were left with was a potential resolution in some future release of the framework (Reporting Services from Microsoft for this specific example)!

I can't help but compare this situation with a recent limitation I came across with Spring Framework a few weeks ago.

When trying to use EhCache for a project, I actually want to use the caching not only for what it is ... well i.e. caching, but also as a way to gather usage stats on the access of some of my service object methods. So I've defined a EhCacheFactoryBean while configuring it with the standard ehcache property file and decorated with a SelfPopulatedCache by injecting an implementation of the CacheEntryFactory. However, reviewing the code I realized that there was an issue, so in less than 5 minutes I raised a jira log and about 2 hours later my issue was assigned to one of the author of Spring, and corrected 2 days later!!

Well the fact that it took such as small amount of time to resovle the issue is very impressive and honor the commiters at Spring, although this could have very well happened in any other companies... but do you know a lot software vendors with such a quick reactive turnaround on bugs correction? However to me, the real advantage lies in the possibilities of having all source code at your disposal, it becomes trivial to simply write a corrected version and move on without having to wait for some future release. I can't help but compare this with similar situations we're faced with when issues are found at work with some Microsoft components.... well just too bad!

Martin

Consultation informatique

Dans ma vie professionnelle j'ai la chance de combiner deux types de travail assez distinct. Le premier est relativement commun car il implique un emploi comme "Lead technique" d'une équipe de développeur d'application de type BI.

Par contre, ma deuxième vie professionnelle est plus stimulante et comporte son lot de défis. Dans cette seconde vie, je fais de la consultation informatique (freelance) dans mon domaine d'expertise: i.e. tout ce qui gravite autour des tâches d'analyse, de design et développement d'application développée avec Java et exigeant des interactions avec des systèmes de base de données.

Mon cheminement professionnel m'a permis de maîtriser ces deux spécialités comportants certaines incompatibilités, soit l'implantation de systèmes de base de donnée basés sur un design de type relationnelles des données, et l'implantation d'applications basées sur un design de type Orienté Objet (dans mon cas c'est Java). Il faut noter que certaines incompatibilités sont quelques fois une conséquence de la mauvaise fois des gens de chacun des deux clans, mais ceci est une autre histoire....

La connaissance de ces deux spécialités s'avère d'autant plus utile avec l'explosion d'application sur l'internet dont les caractéristiques justifient l'utilisation de ces deux spécialités.

Tout cela pour dire, que je suis bientôt mûr pour un changement de carrière ... mon emploi chez IMS étant moins stimulant car nous servons une industrie beaucoup plus conservatrice avec de long cycle de vie des applications logiciels (je travail en ce momnent sur une application vieille de plus de 30a ns fonctionnant sur le Mainframe). Il faut dire que j'arrivais du monde un peu fou de la télécommunication qui est assez intense et garnie en terme d'innovation.


Martin

JDBC convenient programming with Spring

There is no need to re-iterate what has already been said and spread about the usefulness of the Spring framework... but it seems that every time I make use of a feature I come to the same conclusion: it simply makes you more satisfactory of your code, that is how I see it anyway !

Most of my database-related code usually made use of Hibernate because the sizing and the extend of the domain model simply justified leveraging the complexity of this framework.

However, in my current project I decided to give a shot at Spring jdbc support packages mostly because my domain model is simple enough (less than 10 entities with basic relationship) and because... well exploring more of the Spring library!


Although the library only really offers some thin wrapper around jdbc api (as opposed to a complete ORM solution), it does it in a way that you can create your data access code in a more object oriented fashion while keeping a close access to the underlying jdbc low-level api.

To illustrate this, I've created some helper classes (one per each business object entity) wrapping Spring jdbc data access object (e.g. SQLUpdate, JdbcTemplate, MappingSqlQuery) and offering a convenient way to centralize all sql-related string (sql command, table name and field, etc..).

On top of these classes, you can actually implement all generic sql access code (e.g. delete by id) and generic sql commands. Here's how look like the superclass, refer here as BaseSqlHelper:


And Here's one example of how one could implement a particular subclass (in this specific example the subclass handles sql for the User business entity object):



What does this offer you:
1- get all your sql strings contralized in one convenient place
2- benefit from code re-use by moving-up all your common fields (e.g. id, createDate,..) and common sql operations (e.g. delete from ... where id=, select ... from ... where id=) for all business entities into the superclass
3- exploit the MapRow capability to treat query response as real business entities and not merely as data field.
4- Ease for accomodating new fields and remove existing ones


Martin

Utilisation d'Hibernate

Pour faire suite au post précédent, j'ai observé que certaines applications sont construites sans tenir compte des limites et contraintes d'Hibernate... ils utilisent cette librairie comme le "silver bullet" qui va se charger de tout ce qui touche la question de la persistance et ce sans effort ou configuration spéciale!


Par exemple concernant l'utilisation du Paramètre Lazy dans le mapping, plusieurs applications sont configurées avec lazy=false. Ceci facilite évidemment la question du fetching des graphes d'objet, mais ceci à un prix et ce prix s'appelle performance!


Recommandation:

Pratiquement toutes les entités et les associations de compositions devraient être configurées de façon Lazy (i.e. lazy=”true”). Il ne faut pas confondre le paramètre lazy et le paramètre fetch, le premier indique seulement à Hibernate s’il pourra créer un proxy (qui exigera une initialisation en session ouverte) pour la classe en question ou la collection, tandis que dernier indique comment les relations doivent être fetchées (eager ou non).

En utilisant lazy=”false” ceci a comme « side-effect » de pre-fetché toutes les dépendances de l’entité et ultimement la base de donnée complète sera chargée en objet ! Cela peut être pratique puisqu’on n'a pas à se poser la question de devoir initialiser ou pas les dépendances, mais ça devient vite catastrophique lorsque le volume de donnée est important.

La décision de fetcher ou ne pas fetcher (eager fetch) est une stratégie qui doit être défini en runtime puisque différente utilisation exige différent accès aux données. La couche DAO peut être utilisée en ce sens en fournissant des options de loader ou ne pas loader les dépendances (avec Hibernate.initialize()) avant de fermer la session Hibernate. Configurer avec lazy=”false” élimine tout simplement cette flexibilité.

Si pour une raison quelconque, une dépendance d’une entité doit toujours être pre-fetché, alors utiliser l’option fetch=join dans le mapping mais en gardant le lazy à false pour cette entité dépendante.

L’auteur d’Hibernate a lui-même reconnu ce fait et recommande depuis Hibernate 3.0 que toutes les mapping des class et des collections soient lazy= ‘true’ (ceci est maintenant le défaut utilisé).

Martin