Microservices for Java EE/Jakarta EE Developers

With this article, our intention is to illustrate that microservices are a valid option for Java/Jakarta EE developers with the help of Payara.

Nowadays, the concept of microservices is more than a simple novelty. With the advent of DevOps and the boom of container technologies and deployment automation tools, microservices are changing the way developers structure their applications. With this article, our intention is to illustrate that microservices are a valid option for Java/Jakarta EE developers and how Payara Micro is a robust platform to reach that goal. 

Advantages of Microservices  

The main purpose of a microservice architecture is to break down an application into smaller standalone components that are easier to handle, deploy, scale and maintain in the long term. Sounds familiar? Yes, this is something that many developers have been doing since a long time ago! Encapsulation, cohesion and a good understanding of service-oriented architectures have helped them apply this “divide and conquer” strategy to software architecture for many years and will do so in the future as well. 

So, what’s the advantage of a microservice architecture, then? Microservices are better understood when compared with their traditional counterparts: monolithic applications. Monolithic applications, or monoliths, are usually big enterprise applications structured into a single deployable package. If you want to introduce a new component or update an existing one, the entire monolith must be updated at once. This is the way enterprise applications were usually developed, focusing on the concept of tiers (UI, middleware-services, persistence, data) and the segregation of concerns across these tiers. 

So, while a monolith is just a normal application developed with traditional means, the microservice architecture approach would be to break down such an application into its separate component units (or just services), so that each unit would fulfill the following criteria: 

• Have a small footprint 
• Be cohesive, e.g. focus on a single feature or business case 
• Expose an interface to be used by other services of the same architecture or other external services
• Be independently managed, so that it can be coded, tested and deployed faster
• Be responsible for handling its own data
• Be isolated from other services, so no direct dependencies are needed

Monoliths vs. Microservices 

So, does that mean that microservices should be used instead of the traditional monolith in all cases? Not necessarily. Microservices not only define a new architectural style, but also require that development teams build applications in a different manner. 

There are also some advantages and disadvantages regarding when to use a monolith and when to use microservices: (Considered advantages are green, disadvantages are red, orange is for variable benefits depending on the software requirements or the organization’s environment.) 

MonolithsMicroservicesCost of changes across all tiers is high. A change of a single feature means a redeployment of the whole unit. Changes are easier to implement and not costly as they are targeted to specific services only. All components belong to a single unit, there’s no communication overhead. Remote calls are needed for communication between services, so this overhead factors in the performance of the overall application. The entire development team must be familiarized with the design and composition of the entire application. Each service can be handled by a separate team, so this favors separation of concerns and responsibilities. Developed with a technological stack in mind, using one or two languages of choice. A main language/framework is chosen to govern the software architecture. Each service can be developed using a different framework based on its requirements and needs. Standards are discarded in favor of improving each service with the right tools.  Easier to deploy. The complexity of deployment increases with the number of services and the communication routes between them. Clustering can be as easy or difficult depending on all the features implemented across the monolith. Since each micro-service is small, clustering is generally easy, with scalability being a primary drive. Failure of a component can cause the entire application to fail and hinder the user experience. Failure of a service will only bring that specific service down, leaving other services untouched.  There’s a focus on tiers and integration across tiers.  There’s a focus on business needs and communication concerns between teams.  

Microservices can help an organization develop their applications in such structured way. But sometimes, when applications are not critical to their business, or their quality attributes (performance, availability, scalability, security, etc.) are not specifically demanding, the traditional monolithic approach is more than enough. 

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.

microservices java ee microservice architecture microprofile

What is OpenJDK? OpenJDk or Open Java Development Kit is a free, open-source framework of the Java Platform, Standard Edition (or Java SE).

Companies need to be thinking long-term before even starting a software development project. These needs are solved at the level of architecture: business owners want to assure agility, scalability, and performance.

The MicroProfile project defines a programming model for developing microservice applications in an Enterprise Java environment.

In this article, take a look at the service mesh in the microservices world. The software industry has come a long journey and throughout this journey, Software Architecture has evolved a lot. Starting with 1-tier (Single-node), 2-tier (Client/ Server), 3-tier, and Distributed are some of the Software Architectural patterns we saw in this journey.

In this short video I demonstrate how to use MicroProfile OpenTracing with Jaeger in combination with Payara Micro.