Leveraging stateful and stateless frameworks
September 16, 2008
I would not be exaggerating if I said its a war out there between the supporters of stateful and stateless frameworks and solutions in Java. Add to this melee the number of frameworks that are built on either of these two premise. An application developer is therefore spoilt for choices and often confused. The easiest way out is to align with one of the camps and trust their solutions.
Proponents of the various frameworks vouch for their solutions – a natural thing, but unfortunately it is biased due to their own business interests. I’ll take two solutions for illustration purposes – Spring and JBoss Seam. I am a big fan of Spring and am interested enough to dabble in Seam. FYI, one of my projects uses Seam extensively and I personally have designed complex systems on the JBoss platform in the past. So, there is no bias there. I’ll use an example to illustrate the comment on bias - I find the Spring Acegi framework to be a great solution for application security. I suspect the people behind Seam might think likewise but will never integrate the two. I read something about they having evaluated Acegi and decided to write their own. JBoss Seam security looks good but one is forced to write stuff for say RDBMS or LDAP based authentication while it is readily available in Spring Acegi. Other useful features are Transaction(compensation based) support for LDAP operations and the Spring AOP implementation.
I do believe the need for evolution. Hibernate came along and changed the way we wrote JDBC access. But, I would hate to see somebody rubbish stuff that others have done before. For e.g. I dont subscribe to Gavin King’s (creator of Hibernate and Seam) thought that applications are by default stateful. Maintaining state comes with a price – we have all not forgotten the problems we had with earlier versions of Stateful EJBs, Entity beans and Http session replication. I dont think Seam has cracked this entirely yet despite claims that the JBoss clustering on JGroups does fine grained replication of changes. My team members complain of huge files on the JBoss server environment that is presumably used to passivate state. I would not convince myself to write all my applications as stateful ones even if the associated framework claims greater productivity (this is debatable and the answers are unique to situations).
The best solution for an application developer like me would be to use the best of both worlds. There definitely is a case for using both Spring and Seam in your application stack. Lets look at an architectural paradigm that has generated lot of interest these days – SOA. Web services over Http and JMS are common technologies used to implement services in a SOA. Both these technologies advocate a request-response model and are mostly stateless. Spring and its integration with a framework like Mule make a compelling choice to implement the services layer. However you need more than just services to build an end application – you need a presentation layer, a mechanism to maintain conversational state (between user and application) and ability to perform data access where the nature of the use case does not require you to write it as a service. Enter Seam and other productivity enhancing web frameworks like Grails. Presentation frameworks and component libraries (Facelets, JSF component libraries, jQuery) e.t.c integrate nicely and is rarely an issue.
Such an approach allows one to leverage the scalability benefits of stateless frameworks (for the services layer) and the productivity benefits of the stateful frameworks. A combined reference architecture that demonstrates building stateful applications on a stateless service layer in the true spirit of SOA is useful. The MindTree Momentum platform achieve this – leverage the best of open source stateful and stateless frameworks.