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).
Open Liberty Guides and Tools
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:
mvn install liberty:start-server
Once the server is running, the following URLs are available:
http://localhost:9080/inventory/systems
https://www.localhost:9443/metrics
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.
Open Liberty and OSGi
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?
Alasdair 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. We had Liberty running on Java SE 9/10. There were a few limitations, but Java SE 11 threw some major spanners in the works that we have to address.
- Eclipse MicroProfile - we are heavily invested in the success of this project and our goal is to release support for each MicroProfile release in our release following theirs. This might seem like a small thing to have one liner, but there is a lot going on here, including adding support for reactive programming models.
- Jakarta EE - obviously we are very interested in this move and, while it is still in progress, our development team is involved in the discussions and we expect to support Jakarta EE releases when they come out.
- Improving transparency into Open Liberty - some of the things we did when we first launched Open Liberty were compromises in the interest of launching the code as open-source. One key area is in build transparency. We build on IBM hosted hardware and the build results get posted to internal systems so you can only see the outcome of a pull request that you submit if you work for IBM. So we are trying to move the build output so it is publicly visible. We also had a problem with a large number of tests where we couldn't open-source them because they were developed with our customers so we don't hold exclusive rights to them. We still run those tests because they provide value for finding regressions. But we are constantly looking to reduce the number of tests we have behind the firewall, either by rewriting, or getting permission to move them.
- Simplify integration into Maven/Gradle builds - we have a set of plugins for building apps that deploy to Liberty today, but they have evolved over five years and don't provide the simplest user experience. So we are working on simplifying that in a side project we call Boost. I'm quite excited about this longer term, but it's a bit too early to get into details just yet.
- We've been very thoughtful about how to make Liberty play well in Docker/Kubernetes and Cloud Foundry, and continue to treat these as the environments for which we want a really good DevOps experience. We do some of this as a part of the way we implement support for new Eclipse MicroProfile capabilities, but there are other functional and usability improvements we're delivering, like supporting the forwarded headers for HTTP proxies.
- Improve performance - I get that everyone does this all the time, but we are working on some cool improvements such as an auto-tuned thread pool which works out the optimal number of threads at runtime. We are planning on tweaking this algorithm to make it better, as well as looking at ways we can shrink the size of Liberty to make it even smaller.
Resources
- Open Sourcing Liberty by Alasdair Nottingham (September 19, 2017)
- IBM Introduces Open Liberty, an Open-Source Runtime for Java Microservices by InfoQ (October 11, 2017)
- Get More Metrics from Your Apps with MicroProfile 2.0 on Open Liberty 18.0.0.3 by Lauren Cowen (September 19, 2018)
- OSGi in Action: How We Use OSGi to Build Open Liberty by Alasdair Nottingham at EclipseCon (October 23, 2018)