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.



September 9, 2008

Let me set one thing straight – I have never been a big fan of certifications. It stems from ones on programming languages that require you to remember stuff that is easily found in the API docs. And, of course the aversion to written examinations that all of us with Indian schooling know so well of and consequently loathe 🙂 I have therefore never taken up any professional certifications.

So, it was with some misgiving that I responded to a colleague’s query if I would like to take up the Microsoft Certified Architect evaluation. Having used Java predominantly the last few years, my first and obvious question was – how is the MCA relevant to a Java person? I listened a bit to the process and decided to give it a try for two reasons:

  • The evaluation process was around a solution that one has architected i.e. it was case study based
  • My colleague’s persuasion that it was a worthwhile experience
I’ll leave the process of evaluation out and just say this much that I created a few documents on competency, case study and a presentation that was to be presented to the board. The initial screening round was telephonic and was done by an existing MCA.
The review board was a 4 member team that I had to meet face to face and “defend the case study” as the process put it. I was truly impressed by the end of it all – not because I got the certification but because of the manner in which it was conducted. The review by the board was the highlight of the process and I mentioned thus when asked about the motivation for taking this up.
A few impressive things about the process :
  • Emphasis on one’s own experience in architecting a solution and almost neglible theritical knowledge. One can in no way prepare for this evaluation overnight.
  • Thorough professionalism of the people involved. You work and interface with existing MCAs throughout the process. I interacted with a total of 7. This is significant if you consider that there are a little over 100 MCAs worldwide. Thats the amount of focus and attention every candidate receives.
  • Clear sepraration of roles being certified – Solution architect & Infrastructure architect. There is Enterprise Architect as well. I applied for Solution architect.
  • The feedback one receives at the end of the certification. This feedback is very personalized. For e.g. specific books that one is advised to read based on the board review.
  • The collective experience of the architects on the board. It is OK to admit you dont know answers to questions(you will during the review :)) that come at you in quick succession. I learnt it is difficult to match the collective knowledge of all those gentlemen on the board. I am guessing the average age of a MCA on the board should be well over 40 – seasoned architects surely!
  • Inclusion into the fraternity of MCAs. This is a small group of like minded people. I was invited to be a panelist speaker at the “Microsoft Architecture Days” session in Bangalore. I was allowed to talk about Java when discussing the topic “Software + Services”!  This might be unheard of before.
  • Lastly the nicely mounted  certificate signed by Bill Gates 🙂
Where does the “Sun Certified Enterprise Architect” stand in comparision? Again, I was unaware of its existence until recently when I saw it on a candidate’s resume. I was impressed by the name and the source and therefore did some googling on what it took to become a SCEA. This was before I spoke to the candidate who was a SCEA. I was disappointed by what I heard and what I read about the certification:
  • Firstly, the evaluation process tests one’s skills at application design and at best solution architecture. I feel it is a complete misnomer to have “enterprise architect” in its name. 
  • The process is mostly offline. I wonder how “cheating” is prevented i.e. one person defines the solution on behalf of another.
  • Competencies essential to an architect such as communication, leadership, process, e.t.c are not evaluated here at all. 
  • All the benefits or highlights I experienced in the MCA are missing here. 
It would really do good to make the SCEA more interactive, personal, effective and valued especially since it comes from such a credible source as Sun Microsystems. Until then I would continue to vouch for the MCA programme – true value from Microsoft.

I warmed up to the idea of OSGi after reading an introduction like : “Use OSGi to service enable your JVM”. For background, we at MindTree have created a SOA based J2EE delivery platform built on open source technologies – primarily Spring. In this framework, we expose POJOs as services using Spring remoting and access them via the Mule ESB. The idea of being able to expose POJOs as services without having to remote enable them made OSGi an interesting proposition.

I chose Spring Dynamic Modules(Spring DM) for three reasons:

  • I hoped to leverage all of Spring’s capabilities while writing my service
  • Ability to manage my service POJOs as Spring beans
  • Easy migration path for our framework

My test was to write a POJO, declare it as a Spring bean and an OSGi service (using Spring DM) and eventually access the service from a standalone application. This completes a typical usage scenario. I used the “simple-service” sample code that comes with the Spring DM distribution (version 1.1.0).

I faced issues either because I was not able to find the right documentation or because it was simply not there. I encountered and eventually overcame the following issues:

  • Ability to launch an OSGi container in standalone mode and without the prompts – most samples on the internet showed me how to bring up Equinox with the “osgi>” prompt. This was easily solved though.
  • Ability to load all the required OSGi bundles *before* I could load my bundle
  • Look up a published service from the bundle I deployed and invoke it from my standalone code

