Why JeAS?

I've been saying for a while that the last thing the industry needs is a return the days of vendor lock-in or somehow resetting the clock on the past 40+ years of middleware and rediscovering it all again. That's why I believe we have to leverage what we've got. Yes, it needs to morph and evolve, but we should start using (reusing) existing investments. Furthermore, I believe that if the ideals behind Cloud are to be realised then they must start by tackling existing workloads.

This is why the application server (no formal definition in this article) is the right vehicle for applications. It doesn't matter whether you just consider this to be Tomcat or your favourite application server (JBoss, of course!), whatever is hosting your important applications today and which your developers are comfortable with, that's the basis of your own PaaS requirements. Therefore, that has to be the basis for PaaS wherever you may want to deploy in the future. But even today you often find that your application server may be providing more functionality than you need, at least initially. Just considering Java Enterprise Edition for a moment, that's one of the reasons behind the introduction of profiles (which always reminded me of the Core Services Framework Bluestone/HP pushed back in 2000, driven by my friend and co-author Jon Maron).

So this is where I come from when I mention Just Enough Application Server: when deploying into a PaaS you really need support from your underlying application server to ensure that just enough is deployed and no more. Ideally this should be done automatically as your appliance is generated, but static is OK too. Throw in a bit of autonomous monitoring and management in case things change on the fly (application and object migration is a distinct possibility, so the underlying infrastructure/application server needs to be able to cope), and you've got yourself one super sleek PaaS.