The point of any server is to serve data, but that doesn't mean that a Web server is the best tool for serving all data. For heavy tasks, an application server is more appropriate -- but how do you know when to scale up to an application server? In this tutorial, Nelson King discusses the situations where application servers are your best choice -- and where you should use a basic Web server to serve your data.
Web servers are a familiar and necessary component of the Internet. Application servers are less familiar but also a necessary element for at least some aspects of the Internet. This tutorial is aimed at highlighting the distinctions between these two important server types and helping you to decide how and when using one (Web server) may lead to using the other (application server).
Of course, Web servers and application servers are not mutually exclusive. And in the corporation their functions can certainly overlap: there are many, many Web servers that are serving data from a database, while there are more and more application servers serving up basic Web pages, if the Netcraft numbers for SilverStream and Zope are accurate.
But the key to good system design is choosing the right tool for the task. In those cases where both a Web and an application server would serve your needs, you can save yourself some headaches down the road by selecting the right tool. In this series, you'll see where each tool is applicable.
First, a few basics. While a Web server and an application server can run on the same computer (though usually not) these are two quite different pieces of software. There are few Web servers in common use: Apache takes the lions share, while Microsoft Internet Information Server (IIS) and iPlanet Web Server are among the others. Application servers jumped into the limelight only about two years ago and there is a proliferation of products from companies such as BEA, iPlanet, Oracle, SilverStream, HP (Bluestone), and IBM. Microsoft doesnt have a product it labels an application server, but the BizTalk Server is similar in functionality.
In general, an application server prepares material for the Web server -- for example, gathering data from databases, applying business rules, processing security clearances, or storing the state of a users session. In some respects the term application server is misleading since the functionality isnt limited to applications. Its role is more as an aggregator and manager for data and processes used by anything running on a Web server. In fact, in the coming age of Web services, application servers will probably have an even more important role in managing service components. More on this shortly.
Where a developer typically picks a variety of tools to manage and program the Web server, most application server software is sold as a package with an integrated development environment. More often than not this is a Java environment.
One of the motivations for using an application server is to improve performance by off-loading tasks from the Web server. Common sense says that with heavy traffic -- more users, more transactions, more data, more security checks -- the more likely the Web server becomes a bottleneck. In some respects its simply a matter of processing power -- Web browsers from hundreds (if not thousands) of users can place huge demands on a server, sometimes bringing it to a standstill. Of course, it is possible to offload some of this traffic to other Web servers. At some point, however, depending on the load, the type of applications, and the amount of control required it becomes not only more efficient but more manageable to move some of the workload to an application server.
What are the performance criteria for moving to an application server? The most obvious is an overloaded Web server -- measured by whatever evaluation fits the particular situation. More to the point are the causes of the overload. Although not necessarily easy to pinpoint, if the causes seem to be one or more of the following an application server may be the ticket: Long response times retrieving or formatting data; transaction processing bottlenecks; complicated security and user validation; and special processing required for an application.
One of the most frequent causes of poor Web server performance is data management or data-related transactions. Web servers and HTML in particular were not designed for large-scale data handling. Web developers have long used various techniques and add-ons to get around the data problems -- with varying degrees of success. Consequently, if your web applications must deal with a lot of data, or the data is complex in some way -- then you may find an application server not only more efficient but also provides more control.
Application servers shine at managing data. XML translation, communication with database servers, validating data, and applying business rules are all functions for which application servers were originally designed. A key element may be the business rules. These are validations of data and user input (requests as well as data) according to the rules of a company ("an order over 50 is too big to be processed"). Some applications employ a lot of business rules. Although they can in some ways be implemented at the Web server, many application servers provide special business rules development and management tools that make the job much easier.
Application servers usually provide a battery of tools -- pooled data connections, data caches, session persistence, and failover protection -- to name a few, that go far beyond the data management capability of Web servers. Some also include various forms of transaction management linked to external database server connections.
A similar situation exists for security. While Web servers can manage a certain amount of security processing, the more there is or the more complicated it becomes (for example the need to pole corporate security servers for user verification), the better suited an application server is for the job.
Above and beyond performance improvement, if there is one factor that drives the use of application servers, its complexity. Web applications in particular are among the most complex software ever developed. People have done spectacular things with Web servers, including highly complex applications -- however, these often required monumental efforts and were one-time projects. Application servers are designed to accomplish the same thing on a regular basis and without heroic effort
Behind most of the complexity is the need to communicate with multiple servers, typically database and directory servers and to orchestrate a variety of processing such as XML/XSL formatting, validation by business rules, and transaction management. The best of the application servers (and their accompanying development systems) provide very sophisticated management and control toolsas well as the documentation and supportthat can greatly help to tame the beast of complexity. One of the things you should look for especially in the ServerWatch reviews is commentary about how easily an application server product makes the job of coordinating (in your head as well) all the necessary pieces.
If the software vendors have it right, Web developers will soon need to bust apart their notion of applications into many smaller pieces -- into Web services. If we speak of an "inventory control" application it may actually consist of many components (objects) that exist on several different servers (database servers, processing servers, Web services servers). Management of Web services is not something envisioned for Web servers, or even Web server add-ons -- its a role tailor-made for application servers because they already specialize in controlling and integrating distributed applications. Within the next three years, Web services alone could be the major reason for adding application servers to the server mix.
So far this tutorial makes it sound like an application server may be the answer to lifting the burden from overloaded Web servers -- and an overloaded Web staff. It can, but there should be no illusions about the step into application servers. They are a specialized and complex piece of software, often requiring detailed knowledge of database management, Java, XML, and security procedures -- as well as special knowledge more or less unique to application servers. In short, they usually require people who become specialized in their use. This is expensive and opens the door to management difficulties. Consequently, the move to use application servers should be considered not only in the light of site traffic and application complexity, but also within the context of people available to establish and manage them.