By David Doyle
Once you have decided to invest in a Java application server, you must determine which one is best for your particular needs. An application server has a wide range of uses, from simple site navigation to business portals to e-commerce, CRM, and supply chain management. Different servers also offer varying support for particular databases and other software products, B2B and B2C transactions, and technologies like XML, Web services, rich media, and wireless. Those are just some of the possibilities, so you must carefully consider your requirements to determine which server is best for you.
Obviously, you’ll want a product that works with the platform (UNIX, Linux, Windows, and so forth) and Web server (Apache, IIS, NetWare, Domino) you have or intend to use. From that point, begin by looking for servers that meet your price and performance requirements.
A foremost concern is your budget: What can you afford? Depending on your needs, application server prices range from free to tens of thousands of dollars. You won’t necessarily have to spend a lot, but be prepared for high initial costs in case your requirements call for a more expensive server.
Most application server vendors price their products per CPU and/or server. The list price may understate the actual cost. It’s like buying a car: Vendors generally won’t add anything analogous to unnecessary rustproofing, but you may incur additional costs, such as:
- Additional platform requirements to run the software.
- Fees for moving the license between machines or platforms.
- Charges for support (higher during off-hours).
- Development overhead (tools, licenses for developers, debuggers).
- Training expenses.
Take care not to purchase beyond your needs. Some implementations support thousands of concurrent users, whereas many business needs, such as intranets, won’t even support hundreds. It would be a huge waste of money to spend tens of thousands of dollars per CPU when another product suits your purposes at a fraction of the cost.
Scalability, availability, and failover
Performance features are another very important consideration. Java application servers have various methods for dealing with increased usage and server failures. Clustering multiple identical servers will help you in either case, letting the end user connect to several machines as though they were one server.
Scalability is the ability to run a server over an increasing number of computers and processors. Look for a scalable application server if you expect your site to grow in size and/or usage. As site traffic increases, you’ll need to handle more simultaneous connections from users accessing the system. A good benchmark is to have an application server that can handle two or three times the traffic you expect. In that event, you’ll be ready.
You may need to choose a scaling method to match the rate of traffic growth. If you do not anticipate rapid growth, you can probably get by with an n-tier solution that can be distributed across added computers. If your site might suddenly be hit with a lot of traffic, you may need a type of dynamic scaling so that the application server can automatically handle unexpected peak periods. If you definitely expect significant growth, consider a flexible scalability that allows adding CPUs. The latter solution may also require a multithreaded, multiprocess implementation, which may in turn require a different type of license.
Availability depends on a number of factors, most notably load balancing and failover, which can be implemented with hardware, software, or a combination of the two. Different servers offer various types of load balancing, including round-robin, “smart” round-robin, weighted round-robin, least-busy round-robin, response time per component or server, and dynamic. You’ll want one that matches your hardware and software arrangement.
Let’s look at an example of clustering and load balancing. A Web server might handle static documents (such as HTML, JPEG, and GIF files), while a cluster of Java application servers handles requests for dynamic pages. In Figure A, one application server acts alone as a “worker” to balance others running off it. The Web server could be Apache with a Web server adapter module that routes dynamic requests to the worker. The worker could be Tomcat Worker, which uses load-balancing algorithms to farm the requests to the clustered servers.
|Multiple Java Application Servers|
Several other Web and Java application servers have similar features, either packaged as a “complete” solution or available through third-party add-ons.
Some Java application servers support different types of failover. Look for a server with transparent failover if transaction sessions need to be uninterrupted. It should route any pending transactions on a failed server in a way that avoids the failed one, perhaps to a database in another location or in a shared memory area. Another type of failover, called request-level, automatically redirects traffic to other working nodes but loses any session information in a transaction passed to the other node.
Not all Java application servers support all of these performance features, so look for one that suits your needs. Note that the level of support provided doesn’t necessarily correspond to the cost of the server. Some will be quite reasonably priced, but may lack in other areas. Try to estimate the size of the completed site and the amount of traffic you expect. Also think about how much downtime you can afford. Try to learn about other customers’ experiences with actual implementations or load-testing results.
The next article in this series will discuss terminologies and concepts specific to Java application servers, relevant standards, and various types of database support.