Software developers have a lot of tools at their disposal when building modern applications with Java application servers. One of the many trends is the use of lightweight application servers. There is no strict definition of “lightweight”, but generally speaking these are products that have small disk and memory footprint and simple administration model.
Historically WebSphere and WebLogic application servers have been nicely suited for heavy lifting applications trying to replicate CICS mainframe style of computing for distributed platforms. This came at a cost of having significant disk and memory footprint as well as sophisticated configuration (think of the Boeing 747 cockpit with all of the knobs and controls). Not every application needs all that power, flexibility and sophistication.
Enter the world of Tomcat and Jetty. These are minimalistic servers that have very small footprint and simple administration (albeit simple does have its costs when you need to scale). To address this need IBM has shipped WebSphere Liberty Profile back in 2012. A year later, on June 14, 2013 IBM shipped new version of its WebSphere Application Server 8.5.5 along with a significant feature updates in the Liberty Profile. Oracle also has a play in the lightweight server with its GlassFish runtime, however unlike IBM Liberty Profile, it is a separate code base and separate project from Oracle’s flagship WebLogic Application Server. IBM has done something different with its Liberty Profile – taking the proven WebSphere code and refactoring it on the OSGi platform with rebuilt and simplified configuration and systems management, shipped as part of the WebSphere Application Server, calling it Liberty Profile (you can install both if you want). Some interesting facts about the IBM WebSphere Liberty Profile:
- Download size: 50 MB
- Installed size: 67 MB (20 MB for the “minimized” version)
- Install time on developer machine: under 10 seconds
- Startup time: about 2 seconds
- Number of configuration files: 1
As you can see, IBM has created a small and simple application server, but very important is the fact that it is based on largely the same code base as the WAS. This means you get proven product in a new simpler and smaller package. Last year I posted a short article comparing Liberty Profile and Tomcat along with the link to an IBM white paper.
If you are developer, you might ask why bother with Liberty Profile if you could use Tomcat? Here we come to the core of my post. I am yet to see anyone using vanilla Tomcat in production. The conversation starts with “plain” Tomcat, but once you look under the hood, you find many other containers and 3rd party projects bolted on top of the Tomcat engine. Need SOAP? There is an “app for that”. Need REST? There is an “app for that”. Need JPA? There is an “app for that too”. Batch? SAML? Oauth? JAX-RS? JTA? CDI? And the list goes on and on. You get the picture. In the end, you the developer end up building a fairly complex assembly of dozen (or more) of open source packages on top of your “vanilla” Tomcat. This often causes all kinds of performance, compatibility, security and management issues. IBM has seen all of that and created Liberty with full Java EE 6 Web Profile support plus more.
Why does the programming model matter? Here are some reasons why I think it is important to make an intelligent choice about your Java runtime and programming model:
- You may not know all of the requirements for your application when you first start building it. At first it may be the case that Tomcat covers all of your needs, but two weeks later you will inevitably start adding all kinds of different packages and OSS projects to Tomcat.
- The reason you start adding those new packages is to accelerate your development or make it easier. Good examples of such APIs are CDI, JMS, OSGi, Bean Validation, JPA, EJB Light, JSF, etc. How do you build an application without these APIs? Building frameworks from scratch? Using JDNI lookups? Coding low level JDBC? Hell no. This is past century.
- Once you start using annotations in your Java code and then add those other frameworks, your startup and runtime performance suffers because of repeated jar file scanning that is done multiple times instead of once.
- Classpath dependencies also become problematic when you start using many independent open source projects in your Tomcat.
- How about security model? Does your user security context or transaction context flow with the request? Likely not.
- You might argue that you can get a lot of the programming model covered with Spring frameworks. True to some extent, but there are few problems with Spring. For one, it is proprietary programming model and you get stuck with no choices, but Spring itself. With Java EE you get choices for runtime. Second, Spring is not all that bleeding edge any longer and many programmers would argue that Java EE is easier to use than Spring is. Third, if you need production support, you need to pay for Spring (buy it as part of tc Server from VMware) – the cost is quite similar to IBM Liberty Profile and higher in some cases. Fourth, performance is not always that great with Spring, especially when compared to IBM Liberty Profile or full WebSphere Profile. Fifth, VMware tc Server Spring Edition or vFabric Suite are supported on a very small set of platforms and operating systems. Did I mention Spring is proprietary? Haven’t we learned that lesson soooooooo many times already with proprietary programming models?
- How do you manage and monitor this environment built from dozen(s) of packages? Do those packages use the same tracing mechanism (most of them likely use Log4j) or do they use its own unique method? How many log files do you need to read?
- Each 3rd party package drags its own set of dependencies, thus growing the size of your footprint (both disk and memory).
- Does your development tool provide anything mode than basic code assist?
- Are you forced to restart your Tomcat every time you make configuration change? (Liberty does not need to be restarted)
Having a product (such as IBM Liberty Profile or full WebSphere Profile) built for you with APIs and facilities out of the box means that most if not all of the problems listed above are solved for you, including:
- Comprehensive set of APIs – industry standard
- Improved startup times (Liberty will likely start faster for real applications than Tomcat with all those packages bolted on)
- Faster production performance (tests do show that Liberty is about 25% faster than Tomcat)
- Smaller footprint (Liberty provides comparable footprint to Tomcat on disk and smaller memory needs when you deploy realistic applications in it)
- Simplified monitoring and management (Tomcat management is done primarily via files editing)
- Consistent logging (IBM includes High Performance Logger in Liberty)
- Proven security model (all components of Liberty share security model)
- Productive development tooling (IBM provides free plugin for Eclipse and free development license for Liberty)
- Single point of support (you call IBM with any questions you have, development support is included for free if you have at least one production license)
Take a look at the table below to see the programming model comparison between WAS Liberty, WAS, Tomcat, VMware tc Server and JBoss.
(*) – more than one possible 3rd party package is available to fulfill the required capability (not sure how well it will work with Tomcat though – that would be an exercise left to developer)
(1) – Java SE runtime is included and supported with IBM products, but 3rd party JVM is required for Tomcat and vFabric. JBoss only provides OpenJDK support on RHEL – on all other platforms it requires 3rd party JDK support (or using non-supported JDK – such as free download of Oracle Sun HotSpot JDK)
(2) – TomEE is a special bundle that includes Tomcat and complies with Java EE 6 Web Profile, but it is very new and relies on a great number of 3rd party packages. Some of the packages come from Apache Geronimo, other packages come from other independent projects. TomEE today has no support from any major corporation.
(3) – JMX support in Liberty is enhanced with REST API, and great number of reusable Jython sample scripts provided with the product.
(4) – Jersey is a reference implementation for JAX-RS and can produce JSON. There are other JAX-RS libraries that can be used with Tomcat. WAS supports JAX-RS and JSON out of the box with no need to add 3rd party libraries.
(5) – vFabric includes RabbitMQ, but RabbitMQ does not support JMS API (it does provide a proprietary API for Java, but it is not JMS, it also provides APIs for several other languages).
(6) – just like with Tomcat, developers can use many 3rd party libraries with Liberty Profile, but similarly to Tomcat those will need to be tested and supported at developers’ own effort.
(7) – same as above applies to tcServer – developers can plugin many 3rd party plugins, but need to do integration work on their own and do self support. Same packages that can be plugged into Tomcat are very likely to plug into tc Server – some additional assembly, testing and maintenance will be required.
(8) – same as above for JBoss
(9) – JBoss JMS is based on immature HornetQ implementation and is now being replaced by ActiveMQ (according to announcements made at JBoss conference 2013 in Boston). In the future ActiveMQ will become default provider of JMS in JBoss.
(10) – JBoss transaction recovery does not work in some cases and fails to recover transactions – if you are interested to test it yourself, please send email to firstname.lastname@example.org.
(11) – vFabric tc Server does not ship Java EE 6 Web Profile, but a lot of features could be plugged into it to run some of those APIs – however VERY significant assembly is required at the cost of high labor and performance degradation (repeated jar file scanning, memory and security issues, etc.).
(12) – Tomcat support for JAAS does not allow to take full advantage of JAAS capabilities without significant tweaking and labor. Google search shows some of those issues. It can be done, but not out of the box and is not trivial.
(13) – Tomcat provides Read-only JNDI tree.
More info information about WAS Liberty Profile features can be found on the http://wasdev.net.