Programming model support in Java servers (update)


Article updated: September 15, 2015

A lot has happened in the last 2+ years since I wrote the original version of this article. It is time for an update.

Software developers have many different tools at their disposal when building modern web applications. One of the (not so new) trends is the use of lightweight application servers, described in my earlier blog post titled “Developer point of view on the App Server debate“. There is no strict definition of “lightweight”, but generally speaking these are products that have a small disk and memory footprint and a simple configuration model.

Historically WebSphere and WebLogic application servers have been nicely suited for heavy lifting applications trying to replicate the CICS mainframe style of computing for distributed platforms. This came at a cost of having significant disk and memory footprint as well as sophisticated configurations (think of the Boeing 747 cockpit with all of the 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 footprints and simple administration (albeit simple does have its costs when you need to scale). To address this need, IBM shipped the WebSphere Liberty Profile back in 2012. IBM has been investing heavily into the Liberty Profile and by refactoring components from full WAS Profile into Liberty, IBM was able to develop a very robust and feature rich, yet lightweight server, and became the first major vendor to ship a full Java EE 7 certification for production use. At the time of this writing JBoss EAP and WebLogic are still not Java EE 7 certified.

Oracle also has a play in the lightweight server with its GlassFish runtime, however it is a separate project from Oracle’s WebLogic Application Server. What is more important, Oracle has discontinued commercial support for GlassFish.

IBM has done something different with its WAS Liberty Profile – taking the proven WebSphere code and refactoring it on the OSGi platform with a rebuilt and simplified configuration and systems management, and shipping it as part of the WebSphere Application Server (Tom Alcott has written a good article on this subject). Some interesting facts about the IBM WebSphere Liberty Profile:

  • Download size: 63 MB for Java EE 7 Web Profile and 94 MB for full Java EE 7 server
  • Installed size: 71 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 classic WAS. This means you get a 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 a 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? EJB? WebRTC? JMS? 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 several dozens of open source packages on top of your “vanilla” Tomcat. This often causes all kinds of performance, compatibility, security and management issues.

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 3rd party 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 JNDI lookups? Coding low level JDBC? Hell no. This is the past century.
  • Once you start using annotations in your Java code and then add those other frameworks, Tomcat startup and runtime performance suffers because of repeated jar file scanning that is done multiple times instead of once (this is optimized and performance-tuned in Liberty).
  • Classpath dependencies also become problematic when you start using many independent open source projects in your Tomcat.
  • How about your security model? Does your user security context or transaction context flow with the request? Not at all.
  • You might argue that you can get a lot of the programming model covered with Spring frameworks. True to some extent, but there are a few problems with Spring. For one, it is a proprietary programming model and you get stuck with no choices, but Spring itself. With Java EE you get choices for your 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 (just google articles on this subject). Third, if you need production support, you need to pay for Spring (buy it as part of tc Server from Pivotal) – the cost is quite similar to the 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, tc Server is 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 logging and tracing mechanism (most of them likely use Log4j) or do they use their 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 any other mode than basic code assist?
  • Are you forced to restart your Tomcat every time you make a 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 Java EE 7 programming model
  • Improved startup and deployment times (Liberty does start faster and deploys applications faster than Tomcat and JBoss for real applications)
  • Faster production performance (tests do show that Liberty is much faster than Tomcat and JBoss)
  • Smaller footprint (Liberty provides a 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 the High Performance Logger in Liberty)
  • Proven security model (all components of Liberty share a security model)
  • Productive development tooling (IBM provides a free plugin for Eclipse and a 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 full profile, Apache Tomcat and TomEE, Pivotal tc Server and Red Hat JBoss EAP:

api-support-in-websphere-liberty-jboss-tomcat-tcserver-tomee4

Notes:

(*) – indicates capability available in Liberty Base and ND (not available in Liberty Core)

(SoD) – indicates Statement of Direction, meaning that this capability will be available in the near future.

Visit this documentation page for a complete list of all supported features in WAS Liberty.

As you can see from the table above, Tomcat, TomEE and tc Server are missing most of the APIs, however it is possible to add 3rd party packages to get the function. Here are some additional considerations and comments that could not fit into the table above:

  • A Java SE runtime is included and supported with IBM products, but a 3rd party JVM is required for Tomcat, TomEE, tc Server. Red Hat provides OpenJDK support on RHEL – on all other platforms it requires 3rd party JDK support (or use of a non-supported JDK – such as a free download of Oracle Sun HotSpot JDK)
  • TomEE is a special bundle that includes Tomcat and complies with the Java EE 6 Web Profile (not even version 7 yet), 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.
  • JMX support in Liberty is enhanced with the REST API, and a great number of reusable Jython sample scripts are provided with the product.
  • Jersey is a reference implementation for JAX-RS. 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.
  • Pivotal App Suite includes tc Server and RabbitMQ with the older JMS 1.1 client.
  • Just like with Tomcat, developers can use their favorite 3rd party OSS libraries with Liberty Profile, but similarly to Tomcat those will need to be tested and supported at the developers’ own effort.
  • Same as above applies to tc Server, TomEE and JBoss EAP – 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.
  • JBoss EAP used to be shipped with HornetQ messaging which is now being replaced by the hybrid rewrite of ActiveMQ and HornetQ.
  • Pivotal tc Server does not ship with support for the 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.).
  • Tomcat support for JAAS does not allow taking 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 it is not trivial.
  • Tomcat provides a Read-only JNDI tree.

More info information about WAS Liberty Profile features can be found on the http://wasdev.net.



Categories: Technology

Tags: , , , , , , , , , , , , ,

4 replies

Trackbacks

  1. Programming model support in lightweight Java servers | WhyWebSphere Blog
  2. New version of Liberty brings some new cool features | WhyWebSphere Blog
  3. Lightweight Java servers and developer view on the App Server (update) | WhyWebSphere Blog
  4. The state of WebSphere Application Server business – IBM Advantage Blog

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: