By Brian Proffitt on Wednesday, April 27th, 2011. Ref From OPENLOGIC
The open source application servers compared in this article, with descriptions from their respective Web sites, will be:
The role of application servers has grown significantly in IT architecture over the past few years as the cloud becomes the new frontier for application development–a frontier that offers more opportunity and challenges than the Web ever did.
That’s not to say that the Web space is over and done. We have come a long way from simple CGI requests, and Java-based application servers dominate the application server space on the Web, handling everything from interfaces and data access to availability and scale.
Now, though, the client-server model of the Web has become very blurred. If clients are indeed everywhere–and there’s no reason to think they aren’t–then the place where the applications run suddenly becomes very un-localized. Application servers manage it all, but as the power division between client and server becomes ever more diffuse, the complexity of management becomes greater.
And that’s just the Web.
Now picture an environment where the servers themselves are virtualized pieces of information that can be stopped and started at will, based solely on the needs to the task to be done. This process of management and scaling, if automated appropriately, is what makes the cloud ecosystem and applications servers now need to work in this type of environment as well.
It won’t be easy. Cloud adds another layer of compatibility to using application servers, over and above the compatibility issues with which application servers are already dealing. On the Web (and older client-server environments), application servers either work with a closed- or open-ecosystem model.
Closed ecosystem application servers, like WebSphere, provide application developers with a seamless byte-to-screen environment within which they can develop, test, and deploy their apps. It is, for some, blissful nirvana, since intra-environment creation and management of application servers is less stressful.
Of course, there’s the trouble that sets in if an organization discovers it needs to work with such applications inside another environment. It’s the age-old flip side of working with closed and proprietary systems: comfort and bliss if all you need is within that system; pain and torment should that system not need your needs and you need to migrate to something else.
Preventing that problem is part of the appeal of open-ecosystem application servers. This family of application servers, which are usually licensed under a free or open source license themselves, enables developers to code based on open standards, not the specific features of the application server itself.
Unquestionably, the most popular standard on the market today is Java Enterprise Edition (Java EE or J2EE). While some would argue the openness of J2EE, it is certainly more open than its closest competitor, Microsoft’s .NET implementation. While there are open source .NET application servers and frameworks (Novell’s Mono comes immediately to mind), many application developers feel that Microsoft will only tolerate these platforms for only as long as is necessary to propagate .NET in the application server space.
And that’s definitely an uphill climb. J2EE application servers (both proprietary and open) are quite dominant on the market today and there are no signs of that market lead declining.
But is a J2EE application server right for everyone? And how do the open source J2EE application servers stack up against each other and other open source application servers?
Matt Atwater, Senior Enterprise Architect at OpenLogic, cautions that knowing what features you need now and in the future are critical to choosing the right
open source application server. And, he emphasizes, those features should not be defined solely by the applications you are running.
“You need to make your decision based at the enterprise architecture level, not the application level,” Atwater said in a recent interview.
For instance, does your organization need a pure service-oriented architecture (SOA)? The J2EE standard is not conducive to SOA in and of itself, Atwater cautioned, but certain application servers provide plug-ins that can deliver SOA functionality.
“Another question might be, ‘Do I care about maintaining a whole product suite of tools or can I mix and match?’,” Atwater explained.
These are the types of questions an organization must ask when confronting the question of which application server to use. It must mesh with the goals of your IT infrastructure now and one, two, or three years down the road. Compatibility is also key.
“You don’t want to be supporting different types of application servers,” Atwater said.
You also should make sure of the overall purpose of the server you are using.
Apache Tomcat, for instance, is often cited as a prime example of an open source application server, but while it is very good at what it does, it is not a full-fledged application server. Tomcat is a servlet container that provides developers an HTTP environment upon which applications can run. It is also not fully J2EE compliant, since there is no native support for Enterprise JavaBeans (EJB) and only offers limited clustering support out of the box.
Still, Atwater said, that’s no reason to count Tomcat out. It’s lightweight and doesn’t have the J2EE overhead of other full-blown application servers and as such, it may be a better fit for your organization’s needs. Plus, Atwater added, there are variations on the market, such as from MuleSoft and SpringSource, that can fill in specific gaps for your deployment plans.
Beyond the feature set of the application server, Atwater explained, platform stability and reliability are important factors to consider. Community strength and activity is also very important for open source application server customers to consider. The reason is simple: the more active the community, the better they can help you and your organization when support is needed. It also speaks towards the long-term direction and viability of the server.
Direction is very important for potential users to consider. “Where’s the product going in the future?,” Atwater suggested as another important question. In the J2EE community, clarity of direction has never been more important.
That’s due to the Apache Software Foundation (ASF), makers of the aforementioned Tomcat and the full-J2EE compliant Geronimo application server, withdrew from the Java Community Process (JCP) in early December last year.
The ASF resigned its seat on the Java SE/EE Executive Committee and pulled out of the JCP, which serves as the governing body for Java innovation, due to serious difference of opinion with the main sponsor of the JCP: Oracle.
According to the ASF, Oracle, as the sustaining member of the JCP, has not granted a test compatibility kit (TCK) license to the ASF’s own Java implementation, Project Harmony, due to specific incompatibilities in the TCK’s license. Without the TCK, Harmony cannot be tested and certified against the Java standard. This effectively reduces the potential user base for Harmony, which the ASF claims is likely the reason why Sun Microsystems, the original sustainer of Java, inserted the incompatible language in the first place.
The resignation followed through on the threat ASF leaders made in early November of 2010, if the December vote on the Java Standard Edition 7 roadmap went through. In the December vote, only two of the 16-member JCP executive committee voted “no”: the ASF and Google.
The ASF has long maintained that denying individual JCP member rights was an abuse of power by Oracle (and Sun before it). Because of this, the ASF has leveled charges that the JCP is not a true open specification.
The effect of this decision is a little hard to determine: it seemed to immediately remove the ASF’s Java-related projects from the official Java banner–but that’s a bit of a moot point, since Project Harmony wasn’t officially compliant to begin with. Where Geronimo and Tomcat fit into this picture is still anyone’s guess.
This sort of guessing may not be something you and your organization will want to do, despite the high praise Geronimo and Tomcat have respectively received in their customer spaces. There is a chance the ASF and Oracle will work out their differences, but until that happens, it leaves the question of Apache products’ J2EE compatibility in a bit of limbo. (For the purposes of this article, the last-known technical compatibility features will be listed for these application servers.)
That’s not to say that the Web space is over and done. We have come a long way from simple CGI requests, and Java-based application servers dominate the application server space on the Web, handling everything from interfaces and data access to availability and scale.
Now, though, the client-server model of the Web has become very blurred. If clients are indeed everywhere–and there’s no reason to think they aren’t–then the place where the applications run suddenly becomes very un-localized. Application servers manage it all, but as the power division between client and server becomes ever more diffuse, the complexity of management becomes greater.
And that’s just the Web.
Now picture an environment where the servers themselves are virtualized pieces of information that can be stopped and started at will, based solely on the needs to the task to be done. This process of management and scaling, if automated appropriately, is what makes the cloud ecosystem and applications servers now need to work in this type of environment as well.
It won’t be easy. Cloud adds another layer of compatibility to using application servers, over and above the compatibility issues with which application servers are already dealing. On the Web (and older client-server environments), application servers either work with a closed- or open-ecosystem model.
Closed ecosystem application servers, like WebSphere, provide application developers with a seamless byte-to-screen environment within which they can develop, test, and deploy their apps. It is, for some, blissful nirvana, since intra-environment creation and management of application servers is less stressful.
Of course, there’s the trouble that sets in if an organization discovers it needs to work with such applications inside another environment. It’s the age-old flip side of working with closed and proprietary systems: comfort and bliss if all you need is within that system; pain and torment should that system not need your needs and you need to migrate to something else.
Preventing that problem is part of the appeal of open-ecosystem application servers. This family of application servers, which are usually licensed under a free or open source license themselves, enables developers to code based on open standards, not the specific features of the application server itself.
Unquestionably, the most popular standard on the market today is Java Enterprise Edition (Java EE or J2EE). While some would argue the openness of J2EE, it is certainly more open than its closest competitor, Microsoft’s .NET implementation. While there are open source .NET application servers and frameworks (Novell’s Mono comes immediately to mind), many application developers feel that Microsoft will only tolerate these platforms for only as long as is necessary to propagate .NET in the application server space.
And that’s definitely an uphill climb. J2EE application servers (both proprietary and open) are quite dominant on the market today and there are no signs of that market lead declining.
But is a J2EE application server right for everyone? And how do the open source J2EE application servers stack up against each other and other open source application servers?
Matt Atwater, Senior Enterprise Architect at OpenLogic, cautions that knowing what features you need now and in the future are critical to choosing the right
open source application server. And, he emphasizes, those features should not be defined solely by the applications you are running.
“You need to make your decision based at the enterprise architecture level, not the application level,” Atwater said in a recent interview.
For instance, does your organization need a pure service-oriented architecture (SOA)? The J2EE standard is not conducive to SOA in and of itself, Atwater cautioned, but certain application servers provide plug-ins that can deliver SOA functionality.
“Another question might be, ‘Do I care about maintaining a whole product suite of tools or can I mix and match?’,” Atwater explained.
These are the types of questions an organization must ask when confronting the question of which application server to use. It must mesh with the goals of your IT infrastructure now and one, two, or three years down the road. Compatibility is also key.
“You don’t want to be supporting different types of application servers,” Atwater said.
You also should make sure of the overall purpose of the server you are using.
Apache Tomcat, for instance, is often cited as a prime example of an open source application server, but while it is very good at what it does, it is not a full-fledged application server. Tomcat is a servlet container that provides developers an HTTP environment upon which applications can run. It is also not fully J2EE compliant, since there is no native support for Enterprise JavaBeans (EJB) and only offers limited clustering support out of the box.
Still, Atwater said, that’s no reason to count Tomcat out. It’s lightweight and doesn’t have the J2EE overhead of other full-blown application servers and as such, it may be a better fit for your organization’s needs. Plus, Atwater added, there are variations on the market, such as from MuleSoft and SpringSource, that can fill in specific gaps for your deployment plans.
Beyond the feature set of the application server, Atwater explained, platform stability and reliability are important factors to consider. Community strength and activity is also very important for open source application server customers to consider. The reason is simple: the more active the community, the better they can help you and your organization when support is needed. It also speaks towards the long-term direction and viability of the server.
Direction is very important for potential users to consider. “Where’s the product going in the future?,” Atwater suggested as another important question. In the J2EE community, clarity of direction has never been more important.
That’s due to the Apache Software Foundation (ASF), makers of the aforementioned Tomcat and the full-J2EE compliant Geronimo application server, withdrew from the Java Community Process (JCP) in early December last year.
The ASF resigned its seat on the Java SE/EE Executive Committee and pulled out of the JCP, which serves as the governing body for Java innovation, due to serious difference of opinion with the main sponsor of the JCP: Oracle.
According to the ASF, Oracle, as the sustaining member of the JCP, has not granted a test compatibility kit (TCK) license to the ASF’s own Java implementation, Project Harmony, due to specific incompatibilities in the TCK’s license. Without the TCK, Harmony cannot be tested and certified against the Java standard. This effectively reduces the potential user base for Harmony, which the ASF claims is likely the reason why Sun Microsystems, the original sustainer of Java, inserted the incompatible language in the first place.
The resignation followed through on the threat ASF leaders made in early November of 2010, if the December vote on the Java Standard Edition 7 roadmap went through. In the December vote, only two of the 16-member JCP executive committee voted “no”: the ASF and Google.
The ASF has long maintained that denying individual JCP member rights was an abuse of power by Oracle (and Sun before it). Because of this, the ASF has leveled charges that the JCP is not a true open specification.
The effect of this decision is a little hard to determine: it seemed to immediately remove the ASF’s Java-related projects from the official Java banner–but that’s a bit of a moot point, since Project Harmony wasn’t officially compliant to begin with. Where Geronimo and Tomcat fit into this picture is still anyone’s guess.
This sort of guessing may not be something you and your organization will want to do, despite the high praise Geronimo and Tomcat have respectively received in their customer spaces. There is a chance the ASF and Oracle will work out their differences, but until that happens, it leaves the question of Apache products’ J2EE compatibility in a bit of limbo. (For the purposes of this article, the last-known technical compatibility features will be listed for these application servers.)
The open source application servers compared in this article, with descriptions from their respective Web sites, will be:
- Geronimo : “The goal of the Geronimo project is to produce a server runtime framework that pulls together the best Open Source. Alternatives to create runtimes that meet the needs of developers and system administrators.”
- GlassFish : “GlassFish is an open source, production-ready, Java EE-compatible application server. GlassFish version 3 provides a small footprint, fully-featured implementation of Java EE 6.”
- JBoss : “JBoss Enterprise Application Platform balances innovation with enterprise class stability by integrating the most popular. clustered Java EE application server with next generation application frameworks.”
- Jetty : “Jetty provides a Web server and javax.servlet container, plus support for Web Sockets, OSGi, JMX, JNDI, JASPI, AJP and many other integrations.”
- JOnAS : “JOnAS is a leading edge Java EE 5 certified Open Source OSGi Enterprise Server developed by Bull and OW2.”
- Resin : “Resin is a smoking hot Java EE 6 web server. It is built on our distributed-agent technology for the elastic cloud.”
- Tomcat : “Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies.”
Hyperbole aside, this list represents the most active open source application servers on Java or Java EE to date. For comprehensive information on each project compared, locate it in the OpenLogic Exchange library by accessing the “Browse Open Source” link. The table below will list how each product falls within these specifications:
- Sponsor. The company or organization currently sponsoring the product and its open source community.
- License. The free or open source license under which the product falls.
- Version. Version number of the latest release of the product.
- Release Date. Date of the latest version release.
- J2EE Version. The current version of J2EE compliance.
- Java Servlet. Version of the most recent Java Servlet specification.
- JSP. Version of the most recent Java Server Page specification.
- EJB. Version of most recent Enterprise JavaBeans specification.
- Plugins. Are custom plug-ins available?
- Community strength. The relative community strengths surrounding the product.
| Geronimo | GlassFish | JBoss | Jetty | JOnAS | Resin | Tomcat | |
| Sponsor | ASF | Oracle | Red Hat | ASF | OW2 Consortium | Caucho Technology | ASF |
| License | Apache License 2.0 | CDDL and GPL with Classpath exception | LGPL | Apache License 2.0 and Eclipse Public License 1.0 | LGPL | GPL | Apache License 2.0 |
| Version | 2.2.1 | 3.1 | 6.0.0 | 7.3.1 | 5.2 | 4.0.16 | 7.0.11 |
| Release Date | 12/11/10 | 2/28/11 | 12/28/10 | 3/4/11 | 4/5/11 | 3/17/11 | 3/11/11 |
| J2EE Version | 5.0 | 6.0 | 6.0 | N/A | 5.0 | 6.0 | N/A |
| Java Servlet | 3.0 (via Jetty 7) | 3.0 | 3.0 | 3.0 | 3.0 (via preview features) | 3.0 | 3.0 |
| JSP | 2.1 | 2.2 | 2.2 | 2.2 | 2.1 | 2.2 | 2.2 |
| EJB | 3.0 | 3.1 | 3.1 | N/A | 3.0 | 3.0 | N/A |
| Plugins | Yes | Yes | Yes | Yes | Yes | Yes. | No. |
| Community Strength | Very strong. Perhaps negatively affected by ASF’s move to withdraw from JCP. | Very strong. Perhaps affected by ASF’s move to withdraw from JCP, though unclear how at this time. | Strong. Commercial aspects have kept community vitality lower than “pure” open source projects. | Strong. Inclusion within Eclipse Project has strengthened community vitality. | Strong. Particularly amongst commercial interests/ communities in Europe. | Fair. Presence of proprietary version of open source product limits community participation. | Very strong. Perhaps negatively affected by ASF’s move to withdraw from JCP. |
Each of these application servers represents thousands of hours of community effort, and any one of them can have a place in your organization. By examining your IT architecture and application needs, you can find one that’s the best fit for your company.
