Eclipse MicroProfile: 5 Things You Need to Know

Alex TheedomSeptember 19th, 2017Last Updated: September 19th, 2017

0 48 8 minutes read

Optimising Enterprise Java for Microservice Architecture

The Eclipse MicroProfile initiative was launched at JavaOne 2016, the brainchild of server vendors and Java user groups, in order to address the shortcomings in the Enterprise Java microservices space. The pace of Java EE releases slowed to a point where it was unable to meet the challenges of the rapidly advancing microservice trend. MicroProfile addresses this by brings together individuals, vendors and community organizations in open collaboration to deliver microservices to the EE eco-system.

What is Eclipse MicroProfile?

The MicroProfile specifies a collection of Java EE APIs and technologies which together form a core baseline microservice that aims to deliver application portability across multiple runtimes.

MicroProfile 1.0 specification includes a subset of the 30 plus Java Enterprise specifications and they are: JAX-RS 2.0 for RESTful endpoints, CDI 1.1 for extensions and dependency injection and JSON-P 1.0 for processing JSON messages. Why just these three? It’s because this represents the least amount of APIs required to build a microservice.

It is expected that version 2.0 will be far more extensive and is slated to include a subset of features from the backlog which are: configuration, security via JSON Web Tokens (JWT), health checks, JSON-Binding, monitoring, OpenTracing and fault tolerance. Plus it will align all APIs to Java EE 8.

A number of respected server vendors provide runtimes. Those who support the MicroProfile architecture are: WebSphere Liberty from IBM, TomEE from Tomitribe, Payara, RedHat’s WildFly Swarm and KumuluzEE.

Community support comes from the London Java Community and SOUJava plus numerous individuals who give their time and effort.

Motivations for Eclipse MicroProfile

Java EE’s maturity has resulted in a slowing release cadence which has become too slow for the microservice community. However this has not stop Java Enterprise technologies from being used to develop microservices, in fact, a lot of efforts has already gone on microservices in Java EE.

The space was becoming fragmented with each vendor implementing their own opinion about the right way to do microservices. It was clear that if cohesion was not sought then vendor fragmentation was the inevitable consequence. So collaboration was entered into among vendors and user groups with the guiding force to do microservices better.

With the Java EE full profile becoming so large, over 30 APIs at the last count, it doesn’t seem right to include all those specifications when you are building something that you call ‘micro’, especially when you are not going to use the vast majority of those APIs. A slimmer and better solution had to be found.

Objectives

Out of these motivating forces came four overriding objectives that all who participate in the open source project seek to pursue. Those objectives can be outlined as follows:

Avoid fragmentation among vendors and implementers as a way to address the need for a coherent approach to the microservice space. This results in microservice interoperability between server vendors through a common strategy to microservices.

Build quickly through lazy consensus to allow rapid development and iterations. This leads to a high-frequency release cadence, satisfying the communities need for a quick turn-around.

To create more open source technologies in the Java EE space through the framework of the Eclipse organization. This allows the organization to act as the specification lead when those technologies are moved to a JSR format.

And the ultimate goal is to supply the Java Community Process (JCP) with specification requests (JSR) backed up by judicious approaches and implementations that developers and businesses can rely upon and actually want.

MicroProfile attempts to understand microservices in terms of Java EE technologies and is not an attempt to compete with Oracle but to innovate around the edges and to feedback to the JSR.

1. Sand-box Approach to Open Contribution

Eclipse MicroProfile has a unique approach to open contribution that allows an immediate start via the MicroProfile sandbox repository. You simply fork the sandbox repository, create a distinct sub-directory, code your idea and submit as many pull requests as you need to probe the concepts behind your proposal.

Anyone can contribute in this way, even if not yet active in the community. This approach presents a zero bar to entry and allows the capture of ideas for anyone who has the inclination to contribute.

Progressing your idea is just as frictionless. Start a new thread on the community forum announcing your idea and allow a few days (72 hours) for it to garnish feedback. Consider and respond to feedback, making updates as appropriate and providing justification when feedback is not applicable. Once acceptance of your idea is granted, via lazy consensus, your contribution is migrated to its own repository where work on the specification, APIs and test suit commences.

If you don’t want to work alone, you can solicit support from the community by expressing your idea openly on the Google group. This is where all discussions occur. You can find others who share the same interest and are willing to collaborate with you on your idea.

2. Challenges Perception that Java EE is Heavy Weight

