MicroProfile: 5 Things You Need to Know

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?

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.

The MicroProfile 1.0 specification includes a subset of the 30+ 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 number of APIs required to build a microservice.

MicroProfile 1.2 was released in September 2017 with quite a few amazing features, including Configuration 1.1, Fault Tolerance, JWT, Metrics, and Health Check. It is expected that version 2.0 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 stopped Java Enterprise technologies from being used to develop microservices. In fact, a lot of effort has already gone into 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, a collaboration was entered into among vendors and user groups with the guiding force of doing 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 community's 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. Sandbox 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 garner 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 suite 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 Heavyweight

The traditional perception of the Enterprise Edition of Java is that it is heavyweight, 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 developer resources page, an architectural conference application keycode 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 servers.

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 startup time extremely short. These numbers give any other Java EE framework a run for its money.

Note: Each MicroProfile instance was launched on a different laptop machine (Windows or Mac) with distinct performance characteristics, so these results should not be considered a scientific benchmark. What you should take away from this table is that all vendors performed excellently regardless of the operating system and hardware and that startup times are very short. Just imagine how much better the performance would be on a fully optimised cloud infrastructure.

*KumuluzEE added post presentation and shows metrics recorded on a MacBook Pro 15 2014 notebook.

Each vendor’s implementation takes advantage 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 optimized 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 are demonstrated to work.

Attempting to innovate within a standards organization is rife with pitfalls 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.

But 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 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 catches 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.

Links You Want to Click

• Eclipse MicroProfile Presentations
• Eclipse MicroProfile Articles
• Eclipse MicroProfile 1.1 PDF
• Kumuluzee Microprofile Showcase Application

Further Reading

I have published more articles about Java EE. Here is a short list of topics that might interest you:

• Java EE: Past, Present, and Future
• Context and Dependency Injection (CDI)
• Enterprise Java Beans (EJB)
• JSP, JSP and Expression Language
• RESTful web services
• Java Persistence API Introduction (JPA)
• What are JAX-RS annotations?
• What is @Context annotation used for?
• JAX-RS @Consumes and @Produces annotations
• Bean validation failure management