Skip to main content

Dismantling monoliths

Posted by felipegaucho on November 24, 2009 at 4:44 AM PST

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.

src="http://blog.antiquetrader.com/blog/content/binary/eBay%20Monolith.jpg" />

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 href="http://wiki.glassfish.java.net/Wiki.jsp?page=Security">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.

Related Topics >>

Comments

Update Center...

That would be the promise of the Update Center repositories in GFv3... Talk with Alexis and let's get serious to populate it... - eduard/o