A few lessons learned from this exercise are:

  • OSGi is very strict when it comes to class visibility and loading. Parent class loader delegation does not apply – something we are very used to in J2SE and J2EE applications
  • It is easy to share services and packages between bundles. Not all that easy if you want to share between a bundle and a non-OSGi client application. For e.g, you cannot simply type-cast a service you have looked up to an interface that is packaged in the bundle and available on your local classpath.
  • Boot path delegation (creating fragment bundles i.e extensions to the system bundle) can help address the above need but must be used selectively and carefully in order to preserve the benefits of OSGi.
  • All bundles are loaded asynchronously. You need to account for this before you look up any service.

I have replicated below the manifest contents from my fragment bundle (one that exports the common interfaces & classes) and the service bundle (one that imports the common interfaces and implements the service):

Fragment manifest:


Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: m1000350
Build-Jdk: 1.5.0
Bundle-Version: 1.0
Bundle-SymbolicName: org.springframework.osgi.samples.simpleservice.boot
Bundle-Name: Simple-Service-Sample-boot
Bundle-Vendor: Spring Framework
Fragment-Host: system.bundle <— note this extension
Export-Package: org.springframework.osgi.samples.simpleservice <— note this export
Bundle-ManifestVersion: 2


The manifest for my service bundle looks like:


Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: m1000350
Build-Jdk: 1.5.0
Bundle-Version: 1.0
Spring-Context: *;create-asynchronously=false <— Spring DM integration
Bundle-SymbolicName: org.springframework.osgi.samples.simpleservice
Bundle-Name: Simple-Service-Sample
Bundle-Vendor: Spring Framework
Bundle-ManifestVersion: 2
Import-Package: org.springframework.osgi.samples.simpleservice <— note this import


I have attached the code for my sample application. Unfortunately, the complete Spring DM integration (the use of OsgiBundleXmlApplicationContext) does not work and I have posted a question on the Spring support forum :Spring DM issue.

I was however able to invoke the OSGi service from my non-OSGi client.

Disclaimer: The code is just a sample and is not validated in its approach or manner of using the OSGi platform.

OSGiTest – Rename to .java and open in your favorite editor

Today it would not raise many eye-brows if I said that an application server need not necessarily be a physical standalone entity or process and can actually be “assembled” from a set of available frameworks. Thanks to frameworks like Spring and standards like OSGi (and containers supporting it), this can be realized and not remain just on paper.

How about an ESB? The picture that most of us have seen (and reproduced in this post : Myth of the ESB ) appear to imply this big central infrastructure that acts as a conduit for all integration and message based interactions within an enterprise.

How easy or difficult is it to realize such a deployment in an organization? I have worked on SOA for a few years and more recently on deploying ESB as an infrastructure component in a SOA. Not once in these cases have we done such a deployment. Why? The answer is simple – most organizations take an incremental approach to SOA adoption and not all existing applications are amenable for migrating their business logic as services and thereafter accessed via an ESB.

Does this mean an ESB is only a promise? No, if you care to see it a little differently. I’ll go back to my earlier example of an application server. In the world of light-weight containers, components and dynamically loaded modules, the application server can be seen as a set of capabilities realized through an integrated set of components,frameworks,libraries and a runtime. The advantage here is that one can use as much of the application server as is needed.

If I were to apply the same analogy to an ESB, the first question that comes to my mind is – what are the capabilities of an ESB (or) what can an ESB provide to an application? IBM puts it nicely (and using a nice term) by defining a “Capability Model” in their Redbook on “Implementing an SOA using an ESB”. This capability model, for me, also serves as a good yard stick to measure an ESB offering – sort of a self compliance check.

A gist of the capability model is listed below:

  • Communication : Routing, Addressing, Response / request, Publish / subscribe, Sync/Async e.t.c
  • Service Interaction: Service interface definition(WSDL), Substitution of service
    implementation, Service directory and discovery
  • Integration : Database, Legacy and application adapters, Service mapping, Protocol transformation
  • Quality of Service : Transactions, assured delivery
  • Security : Authentication, Authorization, Security standards
  • Service Level : Performance, Throughput, Availability
  • Message Processing : Content-based logic, Message and data
    transformations, Validation
  • Management and Autonomic : Administration capability, Logging, Metering, Monitoring
  • Modeling : Object modeling, Common business object models
  • Infrastructure Intelligence : Business rules, Policy driven behavior

Now thats a huge list of capabilities and you may not need all of them – again like in an application server, you may not need JNDI, JTA, JMS and an EJB container all at once. However you can integrate these capabilities when needed. Can you do the same for an ESB? Yes, you can. Its a different post altogether how one can do that. One might ask this question : but why take the trouble?

