The developers’ world is a mixture of evolutions and reinventing the wheel. When I was doing EJBs 1.0 back in 1998, I was doing Micro Services. But I had to wait 2014 for someone to give it a name, and 2016 to see it officially arriving in Enterprise Java. So here we are: a Micro Profile has been announced for Enterprise Java.
What? A Micro Profile!
For those of you who have followed Java EE, you might remember that Java EE 6 arrived with this new definition of Profiles. The Web Profile was created side by side with Java EE 6. The idea of a profile is to have a subset of Java EE specifications while, optionally, adding new ones. That’s what makes the Web Profile “smaller” than Full Java EE.
Java EE came with the ability to create as many profiles as we needed. So here is the new Micro Profile! What is a the Micro Profile? As stated in the microprofile.io website, it’s :
Optimizing Enterprise Java for a microservices architecture
If we dig into the Micro Profile, we find the following specifications:
- JAX-RS : The API to expose and consume RESTful Web Services
- (Servlets because it’s needed in JAX-RS)
- JSon-P : For processing JSon (JSon-B will come along once final)
- CDI : CDI adds the interception (so it’s easy to add JTA with its @Transactional interceptor binding for example) and extensions (add your own extensions or check Delta Spike)
And because it’s built on top of Java SE, we can also have access to JAX-B and JAX-P when dealing with XML instead of JSon. And that’s it! No more specifications for now! We wanted to make it micro. Bean Validation could come along in the next version of the Micro Profile or/and Concurrency.
The Micro Profile Didn’t Come out of the Blue
As I said, the idea of Micro Service in Java EE comes from its genesis: the EJB component model was a Micro component: just embed the needed business code, as small as you can, package it as a unit in a single jar, link it with other components/EJBs via RMI/IIOP and the container will look after the rest. The EJB model was micro… not the container ;o)
But since then, Java EE containers have evolved. They have been lighter, smaller, faster… so it was time to have a Micro Profile: micro components running in a micro container.
And remember that Java EE is modular by design: Java EE is just a bunch of specifications, each evolving at their own pace. Just use the ones you need.
What’s next?
The Micro Profile just got announced. There is still a lot of work to be done. First of all, it has to be implemented by the vendors (I’m sure we can expect a WildFly, Websphere Liberty, Payara or TomEE Micro Profile very soon). Then it will have to be standardized by the JCP. Being just a profile, this can be quick. And then add more functionalities and APIs to this profile. We might think of a BootStrap API allowing the container to boot and execute the deployed Micro Services. And I’m sure a few extra specifications, APIs and patterns will be added up in future versions.
To build the future of the Micro Profile, make sure to answer the survey and tell us if you are more interested in Startup time, Disk space, Memory, Uber-jar, Metrics, Circuit Breakers, Bulkheads, Reactive or Client-side load balancing.
So it’s up to you now. Help us optimize Enterprise Java for a microservices architecture by joining the MicroProfile Google Group.
Conclusion
If you already have a Java EE expertise. If you know JAX-RS and CDI by heart. If you need micro services in your architecture, jump into the Micro Profile. You will be able to quickly develop Micro Services re-using your Java EE expertise.
I’ll be writing a few technical blogs on how to develop Micro Services in Java EE. Stay tuned.
This sounds promising! Java EE isn’t “about” hard-to-configure application servers; it’s about the APIs. We can evolve the deployment environment without losing the APIs, and this sounds like a good step in that direction.
Light weight JEE containers were long awaited. Much excited to see Micro Profile containers are on there way.