Almost two years ago (wow, hasn’t time flown by!) we ran a report on application servers, specifically around developer productivity and user experience. The WebSphere Liberty Profile (WLP), a lightweight WebSphere profile was new to the scene at the time, in comparison to others in the report.
However, since then it seems to have had many new features and additions which we’ll look at in this blog post. In fact, we’ll stay true to the report style and check out what has changed in the most interesting categories, including:
- Download and installation
- Tooling support
- Server configuration
- Documentation & community
- Real performance metrics
- Features & Open Standards compliance
- Administration & Management/UI
So, we start with the download and installation. Starting at the WASdev site, we’re given a couple of options of how we can get the runtime on our machine. Either we download the runtime directly and work through the command line, or we download via Eclipse after installing the WebSphere Developer Tools Eclipse plugin.
I did it both ways to see how easy they were. The plugin is a standard install with another license agreement I tend not to read although probably should, followed by an annoying restart of Eclipse. Then you add a new server, which is fairly standard, although when looking through the list of add-ons, there were 96 (yah, I counted them) integrations, samples, clients and features I could have chosen.
Kind of overwhelming for new users, and not exactly what I wanted to see on a simple install, but I carried on without selecting any further options. One more license acceptance and install later and I have a new runtime on my machine. Creating a new server was very straight forward and I can start it in Eclipse in the usual manner. Overall, a reasonable experience. Oh and there’s also the option to download the update site to host locally for enterprises that don’t allow access to the marketplace, which is nice. Out of curiosity I tried to download and noticed it was 400MB – WOW! That said, this isn’t the kind of thing the average developer will need to download.
The raw download of the runtime from WASdev was pretty standard too. Although the IBM lawyers still see it necessary to have a license agreement on install, plus a license agreement and additional license agreement on extraction (I guess they can sleep easy though). Interestingly the extended version only seemed to install over an existing Liberty Profile version, meaning I had to download both, and yep, you guessed it, accept the license agreement and additional license agreement on extraction. Not a great deal to skip and agree to, but I do start to wonder how many of my children IBM actually own.
Next, onto Tooling support, and as we’ve already seen Eclipse support is good and always was for install. I also noticed I was still able to open my server configuration in a rich editor for editing:
I was most keen to see how the other IDE support had improved as it was certainly something that was missing the last time I looked at the Liberty Profile.
Out of the box support does exist on IntelliJ for recognising a Liberty Profile Server and deploying onto it, but there’s little else you can really do compared to the nice features eclipse provides, like the server configuration, download & installation etc. This is a real shame for those developers already using IntelliJ, but I guess in the bigger IBM shops, most are RAD/eclipse focused. Netbeans doesn’t seem to have any support at all as this bugzilla report from Dec 2014 would suggest, so if you’re a Netbeans user wanting to play with the Liberty Profile, you can vote for it there!
Maven support was always very good and there’s a great new listing on WASdev with Github repositories which include integrations with Gradle, Ant, Chef and Puppet scripts too – nice job.
Server configuration was always something of a huge plus point for the Liberty Profile, with it’s dynamic OSGi based services runtime that reacted instantly to configuration changes plus the extremely lightweight config file that isn’t more verbose than it needs to be. I remember last time I looked it had seven or so lines of config, let’s look again:
<?xml version="1.0" encoding="UTF-8"?> <server description="new server"> <!-- Enable features --> <featureManager> <feature>jsp-2.2</feature> </featureManager> <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" --> <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" /> </server>
Pretty much the same – 7 actual lines of XML, with 2 lines that really carry interesting information. Well done IBM and the WebSphere team! It’s all too easy to add to this kind of file and give it bloat and unnecessary config and I think they’ve been extremely disciplined to keep it down to these 7 lines.
What’s more, there’s an interesting way you can now add features. To jog your memory, features are the component modules of the server. If you want to use JDBC, you add the JDBC feature, if you want to use OSGi, you add the blueprint feature. So that new interesting thing… The Liberty Profile Repository hosts a large number of additional features which you can install and use in your runtime. This nicely searchable page provides you with the ability to pull down just what you need and install that – a testing nightmare? Yes, I’m sure it is, but let’s leave that with the IBM folks.
Oh hang on, this is the same vast list of add-ons that we saw at server creation during our installation! I think it’s more relevant now, given we realise at this stage what is and isn’t included in our installation rather than at install time, particularly for a new user. To be honest, I think I’d be more likely to install once and clone that environment than go through installation time and time again anyway. It would be super cool if you could mention a remote feature in a server.xml and have the runtime go and download it from the repository and then use it, but that isn’t available at the moment.
Well, the Liberty Profile still scores very highly on server config, and it’s ability to change at runtime in a Mystique style makes it all the more pleasurable to work with from a development point of view.
Documentation and community was an interesting one for the Liberty Profile, as in the past it was noticed that it had a good site, with reasonable tech info (There’s even one about how to use the Liberty Profile and JRebel, if you have time to read one, pick this one, it’s an instant win!), but as it’s still a newish profile, it struggles with community numbers, certainly in comparison with the likes of Tomcat or Jetty where you might expect to hear of many who have similar config problems or exceptions that can help you. The site looks to have got a lot more content, particularly around integrations and samples which really do help. Kudos to Laura Cowen and others for making that a really resourceful site.
In the last report, the Liberty Profile didn’t fare too well when it came to the speed test, so we’re going to run the same tests on the latest version to see how it looks these days. First, I must start with the fact, that this is just on my MBA and not overly scientific, but will give a good gut feel on how the app server has changed. I actually still had the previous version of the Liberty Profile on my mac which I ran previous tests on and after rerunning the tests on that install, the results I got today were very comparable with when I ran them previously, so lets see how the new version stands up.
|Task||Liberty Profile 188.8.131.52||Liberty Profile 184.108.40.206|
|Empty server startup||2||2|
|Server startup time with petclinic installed||3||2.5|
|Server startup time with jenkins installed||8||4|
|Petclinic app deploy time||2.5||1|
|Jenkins app deploy time||5.5||2|
|Petclinic init time (1st req)||4||8|
|Jenkins init time (1st req)||8||21|
|Server startup, deploy petclinic & invoke||10||11|
|Server startup, deploy jenkins & invoke||16||25|
OK, so clearly some serious improvements have been made, particularly looking at the last number, and on initialization time. On just looking at the numbers it looks like an amount of the initialization of the application is done more on deploy of the application or start up of the application server, rather than the first time the application is invoked. I think this is a good thing, as a 21 second wait previously for a jenkins init was just too long.
Not that we can compare this latest version of numbers to previous versions of the other application servers as that clearly wouldn’t be fair, but I would bet it would really stand up against them today and be among the fastest of the servers. Perhaps another number run with all the app servers is in order!
Feature wise, the Liberty Profile has hit a milestone since my last blog on the server, achieving Web Profile compliance at Java EE version 6 (Since WLP v 8.5.5), although it’s not full profile Java EE compliant yet at any version. So congratulations and it’s going to be interesting to see if it goes for the full Java EE profile compliance. On top of the Java EE 6 features, it also supports some JSRs from the Java EE 7 specification, including Java Servlet 3.1 (JSR 340), Java API from WebSocket 1.0 (JSR 356) and Java API for JSON processing (JSR 353).
One other part that was considered lacking, in our last Liberty Profile review was the server administration, outside of hacking XML. Yes, there is the rich eclipse editor, but at the time that only worked for local managed servers, and specifically in the Eclipse IDE. While this remains very Eclipse focused, you are now able to configure and manage remote Liberty Profile servers from an Eclipse instance which is a big advancement. But how about an actual administrative console? Well, a quick repository search unearths the following:
So two options, I tried the top one briefly, but ran into SSL problems. I believe it’s the ‘mobile friendly’ admin version which I didn’t get on with the first time I ran a review, but the admin package I believe to be new, so I moved onto that next. This required a download, and yeh, more license agreement followed by an installation not too dissimilar to the product itself. This time I got the following:
The specified product installation is at version 220.127.116.11 and this product addon only applies to version 2015.1.0.1.
So while I was really interested in seeing the admin console, I couldn’t yet, but will try to do so in future and update this post!
I must say that it’s been a very pleasant experience all in all, playing with the Liberty Profile again, to write this post, and as one of the more exciting application servers on the market today, it’s exciting to watch it change and looking forward, see what’s coming around the corner. I’m sure many existing WebSphere users fear the worst going forward that the Liberty Profile might turn into a more bloated version, like it’s big brother, the full WebSphere profile, but kudos to the team, they’ve stuck by their theme and have kept the Liberty Profile lightweight and developer friendly.
My biggest fear for the Liberty profile is where their users come from. Is the Liberty Profile a tool that a green field developer would use for a new project? Or is it a great tool that companies who use WebSphere in production will use in development. I’d love to think it’s the former as it does have great potential, but right now I think it’s in the latter category, giving existing WebSphere developers a deserved breath of fresh air. It’s going to take a lot of hard work and education to make the Liberty Profile a contender in developer’s minds as well as a contender just on paper.
Do you have any experience with WebSphere Liberty Profile, what are your thoughts on it? Write to us in the comments below, or join the conversation on Twitter: @sjmaple.