How Microservices perform with Java EE
Microservices and Java EE
The Java EE 8 set of specifications allows the creation of monolithic applications with ease. The main benefit of being a Java EE developer is that you don’t have to worry about handling technical concerns like network handling, transaction management or a resource’s lifecycle when the specific container service does that for you. This simplifies the developers' work allowing them to focus on business concerns instead.
In the case of Java EE, a monolithic application’s example could be an e-commerce application with the following characteristics:
- Is structured as an EAR file with multiple modules (linked to the tiers of the monolith):
- An EJB-module that handles integration aspects (SOAP web services, Message handling, etc.)
- Another EJB-module with a common persistence layer to access data stores with traditional means: JPA, JDBC, JCA, etc.
- Multiple WAR modules that correspond to the web applications that will handle the user interfaces. Let’s say this application has 3 WAR modules: One for an administrative interface, another to be used by providers or sellers and another for the use of buyers.
- Since the application’s built with Java EE, most of the code is written in Java.
- For the WAR modules, the user interfaces would be probably coded using JSF or JSP in conjunction with JavaScript. This would ensure consistency since the entire application is structured with the same web technology.
Sounds complex? Yes. The previous scenario was a common occurrence in earlier Java EE days, but nowadays, with tools like Maven or OSGi, modularizing Java EE application has simplified the development of monoliths on Java EE, meaning that your entire application can be deployed in a single WAR file. However, if you would like to implement this e-commerce application as a set of microservices, a simple WAR will not be enough.
There are no technology restrictions that prevent you to create microservices using the Java EE APIs via an application server like GlassFish (and Payara Server by extension). However, there are some considerations to have in mind:
- Since each microservice must be a complete standalone deployable unit, this means that each service should be composed of an application deployed within its own Java EE server. So if, for example, an application is composed of 10 micro services, then you would need 10 separate installations of an application server to host each service.
- Most application servers aren’t exactly lightweight, considering their complexity and the features they offer; e.g. Payara Server’s 5 Full Profile currently weights around 140Mb.
- Although most application servers have greatly reduced their startup times, there’s some overhead since the application server needs to prepare and handle many components that won’t be needed for a specific service. For example, when booting a GlassFish domain, the server needs to initialize its messaging subsystem, and this is something most services won’t need unless it’s strictly necessary.
Related blog:
