ARTICLE
Java Microservices and JeAS
From Enterprise Java Microservices by Ken Finnigan
__________________________________________________________________
Save 37% on Enterprise Java Microservices. Just enter code fccfinnigan into the discount code box at checkout at manning.com.
__________________________________________________________________
Just enough Application Server (JeAS) is a term has been used on occasion over the years, but usually in relation to customizing a full application server by removing functionality manually. Only with the popularity of microservices has JeAS become crucial for Enterprise Java. This article talks about what JeAS means and some of its benefits.
What does JeAS mean?
Say we need to develop a microservice that interacts with an Enterprise Information System (EIS), such as SAP, to retrieve HR information on employees. Imagine that for our microservice we’ve chosen to use JAX-RS, CDI, and JCA. If we were to develop such a microservice for deployment onto a typical Java EE Application Server, it’d most likely be done with the Full Profile.
As we can see, there are lots of specifications within the Full Profile that we’re not using, but they’re still there even though we don’t require them.
Maybe we can use a different Java EE Profile? Let’s try the Web Profile and see how that works:
That results in less unused specifications, but now we have the problem that JCA isn’t part of the Application Server Profile anymore. We can still add an implementation of JCA to our microservice as part of the deployment, but it’s no longer automatically part of the stack and may require additional configuration that we didn’t need with the Full Profile. What’s the answer? Can Just enough Application Server help?
What exactly is Just enough Application Server? In a nutshell, it inverts the relationship between an application server and an application, ensuring that you only package the parts of an application server that your application requires. In the case of our microservice example above, we know that we need JCA and we’d choose the Full Profile of an Application Server. We do that knowing there’s large parts of that Application Server that our application will never use.
Java EE Profiles
Since Java EE 6, We’ve had two profiles available for developers to choose as their application server. While you may not be familiar with these profiles, below you will find an overview of which specification the Full Profile and Web Profile contain.
Many application servers provide the flexibility to slim down their distribution by removing components and their associated configuration. I’ve worked with many customers in the past that have taken this approach. It requires a trial and error approach to find the correct combination that still ensures that the application server functions. In some cases there may even be a component that you’d like to remove but can’t, usually because that component is a key part of the application server. Customizing an application server for many different applications quickly devolves into a complex set of differing configurations that need to be managed and maintained. In these situations, developers typically prefer to simplify their lives and choose the Full Profile as opposed to spending time trying to slim the application server, thereby accepting the extra overhead that comes with not using all components of the application server.
Over the years, several application servers, such as WildFly, have worked to reduce the footprint of components that aren’t being used. Though the dependencies that are required for various components are still on the classpath, the application server is clever enough not to load those classes into memory if the deployed applications don’t require them. This can only go part way, unfortunately, as there are many components that are core to the functioning of the application server, no matter what an application might require.
Where does JeAS fit in with our microservices architecture?
As you can see, the focus of JeAS is on the runtime needed for a microservice. A JeAS runtime aims to provide a whittled down Application Server for microservices, but how its packaged can differ between different
implementations. Which JeAS runtime is chosen can impact the packaging available to a microservice. Though the driving factor should always be about what’s supported by a JeAS runtime and not how it needs to be packaged. For instance, if a JeAS runtime doesn’t support being built as an uber jar, containing an application and its required runtime, then a different packaging method must be used. JeAS runtimes provide a simple and manageable way to only include the parts of an application server that our application requires.
Thanks for reading.
For more, check out the whole book on liveBook here and see this Slideshare Presentation.
Originally published at freecontent.manning.com.
