Spilling the Beans on Open Source Applications Servers

Open source software is playing an increasingly significant role in the enterprise, however, the adoption of open source application servers has been slow.

While "free" open source is a myth that some vendors try to sell you on, used within the right business scenario, open source application servers can actually lower your cost and provide a lightweight solution for your needs. The trick is to know which scenarios call for an open source application server and when it's better to go with a commercial solution. By making an informed decision, you can help promote the adoption of open source application servers within your organization.

Selecting an Open Source App Server That Will Make You a Hero
There are numerous open source application servers that are ideally suited for a myriad of simple application environments, including home grown and external applications—GlassFish from Sun, JBoss Application Server (JBoss AS), JOnAS, and the Apache Geronimo-based IBM WebSphere Application Server Community Edition (WAS CE), to name a few. However, the open source business model does introduce additional risk factors that you should try to avoid. If you're experiencing objection from senior management to introduce open source application servers, the following considerations may help you get your first open source project started. First, let's take a look at a typical customer scenario that might be appropriate for open source application servers.

In this simple scenario, several automobile dealer service centers have multiple browser-based desktops. The desktops are used by the mechanics and parts department personnel to access customer relationship management (CRM) applications and databases. An open source server hosts the CRM application. The auto parts supplier has another open source server at its remote office site that contains an available parts database application, which processes orders for parts. Different suppliers have their own Web service interfaces. One regional marketing broker has a database containing various special offers that auto service employees can give their customers when they drive in for service.

When executives make a vendor decision, they're interested in TCO, that's a no-brainer, but most of them are also looking at factors such as product maturity, vendor reliability (will the vendor be there to fix my production problems?), room to grow (if this application grows, what are my scaling options?), and stability (can I count on the vendor to be around and maintain a stable pricing model?).

The good news is that there are several options, as each vendor offers different strengths and you can decide what's most critical for project success in your organization. If you lay out the reasoning with senior management, you have a better chance of getting your open source project started. The following sections detail our analysis of two leading open source vendors—a "pure play" in JBoss with its JBoss AS vs. the open source application server from a commercial vendor, IBM with its WAS CE.

• Product Maturity: JBoss AS is a clear winner in this category. With seven years on the market and on its way to a fifth major release, JBoss has significantly grown its development team and heavily leverages customers to send back product fixes that improve the product. While IBM is no newbie to application servers, WAS CE is a relatively new product based on Apache Geronimo. It offers developers who use Apache Tomcat additional features such as messaging, security, clustering, Web services, etc., and with IBM's commitment to WAS CE—and their participation in open source development—the product should develop quickly.
• Vendor Reliability: We all know development environment and production are two different things. Moving into production, you can't afford down time, but things rarely go smoothly. As a result, you typically need a vendor that has the capacity and expertise to provide the level of support needed, when you need it. While the JBoss support model worked pretty well for a small customer base, the recent acquisition by Red Hat was bad news for developers. Red Hat immediately pulled the support functions of both organizations together to reduce costs and that means you get passed around before you reach the experts. Moreover, while JBoss is pretty good at handling JBoss-related support issues, it doesn't seem to have much expertise in integration with other vendor products. IBM support is a well-oiled machine and WAS CE users can enjoy the same benefits that commercial product users do. IBM is known for its vigorous testing and broad platform support and can more easily handle support issues related to other vendors.
• Room to grow: A good project manager should always consider the upgrade path in case business needs call for expansion. JBoss AS offers superior scalability to WAS CE, however, WAS CE is more than capable of handling the auto dealer scenario. It can handle remote, geographically dispersed, satellite offices hosting a range of applications that are both loosely and tightly coupled and it supports both real time transactions and batch or disconnected operations via a backbone messaging provider. While JBoss AS can scale, it's no match to IBM's enterprise horsepower with its commercial products, and scaling with JBoss AS can get pretty expensive. You might want to think about it this way: if you're trying to heat up a small room, a space heater could be a good solution. However, if you need to heat an entire house, you can probably get it done with ten space heaters, but you're paying more, taking more risk (of a fire starting) and getting poor results compared to using a central heating system. A WAS CE user can leverage enterprise scalability through a seamless upgrade path to more robust products in the WebSphere Application Server product family. JBoss AS works well for simple projects, but it's still a single product with many limitations, so when it's time to upgrade, a JBoss AS user would basically need to start over.
• Vendor stability: In this category IBM's WAS CE wins heads down. JBoss has yet to find a profitable business model and it seems the Red Hat acquisition only made things worse for the once privately held company—which now needs to answer to investors. To address investor concerns, it seems Red Hat is moving JBoss to a model similar to Red Hat's, where upgrades and new product features will require a subscription, yet clear announcements have not been made. Developers that are used to $0 license fees are not so happy. IBM on the other hand has seen WebSphere continuously grow over the past years and its financial stability is strong. With its mixed model of open source and commercial application servers, IBM can afford to offer the open source product, WAS CE, at $0 licensing cost.
• TCO: Getting back to the obvious concerns management has over total cost of ownership, how TCO is measure is far from obvious. While metrics on elements such as usability, build times, and training required should be taken into account, we have not found publicly available reports comparing the two products on these elements. From a pure cost perspective, WAS CE offers lower support costs than JBoss AS. It also has a smaller footprint and allows removal of any unnecessary components to reduce the overall size, so it's easier to manage, which affects TCO as well. JBoss offers on-site training that can help you achieve lower operations costs, but the training itself is not without a price.

In short, both application servers could handle the auto dealer scenario equally well. While JBoss is a more mature product and offers additional features such as object caching and load balancing for JNDI, RMI, and EJBs, many projects, such as the auto dealer scenario, don't leverage these more complex features—so the justification for a higher support price tag and a heavier footprint is not there. On most other managerial concerns, WAS CE offers a better answer to mitigating the risk of an open source application server.

We did find support for increasing adoption of WAS CE. In a 2006 survey of 384 respondents from large and enterprise-sized global organizations representing the North America, EMEA, and APAC regions, Evans Data Corporation reported that approximately 16 percent are WAS CE users.

Mission-Critical and Clustered Apps Require Specific Functionality
While open source application servers bring a strong value proposition to the enterprise, they have limitations. To tackle more sophisticated projects, involving mission-critical applications, that can handle high volumes of transaction processing, you often need strong performance, high availability, advanced security features, load balancing, advanced clustering, and systems and network management and monitoring capabilities all integrated with seamless access to specialized or additional hardware, software, and network resources. To date, no single open source product can optimally handle these requirements, therefore, taking the open source route on mission-critical projects introduces high risk.

To illustrate a typical mission-critical project, let's take a look at a second scenario. Here, a very large online retail company enables its customers to shop online and fill a shopping cart with items for purchase. The process involves creating and establishing communication with a server, a unique user ID and keeping track of the exchanges that occur between each server and browser—belonging to the thousands (or millions) of users who are shopping concurrently. Each user fills their virtual shopping cart before checkout—an interaction that often involves multiple HTTP exchanges. Once the browser initiates the user interaction, subsequent requests have to be properly tracked and managed with an architecture that defines the transport parameters between the servers. If customer shopping carts fail, are slow, or customers can't access the site, the retailer stands to lose significant amounts of revenue.

This scenario requires a product capable of handling various business challenges that arise with the retailer, and must provide state of the art clustering, exceptional deployment services, near-continuous availability, edge-of-network services, and Web services that can operate across disparate application frameworks, while supporting a large number of different platforms.

In this scenario IBM and JBoss take a rather different approach. IBM attacks it with its strongest workhorse—WebSphere Application Server Network Deployment and offers WAS CE for lower-end projects. JBoss, on the other hand, has recently attempted to position JBoss AS as enterprise-ready—leaning on Red Hat's success. While JBoss AS might be overkill for the low-end scenarios, it suffers from many limitations that make it a rather risky choice for the high-end scenarios.

The JBoss platform extends many recently-added features, which haven't been proven and bloat the application layer, making integration of the most important features—security, messaging, and authentication—difficult. To cluster servers, it requires separate deployment of EAR (Enterprise Archive) files for each member of the cluster—a sizeable manual effort. Additionally, JBoss does not support cluster partitioning for in-memory HTTPSession state replication, which means that data has to reside on all servers in a cluster to be replicated in memory. This wastes heaps of memory and limits horizontal cluster scalability. Additionally, few commercial software packages support the JBoss runtime. Consequently, JBoss AS users may find it is far more expensive and time consuming to purchase these additional products or components and integrate them with JBoss code. Finally, JBoss plug-ins only support JBoss products, limiting customer flexibility.

What we like about IBM's approach is it offers a broad product portfolio and each product is therefore optimized for a different user scenario. IBM also develops its products with interoperability in mind and goes through rigorous testing of new software releases to validate and certify it for compatibility with other company software products, which helps contain development and integration costs. This of course doesn't come without a cost, particularly at the high end, however our experience shows it is almost always less costly to procure pre-integrated commercial product than do the integration work yourself.