The answers come from the cost of deployment, the set of features truly available in the fancy ESBs and the flexibility of actually using an ESB’s features but within your own runtime process. There are quite a few light-weight ESBs that help you do this. If you carefully look at the features in these ESBs, you’ll notice that they fall short of the Capability Model in more ways than one. This is true for the commercial ESBs as well. The lack of standards adds to the disconnect. In the meanwhile, considering an ESB as a logical set of capabilities and using it that way puts many things into perspective – including the value of an ESB in a SOA.

Myth of the ESB?

September 14, 2007

Many in the industry consider SOA as hype and ESB as another, both related, nonetheless. Is it a hype or a matter of failure of understanding? Agreed the hype is fostered by promises of either(or both) being a panacea for all your systems woes.

Lets get to simple descriptions of the two entities : SOA is an architectural approach and a methodology while the ESB is a pattern/logical group of capabilities that are employed to realize the SOA. This means that you are unlikely to find the ultimate SOA/ESB product that addresses all your architectural concerns, no matter what the product vendor says. I am sure all of us have seen the SOA triad of provider, client and broker depicted like below:

SOA - triad of provider, consumer and broker

Also you would have seen the ESB “silver bullet” depicted as below :


Before I go further, let me clarify that I am a great fan of SOA and the ESB. I have employed both and seen clients benefit from it.

The title of this post was suggested by a client project manager, who along with his organization – a large airline, was entirely sold out on SOA and a commercial ESB offering. It took a 3 month consulting assignment to establish the Why and How of SOA and determine what an ESB could provide.

I will first list a few busted myths about SOA and ESB, in no particular order:

  • Writing a few web services does not mean you have embraced SOA
  • SOA is not an IT initiative alone and involves Business and Operations just as much.
  • Neither SOA or ESB are silver bullets for your organization and not everything can/must be a service.
  • Service reuse does not always translate to using the service in a hosted mode.
  • Web services are not the only way to implement services in a SOA.
  • There is a big difference between Process Orchestration(BPM through BPEL) and Service Orchestration aka Composite Services(an invocation like Service A –> Service B –> Service C within a shared context say transaction or process).
  • ESB provides certain infrastructure for your SOA. On a case-by-case basis you would still need the following: Service Container, Service Registry, Service Repository, Service Orchestration.

Do all of the above erode away the promise of SOA and an ESB? The answer is “no”. The key is to clearly establish your SOA adoption (see my post Methodology for SOA Adoption ) and use a capability model(see IBM redbook on “Implementing an SOA using an ESB”) to evaluate the need and features of an ESB. You will then see that pictures like the ones above are not myths but reality.

Bring up the topic of stateful and stateless applications and you can guarantee to get a house divided, almost equally on both sides. There are die-hard proponents of statelessness (and frameworks to support it;Spring for one) and those that support stateful behavior(and frameworks to support it; JBoss Seam for one) .

This leaves the average developer confused – is holding state good or bad? The answer is different : It is inevitable in circumstances and avoidable in certain others.

A regular web application normally contains state while service calls in the integration or infrastructure layer may not. Often the latter is designed that way i.e being stateless for sake of scalability and fail-over.

An often used approach to maintain state is a user session. The most common choice is the HttpSession. Cluster-aware application servers handle replication of these sessions. In-efficiencies in session replication are often cited as reasons to move to a stateless design or look for alternative means for replication. Lets take a look at common approaches to managing user sessions before we decide on the merit of this move. Session replication choices:

  • No replication. No fail-over. Sticky behavior is the only choice in a redundant server deployment.
  • In memory replication. Default behavior in J2EE application servers.
  • DB based replication. Optional behavior in .Net and Ruby On Rails platforms.

Take any approach and you can find people give you many reasons why not to use them. Some of reasons can be : lopsided load in case of stickiness, inefficient in-memory replication and cluster license cost(3 times more) in case of in-memory replication and increase in DB I/O in case of DB based sessions.

We might do better by addressing the problem before trying to find more efficient solutions. Control over what is considered as valid state and the size of the state object graph matter more. I follow these principles/practices when handling state in my application. Some of them are not new and are in fact best practice recommendations for performance, robustness and overall hygiene of the system:

  • Store only key information in the session i.e only minimal data with which you can re-construct the entire session graph.
  • Store only domain model or equivalent data objects. Avoid objects that hold behavior. An easy way to implement this is to wrap session access with a layer that entertains say only XSD derived objects, which effectively cuts out behavioral class instances.
  • Set a limit to the size of the session i.e avoid large session graphs. The session wrapper can ensure this.
  • Persist session only if dirty. Applies to cases where there is container support and in custom session persistence implementation.

An application that follows all of the above would rarely need to debate on the cost of maintaining state via sessions – in memory or in the DB.

DB based persistence is considered expensive and a mis-fit to store transient data such as user session information. However, interestingly frameworks like .Net and Ruby on Rails(RoR), that matured later than J2EE, provide this as an option. In fact, it is the default in RoR, if Iam not wrong.

