Presently, there is a battle of frameworks going on that compete for being the best “rightsizing” framework, tailored for building and running microservices as efficiently as possible. However, there is an older, yet proven concept available to run enterprise applications, that doesn’t apply the concept of rightsizing. On the contrary, it provides access to the full feature-rich specifications set of Jakarta EE (previously Java EE), without the need to right-size your enterprise applications.
The concept I’m referring to is that of the Application Server, commonly used in the Jakarta EE ecosystem. Because most developers are focusing on the rightsizing frameworks today, the concept of an application server is sometimes perceived to be outdated and not suitable for building (micro)services. This is not necessarily true, and the application server still has a part to play. Therefore I would like to address these perceptions by revisiting the concept of the application server and highlight its perks in building and running Java-based enterprise applications.
Application Server Characteristics
Currently, there are several application servers available that are built and made available by vendors for developers, often as open-source projects. Each of these application servers implements a certain version of the Jakarta EE specifications set. Application servers are used to run your Jakarta EE enterprise applications. This means that present-day application servers implement the specifications of Jakarta EE, not yet officially released but compatible with Java EE 8. Although the various application servers are likely to share some of the implementation details, they are also very different. If you compare the internals of application servers, you will see that they all apply their own approach of implementing the specifications and running the server. Some servers also provide some vendor-specific commercial features that should make using the application server for your purposes a more optimal experience.
Note that next to the Jakarta EE specifications, several application servers also implement the specifications from Eclipse MicroProfile. Like Jakarta EE, this is a specifications-based framework that is also being developed under the stewardship of the Eclipse Foundation. MicroProfile provides you, among other features, with the ability to run your application server in a scalable environment like a cloud. This is a fit for orchestrators and monitors because these are operating on the MicroProfile endpoints that are exposed for health checks and metrics.
Lean and tidy enterprise applications
If you look at the picture above, you can see that the application server runs on Java and exposes the various Jakarta EE, and possibly MicroProfile specifications to run Java-based enterprise applications. This means you can compile your enterprise applications against the matching specifications to make them compatible with the application server. This has the advantage that you don’t have to include the implementations of the specifications in your build artifacts (often in the form of a WAR (Web ARchive). That leads to enterprise applications that only contain your business logic, therefore often just a few kilobytes in size. Your enterprise application becomes essentially an extension of the application server itself.
To start developing Jakarta EE-based enterprise applications, you only have to create a Maven-based Java project that contains the following dependency:
<dependency> <groupId>javax</groupId> <artifactId>javaee-api</artifactId> <version>8.0</version> <scope>provided</scope> </dependency>
This is currently a legacy Java EE 8 dependency, but it will soon be replaced by a Jakarta EE counterpart. Since Jakarta EE and Java EE 8 are to remain compatible in regard to the specifications, the dependencies should be drop-in replacements.
In case your application server also supports MicroProfile, you can also include this dependency in your Maven project:
<dependency> <groupId>org.eclipse.microprofile</groupId> <artifactId>microprofile</artifactId> <version>2.2</version> <type>pom</type> </dependency>
These dependencies alone provide you with full and seamless access to the complete specification sets of Jakarta EE and MicroProfile in your project. If you start coding in your IDE, you should be able to access and compile against the Java classes, interfaces and annotations from the specifications that are exposed by the Maven dependencies.
Deploying your enterprise application
By using Maven’s Jakarta EE and MicroProfile dependencies for building enterprise applications, you can also easily build and deploy your application on your application server. Usually, you only have to tell Maven that you want your application built as a WAR (Web ARchive) which implicitly contains the internal file structure that is understood by the application server.
When you have chosen an application server to run your enterprise application on, you can download and unzip it before configuring your IDE to deploy your enterprise application onto the application server.
When you want to deploy your code on the application server, you can easily do so by using the (re)deploy option in your IDE. Maven will then (re)build your enterprise application and deploy it on the (running) application server. Since the WAR is usually only kilobytes in size, this should only take milliseconds. This should save you lots of development time and provide you with a pleasant development experience at the same time.
But that is not all. Using an application server should provide you with a machine that has been optimized by a vendor to handle high loads of request and data. As I explained earlier, the whole application server consists of several components. These are all tuned and optimized to run in harmony to let the application server run with optimal performance and stability on the available resources. Yes, this can take lots of RAM and CPU cycles, but you should ask yourself if this really is a problem. This phenomenon has not yet been solved by rightsizing frameworks either, and should be justified when it provides you with the desired performance and stability.
Another benefit is patching and upgrading the application server. Since the internals of the whole application server are available to you, details like what’s in it and how it works are perfectly transparent. You can use this to your advantage because it allows you to tune the application server to your needs, or replace parts of the application server when patches or upgrades made available by the vendor.
An application server is, of course, no silver bullet, but other concepts, including the “rightsizing” frameworks aren’t either. However, there is a place for application servers in the modern world.
The question you should ask yourself when you are considering using application servers is: do you really need microservices? I personally don’t think that is necessarily true. Sometimes you just want scalable services. And that’s an angle of approach where Jakarta EE and the appliance of application servers really shine through.
Due to the monolithic approach of building and running enterprise applications, an application server should relieve you of the architectural, infrastructural and operational overhead that you implicitly get when you build on a pure microservices-based architecture.
By using application servers, you can still build scalable enterprise applications, and with the addition of MicroProfile, these are also are a fit for scalable environments. And because an application server is tuned with performance, stability and ease of development in mind, it should be a solid base for your project when it aligns with Jakarta EE’s angle of approach in building present-day enterprise applications.