IBM’s third quarter release of Open Liberty 18.0.0.3 features full support for MicroProfile 2.0 and a focus on the MicroProfile Metrics API. Alasdair Nottingham, WebSphere and Liberty runtime architect at IBM, spoke to InfoQ about this latest release.
IBM’s third quarter release of Open Liberty 18.0.0.3 features full support for MicroProfile 2.0 and a focus on the MicroProfile Metrics API.
First introduced just over a year ago, Open Liberty is an open-source implementation of IBM’s WebSphere Liberty application server to build microservices and cloud-native applications. Making its debut in 2012, WebSphere Liberty was designed to be small and lightweight, and has served Java EE 7 certified applications that are deployed in major platforms such as Docker, Kubernetes, and Cloud Foundry.
Writing about the natural evolution for microservices development, Kevin Sutter, MicroProfile and Java EE architect for WebSphere at IBM, stated:
Open Liberty has been one of the leading open-source implementations of the MicroProfile platform. Ever since the first MicroProfile 1.0 release in 2016, Open Liberty has provided a fully-compatible, production-ready implementation soon after the community completes the respective specifications. This quick delivery cadence by Open Liberty allows you to experiment with new MicroProfile APIs almost as soon as they are defined. The latest Open Liberty deliverable supports both MicroProfile 1.4 (based on Java EE 7) and 2.0 (based on Java EE 8).
Developers can take advantage of Open Liberty interactive and static guides. The 15-minute guide on MicroProfile Metrics demonstrates how to implement system and application metrics from a sample inventory microservice.
After cloning the repository, change over to the finish directory and execute the following Maven command:
Once the server is running, the following URLs are available:
The /metrics endpoint on port 9443 will display output from the @Timed, @Gauge and @Counted annotations.
Developers can also take advantage of Open Liberty Tools, a set of lightweight tools for developing, assembling, and deploying apps to Open Liberty, with all Open Liberty repositories available from GitHub .
OSGI is an integral part of Open Liberty. In a recent EclipseCon 2018 presentation, Alasdair Nottingham, WebSphere and Liberty runtime architect at IBM, demonstrated how OSGi is used to build Open Liberty. The following diagram demonstrates how Java EE packaging is mapped to OSGi modules.
In a recent Groups.io conversation, Nottingham explained why OSGi isn’t exactly „en vogue“ in the Java community:
Open Liberty makes use of OSGi as a part of the runtime implementation, but we don’t provide an application programming model based on OSGi. A big part of the reasons for this is because we put OSGi application support into our commercial product and didn’t see a massive uptake in place of vanilla Java. It seems that many developers see the extra complexity of OSGi and not the benefits. As you observe it isn’t ‚en vogue‘.
In any case, we don’t talk about OSGi and Open Liberty because it is really an implementation detail of how we provide the runtime.
Nottingham spoke to InfoQ about this latest release of Open Liberty.
InfoQ: What are the feature goals for each quarterly release of Open Liberty? Is there a primary feature targeted for each release?
Nottingham: We wanted to deliver Open Liberty using an agile approach. This means rather than set goals for each quarter, we manage a backlog of work we are doing and we ship the function when ready, rather than on a particular date. We do set goals for some function, but even then we don’t stop the train if it can’t make it. Some features that we have set goals for in the past have been the Eclipse MicroProfile releases, we aim to ship support for those API’s in our release following the Eclipse MicroProfile release. It is really important to me, as the lead, that we ship when ready so we make sure it is right and the quality is there. Open Liberty releases this year have included complete support for Java EE 8 and Eclipse MicroProfile 2.0 as well as adding support for Spring Boot applications, authentication via social media providers, OpenID Connect, HTTP session failover using JCache providers like Hazelcast among others.
InfoQ: What makes Open Liberty unique over the other middleware application servers?
Nottingham: I think there are three things that make Open Liberty really unique: We support multiple versions of Java EE in the same release. That means you can choose whether to run Java EE 7 or Java EE 8. You aren’t forced to make the choice of one or the other. You should be in control of moving forward. It also means you more easily get all the security and functional fixes. We were designed from the ground up to be modular and to support a pick and mix for server capabilities. This wasn’t retrofitted after the fact. I know it is common for some people to think they will just take Tomcat and stuff in the extra Java EE capabilities into their application. But that doesn’t produce the most efficient runtime. There is real work to be done to make sure all these technologies work well and efficiently together, and that is what we did without requiring you to run everything in every deployed instance. We do not force configuration or application migration for new releases. I know for many people this might seem kind of boring, but no one likes having to update their code just to use the most recent version of a downstream dependency. No one likes having to recode their application or re-configure the server just to go from one version to another. It adds friction and takes you away from the important thing – your application. With Liberty, we still support server configurations produced years ago without change and, as long as you don’t switch from Java EE 7 to Java EE 8, you don’t need to recode your applications because we will continue to run them with Java EE 7. I know people will claim that Java EE 7 and Java EE 8 are forward compatible, but we have a list of Java EE 7 -> Java EE 8 migration gotchas and they just go away.
InfoQ: Is IBM unique in using OSGi to build Open Liberty?
Nottingham: Open Liberty isn’t unique in using OSGi. WebSphere traditional, Glassfish and Payara all use it as well, but the way we use it is very unique. We built Open Liberty from the ground up to really exploit OSGi. We use the modularity layer to: keep our internals internal to remove classpath hell between the runtime and applications; use the OSGi Service layer (and Declarative services) to ensure a fast, dynamic and parallel startup so we can start quickly, efficiently, and lazily; and use the Subsystem layer to create the concept of features to compose our runtime so you can just use what you need.
InfoQ: What’s on the horizon for Open Liberty 18.0.0.4 and subsequent releases in 2019?
Nottingham: I’m always hesitant to answer this kind of question because I believe in shipping when ready, not on a date. Sure it isn’t always possible, but I’d hate to say “we are working on X for 18.0.0.4,” then decide to slip it because it wasn’t ready and then have someone complain that it didn’t arrive. That said, some of the things we are actively working on for the next year are: Java SE 11 – we are actively working on this given Java SE 11 was just released.
