The Eclipse Foundation recently released MicroProfile version 1.2 featuring four new APIs:
The Health Check API determines if a computing node is on the brink of termination or shutdown and will replace that node with a fresh, healthy instance. It includes a built-in class annotation, @Health, and the class must be implement the HealthCheck interface and override the call() method.
The Health Metrics API provides well-known monitoring endpoints and metrics for each computing process. It introduces the following built-in annotations that may be added to any class or method:
@Counted- marks a method, constructor, or type as a counter.@Gauge- marks a method as a gauge.@Metered- marks a method or constructor as metered and tracks how frequently they are called.@Timed- marks a method or constructor of an annotated object as timed and tracks how long invocations of those annotated objects take to complete.@Metric- requests that a metric should be injected or registered.
The Fault Tolerance API introduces new policies with corresponding annotations that may be added to any class or method:
@Timeout- defines a required timeout period.@Retry- defines criteria for when a retry is necessary.@Fallback- provides an alternative solution for a failed execution.@Bulkhead- prevents a systems overload or an indefinite wait.@CircuitBreaker- isolates a failure allowing the rest of the system to function.
The JSON Web Token (JWT) Propagation API is a token-based authentication/authorization system that includes a set of standards for interoperability.
The Config 1.1 API, designed to inject configuration values at runtime, has been updated for bug fixes and to add critical missing features for enhanced work with the specification.
As per the website, additional benefits include:
- Offer more functionality for implementing Enterprise Java microservices
- Interoperability across different MicroProfile implementations provides users the freedom to select one or combine many MicroProfile implementations in an application
- A thorough set of artifacts for each API, including a Test Compatibility Kit (TCK), Javadoc, PDF document, API Maven artifact coordinates, Git tag, and downloads (spec and source code)
The MicroProfile roadmap includes plans for upcoming versions. MicroProfile 1.3, scheduled for release on December 15, 2017, is expected to include these new APIs:
- Open Tracing 1.0
- A distributed tracing system (such as Zipkin) among microservices for troubleshooting latency issues.
- Open API 1.0
- A framework of API developer tools that adhere to the Open API Specification. SmartBear Software, makers of the Swagger Open API tool, recently joined the Eclipse MicroProfile Group.
- TypeSafe REST Client 1.0
- A type safe way of consuming REST services
MicroProfile 2.0, scheduled for release on March 31, 2018, is expected to include upgrades to these Java EE 8 APIs:
- JSON-B 1.0
- JSON-P 1.1
- CDI 2.0
- JAX-RS 2.1
MicroProfile has been committed to adopting microservices in Java since its inception in September 2016. More details on this latest version can be found in the MicroProfile 1.2 specification.
Emily Jiang, CDI and MicroProfile development lead at IBM, and Michael Croft, Java middleware consultant at Payara, spoke to InfoQ about this latest release.
InfoQ: What are your thoughts on the new EE4J project?
Emily Jiang: The new EE4J project is a fantastic open source initiative. It benefits all communities, including those to whom the Java EE TCK was not available under acceptable licensing terms. The project strives to be nimble, flexible, open, and compatible, which will no doubt benefit Java developers. Hopefully, the release cadence will be very much improved, ending the four- or five-year Java EE release cycle era. The opening up of TCKs benefits all application servers, especially the ones that have not bothered to certify themselves against the TCKs due to the expense of the licensing.
I am hoping to see more and more Java container and framework communities coming together to collaborate in the open and public playground, to talk openly with Java developers. Every developer should be able to contribute to the project, raise and discuss the issues. I'm very positive towards the new EE4J projects and look forward to contributing to them.
Michael Croft: Personally, I'm very excited by it. I think what we've seen over the past year or so in the industry in general is the strength of open source software, particularly when big players like Oracle and IBM are donating products to the community. In the case of JSF, some of the expert group members there had already raised the idea of driving that spec forward as a community effort. With EE4J, the barrier to entry for people to get involved has gotten significantly lower and we're already seeing a strong response in the mailing list and in GitHub.
InfoQ: What role do you see MicroProfile play in terms of contributions to EE4J?
Jiang: MicroProfile has been around for a year. Within one year, it has successfully released MicroProfile 1.0 (CDI 1.2, JAX-RS 2.0, JSON-P 1.0), MicroProfile 1.1 (Config 1.0) and MicroProfile 1.2 (Config 1.1, Fault Tolerance 1.0, Health 1.0, Metrics 1.0 and JWT 1.0). The released specifications are long-wanted features in Java EE for microservice development. For instance, Config JSR was proposed more than 10 years ago in the JCP, but it was never being accepted despite two more attempts later on.
As a contrast, MicroProfile Config only took a few months to be released to the public and we received great feedback. The MicroProfile community is very innovative and purely developer-driven. Everything happens in the open. It sets an excellent example on how to be nimble, open, flexible, and compatible. With a similar goal, and both under Eclipse, EE4J can in the future easily adopt MicroProfile technologies.
Croft: The MicroProfile effort was born out of a desire to see a faster pace of innovation. Right from the start, the intention was for MicroProfile to stand on its own feet, while still acknowledging the closeness to Java EE, since it began with Java EE APIs.
The role of MicroProfile is already being seen with the first API that was developed within MicroProfile - Config - being submitted as a JSR just before the move to Eclipse was announced. It's clear that there's a lot of ways that the two projects could relate to one another, but it remains to be seen what form that takes.
My view is that MicroProfile has all it needs to continue in its own right. It is already largely compatible with Java EE/EE4J and any specs developed in MicroProfile will therefore be relatively straightforward to submit to EE4J.
InfoQ: What can our readers expect with Open Tracing API 1.0 and Open API 1.0 with the release of MicroProfile 1.3?
Jiang: MicroProfile Open Tracing defines a model to trace the flow of a microservice request across service boundaries. It is common in a microservice architecture where a request flows through multiple services. This specification defines an API, based on opentracing.io, and specifies the behaviour that allows services to easily participate in an environment where distributed tracing is enabled. This specification defines an easy way to allow a microservice to take advantage of distributed tracing by using annotations. One of the nice features offered by this specification is to allow JAX-RS applications to participate in distributed tracing automatically without any code changes.
The MicroProfile Open API aims at providing a unified Java API, defined by OpenAPI v3 specification, that all application developers can use to expose their API documentation. As OpenAPI v3 Specification itself is language-agnostic, there is a need to evolve the Java-based Open API, for application servers to adopt. This specification is based on Swagger libraries from SmartBear, who is also a MicroProfile member. The MicroProfile Open API specification further improves the APIs to better fit with microservice development.
Apart from MicroProfile Open Tracing API and Open API, MicroProfile has recently created another specification, MicroProfile REST Client, which is also planned for the MicroProfile 1.3 release. This specification is to provide a type-safe approach to invoke RESTful services over HTTP. This specification is REST client focused, aiming for an easier client creation, where the client-server communication is to be handled in the application servers.
Croft: There was actually discussion on this point in the most recent bi-weekly call. MicroProfile 1.3 is currently targeted to release in December and there was a status given by each project to see what might make the deadline. Right now, it looks like OpenAPI, OpenTracing and the Typesafe REST Client API are all likely to make the release. The OpenAPI specification is pretty big, so the main challenge there is the TCK. The spec itself brings compatibility with version 3 of the OpenAPI specification begun by Swagger, already familiar to a lot of developers.
The Typesafe REST Client aims to give developers a typesafe way to consume remote REST services by defining an interface to program against. There is some potential alignment with the OpenAPI spec, but any firm discussion around that area has been deferred to a release after 1.0. One potential area to investigate would be a way to generate REST client interfaces from an OpenAPI definition, though this may fit more naturally in tooling.
Finally, OpenTracing brings the OpenTracing standard to MicroProfile and compatibility with such tracing implementations as Zipkin or Jaeger.
InfoQ: Will the new release cycle of Java SE affect development at MicroProfile and/or EE4J?
Jiang: The new faster release cycle of Java SE affects the development at MicroProfile and EE4J in a very positive way, which means the new or updated specifications can use the new and latest Java SE features. The current MicroProfile programming model requires Java 8 as a minimum. Some nicer features, e.g.,
FunctionalInterface, a default implementation of interfaces, etc., are widely used in MicroProfile specifications.
Croft: We have had lots of questions around Java SE from our customers, but these concerns were just related to Payara Server or Payara Micro. I think that, in the same way, Java SE changes will likely affect implementers of EE4J and MicroProfile more than they will affect the specifications themselves.
That said, the original aims of MicroProfile were to be innovative and to look to the future, so I would expect some discussions around Java SE changes to happen next year in 2018 since Java 8 will reach its end-of-life in September next year as Java 11 (as it is currently called) becomes the new LTS release.
InfoQ: When do you anticipate Java 9 compatibility with MicroProfile?
Jiang: We have not discussed this topic in the MicroProfile GoogleGroup as yet. One important factor with Java 9 is that it is not expected to be supported as long as Java 8 – due to the six-month release cycles. After that, it is not certain. This has some implication for MicroProfile. When MicroProfile adopts Java 9 depends on when the application servers such as Open Liberty, Wildfly Swarm, TomEE, and Payara support Java 9.
Croft: Java 9+ compatibility will largely be an issue for implementers, since there are already existing module systems like OSGi in Payara Server and others. I doubt that there will be formal support for Java 9 since it is not a designated LTS release, so I expect that formal support for future Java versions would choose Java 11 from September.
InfoQ: What are your current responsibilities at IBM, that is, what do you do on a day-to-day basis?
Jiang: Being the MicroProfile development lead and CDI architect in IBM, I actively participate in MicroProfile discussions and contribute to various specifications. I also manage how this specification is implemented in Open Liberty. I lead both MicroProfile Config and Fault Tolerance specifications, as well as contributing to other specifications such Metrics, Health, REST Client, Open Tracing etc. Being an influential member of the MicroProfile community, I am also very devoted to keep MicroProfile nimble and lean by relentlessly trying to improve the way we work as a community. I am very passionate about the MicroProfile programming model. I have spoken at many conferences (Devoxx US, Devoxx UK, JAX London, Voxxed Belgrade, EclipseCon Europe) to talk about MicroProfile and gather feedback on how to improve the specification in the future releases. I am also the Configuration JSR co-spec lead. With this role, I am trying to standardise what we have done in MicroProfile Config, with the aim of keeping Config JSR and MicroProfile Config in sync. Therefore, the new functionalities added in Config JSR will be made to MicroProfile Config.
InfoQ: What are your current responsibilities at Payara, that is, what do you do on a day-to-day basis?
Croft: My current responsibilities are very broad! I work as head of the support team at Payara, so my first responsibility is to our customers and then to our community. Fortunately, I have the privilege of working with some incredibly talented, dedicated colleagues both in my team and in our development team. Between us, we cover commercial support for the product, documentation, blog writing, conference speaking, contributing to MicroProfile, community support and everything in between! It can get very hectic, but it's very rewarding to hear the comments from our user base.
Resources
- Eclipse MicroProfile by Roxanne Joncas (Eclipse Newsletter, September 20, 2017)
- Eclipse MicroProfile Config - What Is It? by Emily Jiang (October 18, 2017)
- The Future of Java EE, A Q&A with David Blevins: The Eclipse Foundation, EE4J and MicroProfile by InfoQ (October 20, 2017)
- Accelerating the Adoption of Java Microservices with Eclipse MicroProfile by InfoQ (November 8, 2017)
- Eclipse MicroProfile: A Quest for a Lightweight and Modern Enterprise Java Platform by Mike Croft at Devoxx Belgium (November 9, 2017)
- Building a Resilient Microservice? All you need is Eclipse MicroProfile Fault Tolerance! by Emily Jiang (November 16, 2017)