IBM Liberty: Modular and solid as a rock
Metallic wire mesh image via Shutterstock
Do you actually want to read an article about a Java EE application server? If you agree that the Java EE Stack is still a pillar of modern IT and think that application servers should be reliable, standards-compliant, but also innovative and cool, then Java/Java EE veteran IBM has something to offer — which may come as a surprise to some. This article provides an overview of IBM Liberty, what makes the application server special and why you should work with it.
Some stars take a little longer to shine. If you would have come to the IBM conference in ICC in Berlin, which took place in October 2011 and you wanted to attend one of the two presentations titled “Lean WebSphere environment for development”, you most likely wouldn’t have been able to find a seat, and you would have witnessed cheers and extended applause. What happened? It was an audience that, aside from the undeniable strengths of the IBM WebSphere Application Server (WAS), had most likely got used to its somewhat poor attributes: complex configuration, high resource consumption and long start times for the server or application. In a worldwide premiere, Ian Robinson (WAS Chief Architect) and his colleague Tim deBoer presented an application server of a completely different kind: a start time of 2 s (seconds!) using an old-fashioned notebook and a 60 MB ZIP file for the installation of the entire application server – no more DVD stacks.
An unequivocal and clear statement was met with even more enthusiasm: We are not unaware of what ails the developers, in particular. Yes, it has taken a while. As of today, however, everything is different. The presentation introduced the “Liberty Profile”, a completely new version of the IBM WebSphere Application Server.
And what’s up with that star, five years later? Back then it was a pre-release version of an application server. Today, IBM WebSphere Liberty – some may have to overcome their antipathy to the name and look at things in perspective – is a valuable server, certified for Java EE 7 Full Profile, that remains slim, fully suitable for production and supported by the manufacturer. As was the case before, the transition to the application server is very simple: after a download of only 50-100 MB, depending on the version, a simple unzip is all that’s needed and Liberty is installed. One more command and the server can be started.
The configuration is just as simple: if you like, a single XML file is all you need. Whoever uses Tomcat will be familiar with it. Anyone used to the IBM configuration has been unfamiliar with this kind of elegance and simplicity, until now.
Even though Liberty is far less known than Tomcat or JBoss/WildFly, some myths die hard. We want to explicitly clear up a few of them.
Myth #1 about the configuration: “There’s no graphical configuration tool”. Yes, there is. If you want one, you can use the practical IBM WebSphere Liberty Server configuration tool , a browser-based administration and configuration tool. There is also the option to use the graphical editors from the Eclipse-based WebSphere Developer Tools (WDT) to edit the XML configuration files. WDT can be downloaded via the Eclipse marketplace, and thus Myth #2 is exposed: „You need expensive Rationals Tools to work with WebSphere“.
The configuration via XML file or UI serves another purpose, however, that you won’t know from other Java EE application servers, namely the definition of the features to be prepared by the application server. This partly explains the puzzle of how IBM has been so successful in making such a slim server. It is completely modular. The developer or administrator tailors their server precisely using the selection of modules in the configuration.
Liberty consists of modules
IBM developed the Liberty Profile as a modular server with fine granularity from the bottom up. Standardized and proven OSGi technology is used for modularization, which is known to properly depict the ideas of versioning and dependencies between components.
A kernel of the server loads the specified Liberty modules at startup. It loads further modules automatically when they are needed. IBM started using internal modularization by way of OSGi in the classic WebSphere Application Server V6.1 back in 2006. In that case, however, you could ban the portlet container or JCA container that is not being used from the central memory. The granularity of the modularization of Liberty is much finer and, in our view, unique to Java EE servers. In order to clear up an obvious misunderstanding: Though OSGi is hidden from the normal Java EE user, you can also use it for the program code comprehensively in Liberty, of course – as is the case for many application servers. The list of features and their modules is too comprehensive for this article, so we’ve included a link . We think an example might be useful here:
Imagine the Java EE application you use requires JSF. The JSF feature is loaded in Liberty through the corresponding configuration. Liberty automatically obtains the servlet and JSP features and their modules, thanks to OSGi. If the application does not use any JSF or JSP-based UI, but rather just servlet calls, only the servlet feature loads. As a result, no CPU cycle or central memory is used for the JSP or JSF functionality.
Liberty is completely Java EE 7 certified
Myth #3 about specification: “Liberty only supports the limited JEE Web Profile.” From the developer’s perspective it is great that, for the above-named feature concept, Liberty has been a fully certified Java EE 7 application server since Version 184.108.40.206 .
This makes it much more than the classic WAS as far as this current programming model is concerned. It also supports the use of Java SE 1.6, 7.0 and 8.0, and not only in the in-house implementation of IBM, but also Oracle, for example. IBM offers comprehensive, production-ready support for Liberty via the standard agreements. This depends on what edition of Liberty you have. The selection ranges from a simple version certified only for Java EE 7 Web Profile to a clusterable edition that offers much more than only Java EE 7.
Zero migration with Liberty
The above-described modularity allows IBM to break new ground with Liberty in order to make using Java EE technology as efficient and agile as possible. A migration of the runtime environment to a higher version eliminates the significant efforts involved in testing and, if necessary, adapting the existing applications for the new version. Given the backward compatibility of many specifications, the extent of adjustment for a single application is generally minor. However, it can’t be avoided. In addition, there are often a hundred or more applications that can be affected particularly in larger environments. And the migration process is not complete until the final application has been adapted. The result: unpredictable project durations that can often go on for many months.
Thanks to its modular structure, Liberty offers a surprisingly elegant solution for this. The migration of Liberty means that an old existing feature would have to make way for a new version; the new version does not simply replace the old one. Instead, the new version is added, which means that both are available.
An example: Liberty currently has the features “servlet-3.0” and “servlet-3.1”. If applications only require “servlet-3.0”, the server can be configured so that only this feature is loaded. In this way, the servlet runtime environment doesn’t change (from the application perspective). If this applies to all features required by the application, the application migration is no longer required here.
In addition, the OSGi-based architecture ensures that incompatibilities between features or certain versions of features are reported at server startup and not only at the runtime. For example, the simultaneous use of “servlet-3.0” and “websocket-1.1” is blocked from the start.
Continuous delivery of new features
IBM is breaking the mold when it comes to the development of and support for Liberty. The traditional way of adding functions through new releases and refresh packs can slow progress in many projects. Too rarely are there updates.
Here, IBM has two approaches to the solution, marketed under the slogan “Continuous Delivery Model”. It is now common that new functionality is made available through the quarterly fix packs. Something that was only available in a restricted format, mainly in the form of additional properties for fine configuration of individual components of the application server. Now, entirely new features are rolled out as follows:
ejb-3.2, batch-1.0, jacc-1.5 and countless others were introduced in fix pack 220.127.116.11, so that the Java EE 7 certification was possible at this level and above.
The real innovation, however, is the Liberty Repository. Here, IBM is providing new functions for Liberty continuously, without fixed schedules and lengthy announcements. This could involve new APIs, features, or tools, as well as scripts or “snippets” for the configuration of the server. Anyone looking for open source components like Struts, RichFaces, Hibernate or others with Liberty will find everything they need there.
The Repository is accessed from the IBM Installation Manager, directly via the website , or from the developer tools available for Eclipse environments (these in turn must be installed via the Eclipse Marketplace). Search and filter functions help you find suitable downloads from the well over 150 entries that are already there. For existing Liberty installations, it is also possible to access the Repository via the command line. In this case, the dependencies of features are taken into account automatically.
Sweet spots in modern architectures
Despite all the euphoria, you have to look at the reality of the data centers, of course, in order to find the best application scenarios for Liberty. Often, a Java EE Application Server already exists, with recorded and possibly automated procedures for server installations, deployment and testing of applications, etc. Adding a new product here would have to be carefully considered. Since there is no “wsadmin” scripting language from the traditional WebSphere Application Server (WAS) for Liberty, such processes cannot be transferred from a WAS to Liberty without some effort.
Myth #4 about the target group: “Liberty is intended only for developers”.
It must be mentioned that Liberty can be used in production environments without restriction. There are cluster mechanisms that enable reliability and load balancing. Larger environments can be administered centrally via an interface (keyword: “collectives”). The scaling potential here is even better than in a classic WAS.
Therefore, using Liberty is less about replacing an existing infrastructure in one fell swoop. Instead, it makes more sense to select the projects that best take advantage of Liberty’s strengths. These are, for example, dynamic and modern runtime architectures like Docker or Cloud. Here, IBM has already created the best prerequisites for Liberty with the platform as a service solution Bluemix. Liberty is likewise recommended for highly scalable server environments with potentially thousands of specialized servers, since the slim and module structure of Liberty works particularly well in that context. Software architectures based on microservices would be a perfect scenario for that.
Even if you don’t take existing Java EE landscapes into account, there are still plenty of arguments in favor of Liberty: a certified programming model with Java EE 7, production capability through scalability and reliability mechanisms and the reliable support from IBM.
And on top of that, the IBM contingents in companies finally have a really cool product to show off again.
Links & literature
 Liberty Repository: https://developer.ibm.com/wasdev/downloads/