In these days there is so much noise about Microservices and scalable architectures. We read about Verticals, Multi Threading and Fat Jars. I ask myself what is all that good for? Didn’t we have an architecture which is still providing similar concepts – called the Java Enterprise Edition?
What is the idea behind Java EE? The main job of a Java Enterprise Server is to server resources to your application. This means a Java EE application sever provides resources like Database connections and security realms. As a Java EE developer you have not to think about how this is done. You just lookup – or in newer days inject – a JNDI resource. This resource can be a database pool, a Mail Session, a LDAP connection or something else. The application sever is responsible about managing, pooling and scaling of these resources. Why not trust in that concept?
There may be some cases where big companies are running there business applications in an awful architecture. Sometimes you can see a productive environment with many tomcat instances, each running a single piece of code from the business domain. For example there are several war artefacts, one for the customer service, one for the order management and another tomcat is serving the offer management. And each module is running in a single servlet bringing its own JDBC connector and security with hard coded configuration. I think you can agree with me that this is nonsense and bad practice.
So why not trusting in Java EE? If you are using this architecture in the right way you can deploy all 3 war modules from the scenario above into one application server. Each war module lookup or injects the same JDNI database resource. The application server is responsible to manage JDBC connections. And the important part here is that these JDBC connections are running in several separate threads outside of your servlet. So why not using this facilitation?
The other part we should think about is the business logic. If you put all logic into one servlet the code grows up with the time. This can not be managed well and took a lot of resources on your web server (each time the servlet is called). Ah! That’s it – we need more verticals, microservices and servers to bind each part of our business logic into a separate thread. Looks so, but again we missed one of the core concepts of Java EE – EJBs. EJBs are by far the most misunderstood concept of Java EE. The reason my be historically, because EJBs where at the beginning awful complex. But today EJBs are perfectly easy. You can put as much as possible of your business logic into several stateless session EJBs and the application server is doing the rest. EJBs are pooled in a container. This means they are running in separate threads, are pooled by the server and are transactional. You can’t implement such a concept easily by yourself. And at least Java EE application servers can also be clustered. So there is enough playground also to set-up large server environments – if you like…
Conclusion
Java EE provides an architecture that solves the main problems of modern web applications. Although Java EE is several years old, there is not reason not to trust in this architecture. In my eyes it is no wasted time to seriously deal with this technology and consider all the ideas and concepts. Thus, Java EE at the end may be the best architecture to build the big brother of Microservices – Self-Contained Systems.
Please let me know if you can give me arguments why I should rebuild my business application from a Java EE platform into a new architecture style like Vert.x, Wildfly Swarm or something else?