Web developers have many options for the servlet containers they use to host Java apps. Included in these choices are both classic proprietary and a host of open source containers. For the typical Java application developer, the container that holds one or more Java applications together is fairly transparent.
From a non-techy’s perspective, servlet containers are largely redundant. The feature sets often overlap, so it seems to make little difference whether Java developers build on Apache Tomcat or Jetty, two popular open source containers, or JBoss or Apple’s WebObjects, two well-known commercial versions.
Why so many choices? For the same reasons as there are numerous versions of the Linux operating system. Feature sets, corporate policies, budgetary restrictions, and scalability are among the deciding factors in choosing a suitable container.
“We don’t see absolutely anything on the horizon to replace this technology. Servlets are based on specifications. Version 3.0 is coming out next year,” Rich Sharples of the middleware business unit of Red Hat, told LinuxInsider.
What It Does
Servlets are frameworks for handling Web requests and responses from one or more Java apps. For instance, a request could be to send back a page. The servlet can construct a page dynamically, explained Sharples.
From a Java programmer’s perspective, servlets are among the lowest of programming levels. They make it much easier to construct pages, noted Sharples. A container is the run-time engine that the servlet uses. It handles tasks like currency and scalability.
“Together they take the system level tasks away so programmers just have to worry about the code for the Java app,” Sharples said.
Why the Variety?
Java developers have a number of container options from which to choose. Containers were developed in response to different market needs and prices.
“So many container choices came into play because different feature preferences caused different things to evolve. For instance, lightweight stacks are gaining more prominence with Web 2.0 apps. We are now into the second generation of this technology,” Jeff Hartley, vice president of marketing and products for Terracotta, told LinuxInsider.
Developers started creating proprietary containers to corral Java. But these products became bloated. Over time, people migrated to the open source options for cost and efficiency reasons. Each one began to develop its own following and ecosystem, he explained. Terracotta developed Java infrastructure software that allows users to scale their applications to as many computers as needed without expensive custom code or databases.
Uncontained History
Obviously, there is a close dependency between one or more Java apps and the container in which they exist. At first, the technology was not needed.
In the early days of Java development, Java apps mostly ran in isolation — known as “POJO,” or plain old Java operations. A single Java app does not need a container.
But as Java apps become more prominent, developers created container technology to help code writers unite services with other devices. Now containers also hold ancillary services, Hartley noted.
What’s Out There
Perhaps the most well-known non-commercial Web container is Apache Tomcat, an open source product available under the Apache Software License. The Apache Tomcat Project has become the defacto container, according to Red Hat’s Sharples. JBoss is a major contributor to Apache Tomcat.
Commercial Web containers such as WebObjects by Apple and WebSphere by IBM are heavyweights that include lots of services, said Terracotta’s Hartley.
Other non-commercial containers include Apache Geronimo, Jetty, Jaminid and Winstone. Other commercial Web containers are BEA Systems’ Weblogic Express, GlassFish and Caucho’s Resin Server. There are over a dozen more.
Do Differences Count?
“Some containers scale better than others. Clearly, there are some differences in each of the products,” Chris L. Merrill, chief engineer for Web Performance, told LinuxInsider.
Web Performance provides Web testing software to measure the performance of sites without having to develop scripts. The company last conducted tests on the leading containers in 2004. However, the measurements were designed to clock performance, not compare features.
“We focused on how the containers failed under load conditions,” he said.
The bench marking report is available here.
Making Choices
Much of the decision-making process in selecting a suitable container is often based on guesswork. Not everybody has access to load testing, so what his company offers helps people to make selection decisions, said Merrill.
“Most of the time the selection is based on a feature set and pricing. Licensing models also an influencing factor,” he added.
Many of the most popular containers are heavyweight products, noted Hartley. They’re packed — some might say bloated — with features and services, some of which are not needed for typical Java apps. Heavy or light, each container has relative benefits. A lighter weight container is often more cost effective.
“We’re seeing a trend where users are moving away from heavier weighted containers for more simple, less bloated ones,” Hartley said.
No Set Rules
Picking a container is much like selecting a car, according to Hartley. It comes down to personal preferences — or corporate edict.
“Often, what a company’s IT manager has used before or what the developmental team has used before makes the decision on what container to use. It is a matter of user choice for the feature differences and historical preferences,” he said.
Loading ...
