- WebSphere Liberty: The next generation application server
- The difference between Liberty and WebSphere Application Server
- The difference between a Liberty profile and Liberty server
- The difference between Liberty assets and Liberty features
- Liberty and a JRE
- Multiple builds for the same Liberty version
- Packaging a server
- Liberty clustering
- Downloadable resources
Java EE, the next inception
A primer to WebSphere Liberty for Java EE developers
Straightening the cloud learning curve for experienced developers
Is this happening to you: You're familiar with some of the traditional on-premise Java EE application servers (like classic IBM WebSphere Application Server, WebLogic, JBoss, and so on), and now your organization is transitioning to the cloud. But the as-a-service versions of your platforms are similar-but-not-entirely to what you're used to, and the cloud models are so dynamic that you're never sure what builds to use, or what features will work, or even what to call things (Is it a profile? Is it a server?).
If you're finding this to-the-cloud learning curve frustrating, help is here. And you're looking at it.
This is the first of a trio of tutorials created to help flatten that learning curve by quickly getting you to the information you need that can be challenging to find on your way from traditional WebSphere Application Server to WebSphere Liberty, and ultimately to IBM Bluemix. Some of this you'll already know (skip those parts). Use the rest of these tutorials to become familiar with WebSphere Liberty, install a development environment for creating Liberty applications, and deploy those applications to Bluemix.
What's Liberty? IBM WebSphere Liberty is the next generation architecture of IBM WebSphere Application Server. Using the Liberty profile enables you to create more efficient runtimes for your Java EE applications, but to do so you must understand how to configure this new runtime and optimize it for your needs. This article introduces you to the Liberty architecture, explains its concepts, its advantages, and how it differs from older application server architectures. It also describes new kinds of tasks you’ll need to perform to customize Liberty for your requirements. This information will help you understand the benefits of the Liberty profile and how to use Liberty for development.
Together, this group of tutorials cover:
- A primer to WebSphere Liberty for Java EE developer (this one)
- Install a local Java EE development environment for WebSphere Liberty
- Install a local Java EE development environment for Bluemix
The first two tutorials are useful to all Liberty developers, while the third one applies specifically to those using Bluemix.
WebSphere Liberty: The next generation application server
Simply put, WebSphere Liberty has a reimagined architecture that provides many significant advantages over other, older Java EE application servers. In a nutshell, these advantages include:
- Kernel architecture – A kernel architecture means the runtime starts very small and very quickly, then grows as needed. Typically, a Liberty server requires ~50 MB of memory and starts in less than 3 seconds.
- Feature manager – Application server functionality is implemented as features that a manager loads only as needed, keeping the server size as small as possible.
- WebSphere Liberty Repository – Features are downloaded as needed, directly from IBM.
- Dynamic updates – New features are installed without restarting the server.
- Java EE 7 support – Liberty supports full Java EE 7 applications.
- Simple to install – To install a runtime, just unpack an archive file. The complete Java EE 7 download is only 94 MB (JRE not included).
- Simple deployment – Drop in an application and the server runs it.
- Simple to configure – Each server is configured primarily via one simple XML file.
- Highly scalable – Administrative model scales to thousands of servers. A cluster can contain hundreds of members.
- Server packaging – Compact application archives are created that include the server configuration for deploying to production.
Liberty’s advantages now make production-ready Java practical for many new uses, such as:
- Continuous updates – IBM delivers new versions of features individually.
- Development environment – Simple to install, configure, and update, multiple Liberty test servers run easily on a laptop with other applications.
- Single-board computers – Liberty applications can run on the new generation of tiny computers, such as Raspberry Pi.
- Internet of Things – Liberty applications can run on small, distributed devices (such as single-board computers).
- Server per application – Deploy each application to its own server for better isolation and manageability without significant overhead.
- Microservices – Run each instance of each microservice in its own server.
- Containers – Run a full application server in a small, lightweight container.
- Cloud – Quickly, easily, and efficiently run large numbers of servers on virtualized hardware resources.
- Elasticity – Auto-scaling clusters grow and shrink based on load.
- Massive throughput – Topologies can process billions of API calls per day.
Can your application server do this? Liberty can!
The sections that follow address essential concepts and terminology to better explain how the Liberty profile works, and how it differs from other application server products.
The difference between Liberty and WebSphere Application Server
WebSphere Application Server is made up of two application server runtime environments called profiles:
- Full profile (sometimes referred to as "classic" WebSphere Application Server) – The original architecture of WebSphere Application Server that started in 1998 with Servlet Express v1.0 and evolved into an industrial-strength Java EE container.
- Liberty profile – The next generation Java EE container architecture, introduced in WebSphere Application Server v8.5.0 in 2013, designed to be highly composable, to start faster, use less memory, and scale better.
Which WebSphere Application Server are you familiar with: When you’re using a WebSphere Application Server Network Deployment cell, each cluster member runs in an installation of full profile. Even though Liberty is part of the WebSphere Application Server product, you may not have used it yet.
As you’ll see, Liberty’s runtime is very compact and lightweight, making it particularly well-suited for virtualized infrastructure and cloud computing, for lightweight containers, and also for devices in the Internet of Things.
Liberty is available packaged in several different platforms. As of this writing, they are:
- Liberty profile – Part of WebSphere Application Server and available separately, for installation on an on-premise computer, including installing it locally on your laptop for development.
- Liberty Docker images – The
websphere-libertyimages that run Liberty in Docker containers.
- Bluemix instant runtime – The Liberty for Java runtime in Bluemix, built using the IBM WebSphere Application Server Liberty Buildpack for Cloud Foundry.
- Bluemix container – The IBM Liberty Image (
ibmliberty), the websphere-liberty image optimized for running in Bluemix.
For a given version of Liberty (such as v22.214.171.124), each of these installs provides equivalent, nearly identical functionality. The main difference is that the buildpack does not include Liberty features that are not used in a cloud environment.
The difference between a Liberty profile and Liberty server
A Liberty server is an application server, capable of running Java applications, typically ones written for the Java Enterprise Edition specifications. A server in Liberty is typically configured as a Java EE-compliant container implementation, such as Java EE 7.
A Liberty profile is an application server runtime environment that is installed on a computer’s local file system. A profile doesn’t run, but it is capable of running one or more servers.
A Liberty profile has a version number, such as v126.96.36.199, which is the version of the Liberty kernel. All of the servers running in a profile have the same version. Because a profile can run multiple servers, and each server can be configured individually, there is little reason to install multiple profiles of the same version on the same computer. However, to run two different servers that are each a different version requires installing two separate profiles, one for each version, and creating a server in each profile.
While a single Liberty server can run multiple applications, Liberty can also efficiently run each application or microservice in a separate server. A good practice with many Java EE application servers, such as WebSphere Application Server full profile, is to deploy multiple applications to a single server to share its resources. However, because a Liberty server is quite small and efficient, deploying multiple applications to a single server achieves little resource savings. Therefore, each application is often deployed to a separate server, for better isolation and manageability. In a microservices architecture, each instance of each microservice (a part of an application) is deployed to a separate server.
The difference between Liberty assets and Liberty features
The Liberty profile implements its functionality as OSGi bundles, where a related set of bundles implements a feature. A feature in Liberty implements a set of functions for use by an application and by other features. Each bundle includes a set of JAR files that are added to the server’s class path.
The feature manager in a Liberty server controls the set of features that are currently running in the server, loading and unloading them as the applications need them. It only loads features that are enabled for the server. The list of enabled features is configured in the feature manager section of the Liberty server’s configuration. A good practice is to configure the server with only the features its applications use, which enables the server to start faster and consume less memory.
Assets and repositories
For a server to be able to load a feature, not only must the feature be enabled in the server’s configuration, but the corresponding asset for that feature must be installed in the profile for that server. A Liberty asset is a set of code artifacts that can be added to a profile, such as a Java library that implements server functionality. A Liberty Repository is an online resource that contains assets available for download to Liberty profiles.
The IBM WebSphere Liberty Repository is IBM’s main repository for Liberty assets. By default, a new profile is configured to search that repository for assets to download. The asset management utilities in a profile access a repository programmatically.
Each feature also includes a list of required prerequisite features on which it depends. When a profile downloads the asset for a feature, it also downloads the assets for any prerequisite features that are not already installed in the profile. Likewise, when the feature manager loads a feature into a server, it also loads any dependent features that are not already loaded in the server.
Some Liberty features are convenience features. A convenience feature is a single feature that is a proxy for a list of multiple finer-grained features.
For example, a single Java EE feature enables all of the features that are part of the Java EE platform. Likewise, an EJB feature loads multiple EJB-related features: EJB Lite, EJB Home, EJB Remote, and a few others.
Often, for application development, you simply enable a convenience feature. When you’re ready to deploy your application, you can replace that convenience feature with the list of finer-grained features that the application actually uses to save memory and disk space.
Table 1 shows the list of convenience features in Liberty profile v188.8.131.52.
Table 1. Liberty convenience features
|Java technology||Liberty convenience feature|
|Java Platform, Enterprise Edition 7 (Java EE 7)|
|Java Platform, Enterprise Edition 7 Web Profile|
|Java Platform, Enterprise Edition 6 Web Profile|
|Enterprise JavaBeans (EJB) 3.2 full|
All of the features enabled in a feature manager’s configuration must be compatible. Two incompatible features cannot be loaded into the same server, so they should not be enabled. They can still be installed in the same profile and loaded into separate servers.
For example, a server cannot enable two different versions of the same feature (such as jaxrs-1.1 and jaxrs-2.0). Likewise, a server cannot enable webProfile-6.0 with either webProfile-7.0 or javaee-7.0. When you start a server that enables incompatible features, the server logs a
CWWKF0033E error. See Supported Java EE 6 and 7 feature combinations.
Liberty and a JRE
A Liberty server is a Java program, so it needs a JRE (Java Runtime Environment) to run. As you’ll see, most of the Liberty developer builds do not include the JRE; they assume the JRE is already installed as a prerequisite. This makes the Liberty download smaller, and enables multiple Java programs to share the same installed JRE.
A JRE can run Java programs, but it cannot compile Java code. A JDK or SDK (Java Development Kit or Java Software Development Kit) contains not only the
java runtime but also the
javac compiler. So while Liberty only requires a JRE, it can also run in a JDK or SDK.
Multiple builds for the same Liberty version
Each version of Liberty (such as v184.108.40.206) has multiple downloads, listed in IBM WebSphere Liberty Repository: Product, such as:
- WAS Liberty with Java EE 7 Full Platform
- WAS Liberty with Java EE 7 Web Profile
- WAS Liberty with Java EE 7 Web Profile with Java 8
- WAS Liberty Kernel
What are these downloads, are these different kinds of Liberty?
The downloads are different development builds of the same version of Liberty. Figure 1 shows their relationships. (Builds are also called “Install ZIPs”; see Liberty profile: List of installation ZIP archive files.)
Figure 1. Liberty developer builds
Each of these builds contains the same version of the same Liberty kernel. The difference is the set of features that is included with the kernel. For example, the build called WebSphere Application Server Liberty Kernel does not contain any features and the archive file is only 11 MB. By comparison, full platform (94 MB) is bigger than web profile (63 MB) because full platform contains more features. Full platform is a superset of web profile, and the web profile portion of full profile is exactly the same as the separate web profile download. Therefore, the download choices are simply a matter of what features you want included.
Notice also that two of the builds correspond to convenience features, as shown in Table 2.
Table 2. Convenience features and builds
|Liberty convenience feature||Liberty developer build|
|WebSphere Application Server Liberty with Java EE 7 Web Profile|
|WebSphere Application Server Liberty with Java EE 7 Full Platform|
What Table 2 tells us is that if you want a server to run applications built for a particular Java EE platform, install the build that corresponds to the convenience feature for that platform. Servers running in that profile will have the Java EE features the applications require.
Each of these builds requires that you separately install a JRE. The exception is WebSphere Application Server Liberty with Java EE 7 Web Profile with Java 8, which includes not only the web profile but also a JRE (specifically, the IBM Java SDK). Because the archive includes an SDK, it is considerably larger: 198 MB vs. 63 MB for web profile without the SDK. If you already have a current JRE (or JDK/SDK) installed on your computer, you don’t need this archive. Because the JRE is platform-specific, this is the only Liberty build with platform-specific options.
These Liberty developer builds are not the complete WebSphere Application Server product. The full product includes both full profile and Liberty profile, and is a family of product editions including Express, Base, Network Deployment, and z/OS. The Liberty developer builds are equivalent to the Liberty profile portion of the WebSphere Application Server for Developers edition.
Packaging a server
To deploy an application running in a Liberty server to a new computer (such as a production environment), it is not necessary to install an entire Liberty profile and all of the optional assets. Rather, Liberty can package a server into an archive that contains just the application, the server configuration, and (optionally) portions or all of the runtime. The packaged server only consumes disk space and bandwidth for the artifacts that need to be transferred.
Before packaging a server, you can first remove any unused features from the feature manager’s list of enabled features. If you configured the feature manager with any convenience features, replace each of those with the explicit list of features the application actually uses. A minimal set of features makes the archive, the resulting runtime, and the server they run as compact as possible.
When packaging a server, there are multiple levels of what can be included in the archive. All levels include the applications and their server configuration. The levels are:
all– Full runtime
minify– Minimal runtime
usr– No runtime
The minimal runtime doesn’t contain all of the assets installed in the runtime, only those for the features enabled in the server. Therefore, the contents of a minimal archive depend on the server’s configuration.
You can also package just the runtime without the applications:
wlp– Only the runtime
Should you include the runtime in the packaged server? That depends on whether the target computer where you’ll unpack the archive will already have an adequate runtime installed. For example, if you want to include everything needed to run the application, include the runtime (
all level, or better yet
minify level). However, if you’re installing multiple applications in multiple servers on the target, it’s less efficient for all of their packages to include the runtime and for the runtime to be installed multiple times on the target. Instead, either one of the packages should include the runtime non-minimized, since it has to support multiple servers. Or, create a
wlp package for the runtime and
usr packages for each of the servers.
When unpacking a packaged server or runtime on a target computer, remember that the runtime does not include a JRE, so the target computer will need to have a JRE installed.
As you’ll see later, a packaged server (
usr level) is also a convenient way to deploy a Java application to Bluemix along with its server configuration.
The Liberty profile supports clustering. A cluster in Liberty provides much the same behavior as clustering in Full profile: user load is distributed across multiple servers, and user sessions fail over from one server to another. However, Liberty’s implementation is lighter weight with greater scalability. As with Full profile, the clustering feature in Liberty profile is part of WebSphere Application Server Network Deployment (WAS ND). In Liberty features, notice that the features
clusterMember are only included in WebSphere Application Server Network Deployment and z/OS, not in WebSphere Application Server Base.
In Liberty profile, an administrative domain is called a collective. A collective serves much the same purpose as a cell in Full profile, but is implemented quite differently. The collective controller serves the same purpose as the deployment manager; it provides centralized administration of the collective members, which are the Liberty servers in the collective.
Several improvements have been made:
- The members are loosely coupled to the controller.
- A server can be both a controller and a member.
- A collective can have multiple active controllers for high availability of administrative functions.
For more information, see Introducing Liberty Collectives.
Servers in the same collective can be joined into a cluster. An application running in a cluster has higher availability and greater scalability than it does in a single server. A collective can define multiple clusters. A server can be a member of only one cluster. For more information, see Introducing Liberty Clusters.
A cluster can be an auto-scaling cluster, one that adds and removes cluster members to provide scalability as needed. Scaling functionality is added to the controllers and to the cluster members that can be added and removed. You configure the scaling controller using a scaling policy for each cluster. A scaling member monitors its workload and reports its performance to the scaling controller.
Auto scaling works best when the Dynamic Routing feature is also enabled. While the WebSphere plug-in for an HTTP server handles a static set of servers, Dynamic Routing handles an environment where servers are being added and removed without having to regenerate the plug-in configuration. It is a feature added to the controller. Dynamic Routing is one aspect of Intelligent Management, a suite of on demand router (ODR) functionality to optimize load distribution of HTTP requests.
This tutorial reviewed basic concepts of how the IBM WebSphere Application Server Liberty profile works. With this understanding, you’ll be prepared to set up a Liberty server for your development needs.
The next article in this series Install a local Java EE development environment for WebSphere Liberty.
The author thanks the following IBMers for their help with this article: David Currie, Ross Pavitt, Rick Osowski, Pam Geiger, Budi Darmawan, Heather Nelson, Dave Thiessen, and Ruth Willenborg.
- Introducing the Liberty Profile
- IBM WebSphere Liberty Repository
- IBM WebSphere Liberty Repository: Features
- Download the WAS Liberty runtime
- Introducing Liberty Collectives
- Introducing Liberty Clusters
- Lab: Build and Administer Your Own Liberty Application Cluster
- New Docker images for Java EE 7
- IBM WebSphere Liberty Buildpack Contributed to Cloud Foundry
- Full profile overview
- Liberty profile overview
- End-to-end paths for the Liberty profile
- Intelligent Management for web servers overview
- Liberty profile: Runtime environment known issues and restrictions
- If liberty means freedom of choice, am I free to choose the Liberty profile?
- Building a large scale WebSphere Application Server Liberty collective topology
- Best Practices for Configuring and Managing Large WebSphere Topologies
- Java Platform, Enterprise Edition (Java EE) 7
- WebSphere Liberty profile: The little appserver that could
- Liberty Pi - Running WebSphere on the Raspberry Pi
- Liberty controlled car
- Microservices with Liberty and NetflixOSS
- Building web scale applications with WebSphere Liberty Profile and Netflix Open Source Software