Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
Update: Since this post was published, RebelLabs has completed the full version of The Great Java Application Server Debate with Tomcat, JBoss, GlassFish, Jetty and Liberty Profile. Feel free to check it out!
This is the first blog post of a series in which we test-drive application servers from a developer’s perspective, and give our opinion on how they perform through our developer-oriented tests. This is more of a ‘how it did’ than a ‘how-to’. We start our series with a relatively new offering from IBM, the Liberty Profile.
Caveat – Yes, I’m an ex-IBM employee (who used to work on WebSphere Application Server) but hey, ZT pays my way now, so this is an accurate, genuinely non-biased, opinionated blog post which does not take my past into consideration – True Story.
The Liberty Profile is both part of the full IBM WebSphere Application Server image and a standalone download. It’s an Application Server that targets developers needs in an environment where the full WebSphere product is not ideal or appropriate. It was first available in WebSphere Application Server v8.5, released in 2012. Let’s be fair, WebSphere Application Server hasn’t had a good image among developers in the past, due to performance, size of download and complexity reasons. In fact, it has been referred to as WebsFear in some circles in the past. The Liberty Profile set out to change that image, so let’s see how it did.
First contact – Download and Install
Usual downloads with large corporates require you to give information such as your shoe size, pet’s name and BMI in order to download, but the Liberty Profile flips this on its head quite substantially for two reasons. Firstly it offers two download options – you can just grab the runtime directly, or download the tools and get the server through your tooling, neat. The second ‘shock’ is that you don’t have to provide any information to download or install, you just need to accept the licence agreement, which we’ll talk about later. IBM have really lowered the barrier to entry here and I’m sure it will pay off for them. Well done IBM!
Read the complete Java Application Server Report where we discuss the pros and cons of App servers such as: Tomcat, Jetty, GlassFish, IBM WAS Liberty Profile and JBoss (aka WildFly):
Back to the install… As I wanted to download the tools as well, I decided to go down that route. Indigo is the suggested level of eclipse (for some reason) but Juno is also supported, so I went for the latest and ‘greatest’ version of eclipse, Juno. The tooling takes the form of an Eclipse plugin that took just over 7 minutes to install including an eclipse restart, which was all a bit boring but p2 should take a quite a bit of the blame for that (13MB content.xml file and more). Hang on… back up – The tools are an eclipse plugin. They’re now lightweight, free, sit on your existing eclipse installations and don’t require you to download and install a gazillion GB of Rational Application Developer on a development machine, which is almost the polar opposite of what a developer wants on their development machine.
Once the tools were installed and eclipse restarted I could download and install my server (41.4 MB) in just over a minute – I expect most existing WAS users are quite shocked at this, but most other lightweight appserver users are shrugging their shoulders. Either way, I’m sure you’ll agree this is great progress for a large corporate which has done things very differently in the past.
Startup performance – restart/redeploy
Note to JRebel fans – app server restarts and app redeploys are the things other people do when they want to waste their time ;o)
The Liberty Profile is constructed in a modular and dynamic way such that its runtime is constructed to suit the applications running on the server. This means if your app doesn’t use specific functionality, your runtime doesn’t load it or start it. This leads to a much faster startup time.
We need an application to test on the Liberty Profile, so we’ll try a couple in varying sizes. Firstly the petclinic application which has the spring framework, hibernate libraries, and others.
On my macbook air (spec shown below) the petclinic app took approx 15 seconds from “Run As->Run On Server” till my petclinic application was visible. This includes deployment, application server startup and initialization time. A redeploy (including reinitialization) of a change took just over 5 seconds. Not bad for a small app.
Let’s now look at a bigger application. Jenkins is a 53MB web app, which I copied across to the hot deploy folder that the Libery Profile supports and the app is installed and started as soon as it sees it. From the console log, the application starts in 0.73 seconds and after 4 seconds of initialization, the app is ready to use. Pretty impressive.
[AUDIT ] CWWKZ0001I: Application jenkins started in 0.73 seconds.
Tooling support – how good is the best, how good is the worst
The Liberty Profile tools, named “IBM WebSphere Application Server Developer Tools for Eclipse” (a product name that almost needs punctuation) is only supported on the Eclipse platform. One of the things I’ve realised since leaving IBM is how many IntelliJ IDEA and NetBeans users there are out there. While IBM do want to cater to it’s own audience I do think it’s a kick in the teeth to all other developers who don’t use eclipse to force people to use the tools which IBM dictates you should use. The tools let you download and install the whole server easily, and provides feature rich development for the programming models which the Liberty Profile supports. It also provides rich editor support for server config changes in a similar style to a deployment descriptor editor which you’ve likely seen/used.
Overall the tooling is good, on Eclipse, although there were a number of times the server state was out of sync with the tooling which got annoying as there were lengthly delays in waiting for the tools to catch up, which stacked up my other user actions and made my dev environment useless. This happened more than once and is very painful as it does bring development down to it’s knees as everything is dependant on the previous task completing.
Open standard’s compliance
IBM is pretty hot on compliance and standards (often more so than anything else) so it’s no surprise to see the Liberty Profile following the same path. Although version 8.5 of the Liberty Profile is not compliant with Web Profile, the latest Beta is. The Liberty Profile also supports standardised OSGi applications and allows users to create bundles and applications they can deploy and run on the server.
Ease of Config change
The Liberty Profile really does excel when you look to the config. I feel like I always want to compare the Liberty Profile to the full profile of WebSphere purely becuase parts of it are soooo much slicker and, well, generally better. This is probably more of as a result of the poor config model the full WebSphere server has, but the Liberty Profile is more than comparable to other lightweight servers out there today with config. Let’s take a look at the config we get generated from a newly created server:
<server description="new server"> <!-- Enable features --> <featureManager> <feature>jsp-2.2</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="localhost" httpPort="9080" httpsPort="9443" /> </server>
Let’s give existing WAS users a moment to pick up their bottom jaw… This is the only config the server has. It’s simple, to the point and uses convention over configuration. As new ‘features’ are added to this config file, they are added to the runtime dynamically, without a server restart required. ALL config for the server can go into this file, and it can optionally be split up for ease of management or sharing.
This sucks! The Liberty Profile does not provide an administrative console to perform useful actions like updating the server config or installing/uninstalling applications etc so you’re stuck with the eclipse editor to update the server.xml, or just going in manually. There is a web app called the Liberty Profile Admin UI Tech Preview, which is a admin console beta download. I had a quick play but it has extremely basic functionality and for some reason provides it in a mobile app look and feel even on the browser, which simply isn’t good enough in todays environment when browser fronted applications can provide such a rich interface. All in all, the Tech Preview feels more like a very light on features status app which you might want on your mobile device, rather than any useful kind of usable management console.
Config Change & Turnaround time
WebSphere users who are used to multiple and large config files scattered across numerous directories will be very pleasantly surprised with the new config model, not just being a single file, but so small, as mentioned earlier. The dynamic runtime allows the server.xml file to be altered, reloaded on the fly (JRebel likey) and visible to the application instantly.
The lack of EJB and CDI support in Version 8.5 is very noticeable, as well as the lack of inbuilt messaging. As a result the Liberty profile doesn’t support the full Web Profile technologies, but interestingly additional effort has been put into OSGi application support instead. I think many would have preferred EJB and CDI support, particularly looking at the requests on the WASdev forums. The latest beta of the Liberty Profile, however, does contain increased support including EJB, CDI, WebServices and some really interestingly product extension support, which allows users to create their own ‘feature’s in the server.xml file, but this is still in Beta.
Team effectiveness, Documentation & Support
The Liberty Profile is a sharable developer app server. By this I mean it allows for great collaboration among other developers in the same team by providing the following:
- A server.xml that can be moved to any other Liberty Profile server instance
- Support for server.xml snippets that can be imported into an existing server.xml. The snippet takes the same format as the server.xml and can be shared across the team
- The eclipse tooling creates a new project in the workspace, per server, which allows you to check in config files to your favoured repository easily.
- Servers can be ‘packaged’ into an archive and extracted onto other machines to easily share with other developers in the team, or even other test stages etc if you just wanted to duplicate your environment
Documentation can mostly be found on the new community site wasdev, which is non-typical in terms of the traditional IBM sites, but still suffers from the hangover of developerWorks performance and format. It’s run by the development team so isn’t full of the usual marketing/sales. There is also the traditional IBM information center, which people typically love or hate, that provides more formal documentation for the product. You can get support from the wasdev forum which is reasonably active, and again, you’re talking with the development team, this is on a best can do basis. If you choose to pay the big bucks you’ll also get the full IBM support where you can even afford to scream and still expect help :o)
Things that didn’t fit into other sections
One feature which is pretty nifty is minify, which takes your Liberty Profile server and removes everything your application doesn’t need leaving you with a much smaller footprint. This sounds like a feature you could use once you’ve finished making your dynamic development changes and just want to reduce the footprint and make the server as fast and small as possible.
You’re now able to use the Liberty Profile on a mac, which most devs wouldn’t be too shocked at, but most existing WAS (and mac) users might have just broken into tears (in a good way).
There is no migration story from the Liberty Profile to the full profile of WAS, which means if you wanted to develop your application on the Liberty Profile to make use of its lightweight nature but use full WebSphere app server in production, you’ll need to map the server config yourself. It would be nice to see a tool which mapped your server.xml to a bunch of jython scripts that could create the same environment in full WAS.
The Liberty Profile is free to use, but only in development. If you wanted to move to production with the Liberty Profile you’ll need to pay the usual WAS bucks. Sadly there is no license for using the Liberty Profile outside of development for your hobby usage. So if you wanted to run an app server for a home project, you’re not licensed to do so with the Liberty Profile :o(
Overall, the Liberty Profile is one of the fastest changing and most interesting app servers to watch on the market today. Don’t look at it as just another WebSphere app server, take a look at it with a fresh and open mind and I really think you’ll be impressed with it. The new Beta is just as exciting with some great new features.
On the downside, it comes at a cost. Yes, development is free, but the world doesn’t stop at development and the cost curve to use it outside of development is very steep, particularly in comparison to other lightweight servers out there today, many of which are free.
As the Liberty Profile is new and rapidly moving, it looks like the biggest focus is on feature and technology support rather than some of the fluffier aspects such as UI and migration, but it needs to focus on these aspects because in reality, devs will be comparing this server to Tomcat and Glassfish which have already been around for many years and the Liberty Profile is playing a catch up game to these servers.
It’s important to IBM there is a good answer to the question, “Why would I use the Liberty Profile over Tomcat”. Ease of use, particularly around config, is one of the big reasons here for me, but it realistically depends on the requirements of your application and if the Liberty Profile doesn’t support the features you need, it’s not even in the equation. The most compelling reason to use the Liberty Profile, in my mind, is if you’re already decided to use WebSphere in production. IBM have put together a doc comparing the Liberty Profile to Tomcat.
It’s certainly one to keep an eye out for going forward. I personally know the main developers and architects on the Liberty Profile such as Ian Robinson, Alex Mulholland, Alasdair Nottingham, Erin Schnabel, Tim DeBoer and many more. They should take a lot of credit for the changes you’re seeing in the Liberty Profile and are individually responsible for the great new direction and results it has already achieved.
It will be interesting to see how the Liberty Profile handles the increase functionality with both footprint and size and what this means to the wider portfolio of WebSphere Application Server products as the Liberty Profile improves and increased in scope in the future.
I hope you enjoyed this post – let me know what your thoughts are around WebSphere and the new Liberty Profile in the comments below or tweet us @Rebel_Labs. Existing WebSphere users – What do you make of the new changes? Non WebSphere users – Would you consider looking into/using the Liberty Profile?