The traditional perception of the Enterprise Edition of Java is that it is heavy weight, cumbersome and slow to deploy and this was true for much of its earlier life, but that perception is being successfully challenged, thanks to the Eclipse MicroProfile effort.

On the MicroProfile Eclipse developer resources page, an architectural conference application key code sample can be found that you can use to test for yourselves the lightweight nature of a MicroProfile Java EE application. If you don’t have time, then watch this excellent presentation.

The key code sample consists of four microservices and a front-end application. In the presentation, each microservice was developed with the MicroProfile architecture and deployed on one of the four participating vendor’s server.

A maven plugin compiles the application as a WAR and packages it into a JAR with the server runtime. It is launched via the command line using the java -jar command. Examine the table below and as you can see the JAR size is minimal and the start up time extremely short. These numbers give any other Java EE framework a run for its money.

Vendor	Microservice	JAR size/Mb	Start Up Time/Secs
WebSphere Liberty	Session Voting	35	7
WildFly Swarm	Session	65	6
Payara	Session Schedule	33	5
TomEE	Speaker	35	3

Each vendor’s implementation takes advantages of the server’s architecture to optimise the deployment. For example; IBM’s WebSphere Liberty uses ‘features’ to select the Java EE technology required and packages just what the application needs. WildFly Swarm uses ‘fractions’ to ‘right size’ the service ensuring that only the required APIs are included in the deployment.

The common feature across all vendors is the optimised way that the deployment is packaged. Just enough code is included to make it work resulting in an uber JAR of minimal size.

3. High Cadence Release Philosophy

The Java EE release cycle typically takes a few years between versions, which, for a standards-driven ecosystem, is perfectly correct. Standards organizations are not meant to innovate, they exist to standardize. They collect the proven ideas once they have been fleshed out and demonstrated to work.

Attempting to innovate within a standards organization is thwart with pit falls and is proven to be disastrous. CMP (container managed persistence) is an example of what happens when a committee guesses what people want and gets it wrong.

The world of microservices is changing very fast and a multi-year release cycle is just too long for the community. MicroProfile’s goal is to improve on this by shortening cycles and making them more iterative. The idea is to try out suggestions, see what works and what doesn’t, and do it in an ‘iterate quickly, fail fast’ process. The bad ideas are flushed out quickly, leaving just the good ones. As technologies become proven they can be submitted to the JCP for consideration in a future JSR.

The shortened release cycle is designed to deliver something and frequently, even if it is just one idea. This is considered more preferable than delivering a lot of ideas, two years down the line.

MicroProfile’s currently planned releases are publicly announced on the Eclipse MicroProfile site.

4. Complete Transparency at all Stages

A guiding philosophy that has proven to result in solutions that the community really wants is that of total transparency. This is the approach that Eclipse MicroProfile has taken. All discussions are conducted in the open on the Google group which is where all discussions start and flourish and anyone can jump in with a comment or a new idea.

Bi-weekly Google Hangouts are an integral part of the process and all are invited to join the meetings. They are announced ahead of time on the community forum and meeting notes are published in a Google doc for all to see.

Contributors are acknowledged on the Eclipse Project site where it is transparent who is the greatest individual and organizational contributors and which company members have been most active.

5. CDI Centric Programming Model

The Context and Dependency Injection specification is one of the most powerful and feature rich specifications in the Java EE ecosystem and is often leveraged by other APIs.

Two of its most powerful features are interceptors and observers. Interceptors perform cross-cutting tasks that are orthogonal to business logic such as auditing, logging, and security. An essential ability for all kinds of microservice attributes developers require.

The baked in event notification model implements the observer pattern to provide a powerful and lightweight event notification system that can be leveraged system-wide.

On top of these features, you get the expected decoupling of server and client (the essence of dependency injection) plus the entire CDI specification including the ability to define a bean’s lifecycle, typesafe injection, scopes, producer methods, qualifiers and a complete service provider interface (SPI) that allows third-party integration.

It is clear to see why this API was chosen as a core dependency for the baseline Java EE microservice.

How to Get Involved?

Getting involved could not be simpler. Pop over to the Google Groups, pick a thread that tweaks your interest and start reading and commenting. Do like to talk? Then jump on one of the bi-weekly Google Hangouts and express yourself. If you have an idea for a feature that’s not being discussed then why not start a thread and get some feedback. If you like to jump in at the deep end then fork the microprofile-sandbox repository and get coding. There is no way that you can’t get involved.