Felipe Gaúcho works as senior software engineer at Netcetera AG in Switzerland. He is a well known Brazilian JUG leader and open-source evangelist. Felipe works with Java since its early versions and has plans to keep that Java tradition as it is. When he is not coding, he prefers to listen reggae and travel around with his lovely wife Alena and his son Rodrigo. Felipe is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. View Full User Profile

Dismantling monoliths

  • submit to reddit

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.


Published at DZone with permission of Felipe Gaúcho, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


William Draï replied on Tue, 2009/11/24 - 12:10pm

This is exactly the point of CDI (JSR 299, ex Web beans) in JEE6, and the idea behind Seam 3. Instead of bringing a whole application stack, it will provide a set of CDI 'portable extensions'. So you will be able to take the Seam 3 security extension only and maybe mix it with extensions from other vendors or even your own extensions to build your application. If CDI is correctly marketed to the community (which is not the case for now but the 1.0 RI has been released for only a few weeks), it could completely change the way we build JEE apps.

Erin Garlock replied on Tue, 2009/11/24 - 1:30pm

While the idea of a generic registration module is nice in theory, what does it do?  Accept user input?  What data?  Is it three fields or the entire list of possible fields in a user credit history check or perhaps from the Bureau of Motor Vehicles?  Does it confirm password and retyped-password match?  What if I'm using Two Factor Authentication and password is irrelevent? etc. etc. 

The problem isn't the use-case.  The real problem is that "Registration Module" is more akin to design-pattern (or perhaps an interface in OOD terms) than a framework, just as there is no off the shelf "Vehicle" framework (e.g. car, train, boat, plane).  Also, try the same exercise with any classic design pattern, say a Factory pattern for instance.  There isn't one "Factory" jar out there you can buy, because it isn't a deterministic problem.  You could try and parameterize all your inputs and use dependency injection and other technical black magic to try and create a framework, but I'd be willing to bet that there wouldn't be much that would be delivered in the final product.  I also feel that this is venturing into the same area of discussion as the recent Javalobby article by Eyal Golan; The Abuse of Utility Creational Methods

The "Registration Module" interface is a mechanism by which you can frame all your questions and possibly define some common behaviours (e.g. register, unregister, suspend) but other than that everything else is domain specific.


Luiz Decaro replied on Tue, 2009/11/24 - 2:22pm

I agree to Erin. I just add that a "template" for all non deterministic but most recurrent problems in my opinion is a domain pattern that should be available so that small/medium applications may benefit from a ready solution.

Felipe Gaúcho replied on Wed, 2009/11/25 - 3:51am

@Erin Garlock: good point, and I agree partially. If you check how JAAS is implemented by traditional Java EE applications, it is always the same workflow, also because there is the default JSP tags you should use if you want to rely on the "container based authentication" (j_username & j_password). So, every web application out there uses this pair of field names to pass to the container the authentication values. Authorization in the other side is a bit more complex, I agree that authorization would demand a set of new standard mechanisms before to be made generic. You have a good point about the domain specific solutions, but I still believe we can have a better support from the containers. @wdrai: it is very nice to know Seam 3 will provide such facilities, I will check it out asap. You are right, if Seam 3 delivery an easy of use set of components we will review the way we design EE software .. for better ;)

Stevi Deter replied on Mon, 2009/11/30 - 1:38pm

An interesting example to look at is the .NET Framework's Membership Provider. It provides a default implementation, down to creating a database for you, in a way that allows you fine control in overriding what you want to.

It being .NET, there's also a set of default controls for the UI that hook into your Membership implementation. 

I've used it pretty successfully in a couple of .NET applications, even including some pretty sophisticated authorization logic that "just worked" if I followed the membership model.

The new ASP.NET MVC framework actually includes scaffolding to build out an initial application that includes the default membership provider and login already wired in. 

While JAAS can be very nice, it isn't quite up to the ease of use, especially as already noted in the authorization implementation. 

One of the few areas where I'll admit that the .NET world may have it better than the Java world!

Ming Shing replied on Thu, 2010/11/25 - 5:01am

You could try and parameterize all your inputs and use annex bang and added abstruse atramentous abracadabra to try and actualize a framework, pass4sure 000-004, pass4sure 000-006, pass4sure 000-007 but I'd be accommodating to bet that there wouldn't be abundant that would be delivered in the final product.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.