When I comment in mailing lists that I am implementing a registration module for my application, hundreds of other developers comment they are coding exactly the same functionality in their projects - an indicator that something is missing in the Java EE Universe.

Registration is just an example, there are many others like notification, content repository management, etc. If you look for solutions to such problems you will find a lot of frameworks and products supplying solutions for separated parts of a common enterprise application. The point is, you can't can adopt one of this features without adopting the whole framework surrounding the feature and usually you can't or you dont'n want to do that. It is senseless to expect such specialized features included in the container specification, but at same time we should recognize that today it takes too long from the concept of a feature to production in a standard Java EE Server, and it is not a problem of the server, it is something else, something missing.

The game of the monolith

In my opinion, what is missed is a set of standardized components on top of which the frameworks will assemble its complete solutions. For example, think about the popular JBoss Seam, a beautiful framework isn't it? But now think on how to use just the authentication feature of JBoss in other framework, or the REST support or even the AJAX component of Seam. Is it possible to get advantage of such implementations in other frameworks like JSF without a painful migration path? I don't think so. That's the point: while JSF, Seam and other frameworks are doing a great job in offering complete solutions based on Java EE containers, each of these products has an independent set of features, and that features are non-compatible with the features of other products. More: the vendors behind these products need to code, test and guarantee somehow that each small feature is robust and good for your problem, resulting in a non-standardized market, full of sales speeches and religious arguments - a mess. A profitable mess I would say, but much less profitable than it would be. As far I see today, we have a Java EE container and in front of it we have a collection of frameworks incompatible whithin each other - a collection of monoliths.

A good analogy is perhaps the car industry, where the engine of your car is built with sharable components. There is no such thing like a motor full of pieces incompatible with any other motors in the world. When the companies design cars, they check the market to see what components are available and then design the car (the solution) based on that components. The standardization of such components is very complex but at least it provides the guarantees we need to risk our lives inside the cars. And if you need or want to change a some part of the motor of your car, you will get surprised with how many options you have in a good car parts supplier - all compatible with the components specification of your car.

Application level components

If you try to implement a basic Java EE feature by yourself, let's say the registration use case, it will cost you a lot of effort. Just try that: open your IDE and build a registration system without using any framework. It is easy to do, specially after Java EE 6, but write down the time you need to get it available on the screen. And include the amount of time you need to configure and deploy the solution - a simple login/logout/registration use case. Now, make another experiment: install Hudson and then install some plugins. How long it takes since you downloaded Hudson and get your plugins available for testing? Minutes, right? Where is the diference?

Obviously Hudson is a web application and not a generic server, but the key point is: Hudson provides more than just the infra-structure and an extensible API, it provides application level components. So, the Hudson application is running on your browser and if you want something else you just click a few buttons and that features will become fully integrated with the web application. That's what I dream for the next generations of Java EE containers, not only a robust and efficient solutions platform with standard connectors and interfaces, but mainly a set of components I can quickly add to any application - independent from the brand of the framework my application is based on.

* Everytime I think about it, I recall that such feature should be provided by independent vendors and should be away from any java EE specification. And after few minutes I also recall that such abstraction and simplicity leads the today market to a lack of alternatives other than monoliths. It is an open tought, I hope that one day I don't need to rethink about this anymore.. the day where my Glassfish will have a pane full of fancy features, like Twitter notification, registration use case out of the box, GMail integration and many others plugins. I am pretty convinced that a server offering such goodies will dominate the market as quick as Hudson did few years ago.