The WebSphere Contrarian
If liberty means freedom of choice, am I free to choose the Liberty profile?
This content is part # of # in the series: The WebSphere Contrarian
This content is part of the series:The WebSphere Contrarian
Stay tuned for additional content in this series.
I don't know about you, when I hear the word "liberty" I also think about "freedom of choice.” I suspect I associate one with the other because as an undergraduate – long ago – I took at History of Economics class. One of the classical economists discussed was John Stuart Mill, who was a proponent of free markets, and often cited both "liberty" and "freedom of choice" in his economic discourses. Clearly Mr Mills' writings made an impression since I recall this so many years later, and it's this aspect of my background that prompted the question posed in the title of this article. (Also, to set the record straight, I wasn't a contemporary of Mr Mill many years ago – it was a History of Economics class, not a Contemporary Economics class. It just needed to be said.)
In any event, the IBM WebSphere Application Server Liberty profile was very well received when it was introduced in mid-2012, and the ever-expanding list of functions in the Liberty profile has resulted in my repeatedly being asked for advice on determining whether the Liberty profile is the right choice. Before delving into the factors you should consider when making this choice, it’s worth providing a brief “level set” for both the IBM WebSphere Application Server “full” profile and the Liberty profile.
Profile: An overloaded term?
Profiles were introduced in IBM WebSphere Application Server V6.0 and provided for a separation of the WebSphere Application Server binaries from the WebSphere Application Server runtime configuration. The motivation for profiles was to eliminate the need for multiple individual installations that were specific to the deployment manager, node agents, and application servers, which resulted in multiple sets of binaries on a single physical server. Profiles enabled you to perform a single installation of the binaries, then create one or more “profiles” using the Profile Management Tool, or manageProfiles(.bat/sh) script, with all of the profiles using the same set of binaries. This eliminated the need to install and patch multiple sets of binaries on each server, while also saving disk space. There were initially three profiles on WebSphere Application Server V6.0: Deployment Manager, Application Server, Custom (Node agent without pre-built application server). Additional profiles were added in WebSphere Application Server V6.1 and V7.0 for the Enterprise Proxy Server, Job Manager, Admin Agent, Secure (DMZ) Proxy Server.
Continuing chronologically, Java EE 6 introduced the term “web profile” which was defined in the specification as “a profile of the Java Platform, Enterprise Edition specifically targeted at web applications” (which seems, at least to me, to be a circular definition; personally, I’ve always used “a subset of the Java EE Platform APIs employed for web applications” to more precisely define the Java EE Web Profile without reusing the word “profile” to describe the profile).
Somewhat curious again - to me at least - is the fact that the Java EE Web Services APIs (JAX-WS, JAXB, and so on) are not part of the Java EE Web Profile, although the Web Profile specification does speak to the “new pluggability features in the Servlet specification to allow applications to use libraries that extend the servlet container with minimal configuration overhead,” and then goes on to cite JAX-RS as a Java EE API not in the web profile that “can be plugged into a web container,” so presumably web services are to be addressed in a similar fashion.
In any event, the Java EE Web Profile is also part of (or a subset of) the Java EE 7 specification, so it seems here to stay, at least for the foreseeable future. It’s also worth noting that the Java EE 7 Web Profile requires JAX-WS; it is no longer a "pluggable" option, as was the case in the Java EE 6 Web Profile.
Finally, in WebSphere Application Server V8.5.0, the Liberty profile was introduced, and while the Liberty profile provides for a separation of the binaries and configuration, the Liberty profile is based on a different set of binaries and employs a different configuration model. But unlike prior profiles, the term “Liberty profile” encompasses both the configuration and the binaries. As a result, yet another term was added to the profile lexicon, with the phrase “full profile” used to denote the pre-Liberty profile WebSphere Application Server runtime.
Of course, since the Liberty profile employs a different set of binaries and a different configuration model from prior versions of WebSphere Application Server, it could be argued that the Liberty profile isn’t a profile at all, at least not in the customary WebSphere Application Server definition. Alas, the name has stuck, and we can only hope that WebSphere and the Java Community process will find another noun to use as the need arises in the future.
In fact, when a second configuration option for the Liberty profile was added in WebSphere Application Server V126.96.36.199 there was no mention of “profile;” instead this Liberty profile-based management process is known as the collective controller with the original Liberty configuration option simply referred to as a “server.”
Finally, while on the subject of profiles, the different and simplified configuration model for the Liberty profile allows for “profile creation” simply by adding a single line to the Liberty profile server.xml file, eliminating the need for a profile management tool or script, as is required with the WebSphere Application Server full profile.
Whither the Liberty profile?
Since its introduction, the Liberty profile has been generally regarded as a development runtime, this by virtue of the lightweight memory footprint and fast start up, both of which are highly regarded by application developers who need to frequently deploy new application versions during the development process. Additionally, the container services and features available at introduction were, for the most part, more appropriate for development use. As a result, it’s a common misconception that the Liberty profile is only suitable for development, when in fact the Liberty profile was (and is) suitable for production use; in fact, one client introduced the Liberty profile into their production environment just a few months after its introduction.
While this might come as a surprise to many, it shouldn’t. The decision to invest in the Liberty profile is the result of customer requests from system administration and operations groups - not just developers - going back over a dozen years to WebSphere Application Server V4.0, for a componentized application server runtime that could be configured for only the features and functions that were needed from an application and operational perspective.
These requests grew in frequency and urgency over the years. WebSphere development undertook extensive work in WebSphere Application Server version 6.0, 6.1, 7.0 and 8.0 releases to make the full profile "lighter weight" by removing dependencies between the various container services, starting container services only when needed, plus other optimizations. While progress was made, the Java EE architecture for the full profile prevented further improvements on this front. A new OSGi-based architecture was employed for the WebSphere Application Server Liberty profile, where each of the container services and run time features are implemented as OSGi bundles, allowing a "fit for purpose" runtime for both development and production. The OSGi architecture and delivery of features as OSGi bundles are also what enables the incremental release (commonly referred to as continuous delivery) of new features and functions without needing to wait for a major release, as is still necessary with the WebSphere Application Server full profile.
The current investment emphasis in the Liberty profile reflects both our ability to deliver new features without waiting for a new major release, as well as demand for more features that are currently only available in the full profile (for example, SAML, VMM/Federated repositories, certificate distribution, health management, application edition management, and so on). This demand is coming from across our client base, both external and internal; at last count, more than 150 IBM products embed the Liberty profile.
Whither the full profile?
The IBM WebSphere Application Server full profile remains core to the IBM Systems Middleware portfolio. IBM continues to invest in the full profile, reflecting the level of customer adoption and infrastructure investment that is based on the traditional WebSphere Application Server edition. Additionally, we continue to field and prioritize RFE (Request For Enhancement) submissions that ask for updates and new features to the full profile, even though delivery of new features in the full profile architecture is necessarily tied to major (integrated) releases.
Evidence of our investment in the WebSphere Application Server full profile is the following statement of direction from earlier this year (see Related topics):
IBM intends to certify WebSphere Application Server to Java EE 7 full platform compliance. WebSphere Application Server has made good progress towards this with the WebSphere Application Server Liberty profile features that were made available in WebSphere Liberty Repository through the continuous delivery model. WebSphere Application Server Liberty profile intends to complete Java EE 7 full platform compliance by using this approach. In addition, it remains the intention of IBM to certify WebSphere Application Server full profile to Java EE 7 full platform compliance.”
In short, rest assured that there are no plans to cease delivery or investment in the WebSphere Application Server full profile.
Liberty core versus Liberty profile
A source of confusion with respect to the Liberty profile is the Liberty Core product offering. Many incorrectly associate the Liberty profile solely with Liberty Core. While it is accurate to state that the Liberty profile comes with Liberty Core, it’s important to understand that the Liberty profile is also included with (along with the full profile) WebSphere Application Server – Express, WebSphere Application Server, WebSphere Application Server for Developers, WebSphere Application Server Network Deployment, and WebSphere Application Server for z/OS.
This packaging is illustrated in Figure 1.
Figure 1. WebSphere Application Server V8.5.5 profiles by product
As you can see in the figure, existing WebSphere Application Server users receive both the Liberty profile and the full profile “in the box.” Only users that purchase Liberty Core are limited to the Liberty profile installation images.
Regarding the differences in the Liberty profile for each of the products shown above:
- Liberty profile in Liberty Core delivers the Java EE Web Profile APIs, as well as OSGi application features and some additional “core” features for management and security.
- Liberty profile in WebSphere Application Server adds additional application APIs; in the latest release, the Java 7 EE full platform is available. Additional features include JCA connectivity and some object (or NoSQL, if you prefer) database options.
- Liberty profile in WebSphere Application Server Network Deployment adds additional management capability to what’s included with WebSphere Application Server, the collective controller, and a subset of the Intelligent Management features that are available with the Network Deployment full profile.
- Liberty profile in WebSphere Application Server for z/OS includes some features to leverage z/OS platform capabilities.
The features associated with each product offering are depicted in Figure 2.
Figure 2. Liberty profile Java EE 7 features by product
When to choose the freedom of Liberty
Those of you familiar with my earlier articles already know my response to this question: it depends. I am going to defer a more detailed discussion of the different deployment and operational options for another day, but I will take this opportunity to offer some suggested starting points.
- Employ the Liberty profile as your desktop development environment, with formal testing
and production remaining on the full profile.
This is likely a “slam dunk” action due to the Liberty profile’s lightweight footprint and fast startup time, which will make your development staff happy - and more productive. In this scenario, the container fidelity assurance provided between the Liberty profile containers and the full profile containers means that the containers on both profiles will function the same from an application perspective. Developers can start using the Liberty profile in their local development environment while the formal integration, test, and production environments continue to leverage the existing WebSphere Application Server full profile skills and infrastructure.
Since the Liberty profile offers a subset of the APIs that are available in the full profile, you’ll need to answer the question “Can this application run in the Liberty profile?” Fortunately there are tools to help with this assessment:
- WebSphere Application Server Migration Toolkit is a freely available Eclipse plugin (see Related topics) that scans application source to provide a high level evaluation report showing which Java EE technologies your application uses, as well as the WebSphere Application Server offerings (either full or Liberty profile) that provide the required container services. Additionally, a line-by-line analysis of the code changes required is provided along with detailed information for making the changes, and where possible quick fix code changes are available.
- Migration Toolkit for Application Binaries (see Related topics) is run from the command line, not from within Eclipse, which means that systems administrators who might not be familiar with an Eclipse IDE can easily assess applications for Liberty profile suitability without accessing the application source code.
The recent availability of Java EE 7 in the Liberty profile also means that developers can start developing applications that use Java EE 7 APIs, and then when Java EE 7 is available on the full profile, the new Java EE 7 applications can be deployed to production on the full profile.
- Leverage assisted lifecycle management for the Liberty profile in production.
Assisted lifecycle management is one of the intelligent management features introduced in WebSphere Application Server Network Deployment V8.5 that enables operational control and monitoring of middleware servers (meaning non-WebSphere Application Server full profile servers) in a Network Deployment cell. Using this function, you can start to gain operational experience with the Liberty profile servers while using your existing Network Deployment full profile skills and infrastructure. Liberty profile servers are added to a Network Deployment full profile cell, which allows for starting/stopping, routing requests, and monitoring from the Network Deployment deployment manager.
- Other options
A variety of other options also exist, either managing each of the Liberty servers individually or using the Liberty collective controller as a single point of management, but since these other options require a detailed discussion of the Liberty profile configuration and administrative architecture, we’ll defer coverage of these to another time. As a teaser, however, know that the Liberty profile offers not just freedom for developers, but for administrators as well.
The aim of this article was to clear up some common misconceptions about the Liberty profile so you can begin to reasonably assess how it might fit in your enterprise. Hopefully I’ve succeeded in that regard. Of course, there’s much more to consider, and I intend to return to these pages shortly to discuss other options (for production) to further help you determine if the Liberty profile is what you need , based on you application and operational requirements.