Recently I had the choice to architect a SOA based platform to build applications on top. We wanted the core services to be stateless to easily scale out when required. Naturally we preferred the application servers to NOT be clustered and be load balanced instead. The applications built on top had to contain minimal state however. We also decided to mask session management from the consuming applications and implemented session persistence and therefore recovery using the DB. While there were initial apprehensions about DB I/O bottlenecks, adopting the principles described above helped us tide over the issue. The end-applications have been in production for a year now. The logic we used in favor of DB based sessions was this : nature of DB access for say 100 concurrent users would mostly be READ with the odd case of a WRITE(i.e when session gets dirty). 100 reads of small sized records using an index on a table is extremely fast as there are no concurrency or transaction isolation issues as each read is for a specific record independent of the other. Anyway, we have the option to switch back(courtesy the wrapper over session management) to Http sessions and clustering if performance sucked, which hasn’t happened till date.

To sum it up : the debate between Stateful and Stateless applications and consequently that on the most efficient session persistence/replication mechanism is really a matter of choice if session is handled with some discipline in the application.

One of the first few questions an architect would pose when designing an application would be: what are the availability needs of the system?

The answer would not only influence the overall architecture but would trickle all the way down to application design, choice of technologies and of course the physical deployment.

Clustering solutions help to address availability needs by aiding deployment of redundant servers that fail-over in real-time.

There is a cost to redundancy though, and often a high one. While at it, be prepared to spend a few hundred thousand dollars on software licenses if you use commercial J2EE app servers and RDBMS that are priced on per CPU basis. Now, as an architect you need to fight another battle – that of justifying deployment and ownership costs.

Sharing infrastructure between applications helps to ease this burden. Is it not nice if three applications can be “co-located/co-deployed” on the same set of boxes and thereby only incur one-third the cost that would have been the case otherwise?

The rest of this post is about recommendations, challenges and potential pitfalls in creating and using a shared infrastructure.

I have chosen the term shared “infrastructure” instead of shared hardware intentionally. It is because co-deploying applications often needs more than just computing boxes. It requires a holistic view of your applications – from development to final deployment.


  • Firstly have a broad technology blueprint that applies to all your applications. Decisions here include technology stack – Operating System, RDBMS vendor & version, Application server, tiering of applications, hardware configuration – scale up vs. scale out.
  • Consider a common boiler-plate structure for your code repository. The structure is prescriptive on what goes where(Html,images, JSP, EJB, DAO, SQL Scripts, deployment descriptors) but does not dictate package hierarchy say.
  • Create a unified build and release process. This includes build scripts, final packaged binaries(exe, rpm, so files) and the supporting artifacts that enable the release & continuous integration.
  • Identify and build/buy/wrap common services & components across the applications. They may be across the various tiers – data access, security, scheduling, pagination, internationalization.
  • Establish clear guidelines on resource usage and communicate to all project teams. Indicative ones can be on : connection usage & release, JVM heap – stateful vs. stateless behavior, synchronous vs. asynchronous modes, Transaction demarcation in applications and with common components/services.
  • Design the tiers and common components/services in such a way that they may be remotely deployed. Can help to isolate heavy use components and move them to dedicated servers – batch jobs run by the scheduling component for e.g


The challenges arise largely around the recommendations themselves.

  • Governance – ensuring the guidelines are adhered to. Peer reviews work great here.
  • Uptime of the infrastructure – a downtime can affect not just one but all of the applications.
  • Monitoring and administration process, tools – Monitor the infrastructure for signs of distress – over use of CPU, memory, resource pools.
  • Personnel skills and training – The overall infrastructure in a shared setup is mostly more sophisticated than that of one dedicated to a single application, at least initially when setup. Specialized skills around clustering solutions – OS onwards, shared data storage(NAS, SAN), physical security would require good in-house skills or the services of consultants.
  • Smooth roll-out and compartmentalized releases that have minimum downtime of the shared infrastructure. For e.g, the ability to turn off individual silos, deploy the release and bring them back on.

Potential Pitfalls:

  • Rogue applications : All applications that reside and benefit from the shared MUST adhere to the established guidelines for development. Non compliance affects all.
  • Overloading : Every infrastructure has its limits. The application portfolio cannot simply grow. Application sizing must be done and the infrastructure augmented if required.
  • Trouble shooting : Application logs, databases, concurrency, tool mix e.t.c tends to grow with co-deployment. Issues arise out of sheer size. This can be suitably mitigated by : log analysis tools, partitioning, tool standardization and avoiding shared data between threads.

Of course it may appear less painful to have dedicated infrastructure. It is not true because you end up addressing most of the above anyway, though maybe on a smaller scale 🙂