In the 70s and early 80s, when mainframe databases ruled and the micro- and mini-computer revolutions were in their infancy, there were literally hundreds of companies competing to be the new database of choice. It had become clear that as more companies began using smaller computers, they could neither afford the database technology available on the mainframe, nor the cost of custom coding flat or index file data-manipulation applicationsfor each new application that they developed. The rise and adoption of the relational database became a key driver that allowed minicomputers and PC networks to replace mainframes as the primary business platform. Today, there are only three or four primary database vendors left standing (depending on how you count them): IBM (DB/2), Oracle, Microsoft (SQL Server), and Sybase. If you check out the relatively nascent market for application servers, you'll see a similar pattern emerging. The first inclination is to begin considering technology investments before you're left with applications that have to be rewritten or ported to a different platform, because your vendor no longer exists. But a bigger question looms: Do you really need an application server? Problem lies in the definition
As with many unanswered questions, the real answer depends on how you define the question. In this case: What is an application server anyway? The earliest recorded use of the term comes from late in the client-server era and early in the Internet Age, when it became clear that client-server applications would never scale to large numbers because of the nature of the fat client. The distribution, management, and performance of business rules on the client severely limited the scalability of client-server applications. Many different companies arrived at the same answer at about the same time: Move the business rules to a server that sits between the client and the database. Depending on which company was defining this middle tier, it was called something different. Companies with transaction-processing backgrounds called it a transaction server. Vendors who made tools that enabled this multitier distribution of presentation and business logic (e.g., Allaire with their Cold Fusion product) called it an application server. Whatever it was called, it was designed to centralise the management of the application objects required to connect clients--whether Web or Windows clients--with the databases or system services with which they had to interoperate. These centralised management services include the creation and management of server components (at the time, primarily focused on COM or CORBA object frameworks), clustering support, component load balancing, transaction management between multiple back-end databases or system services, and failover or other advanced redundancy features. They also had to have some mechanism for connecting to the legacy systems and relational database systems that housed most of the existing production data. What they will become are the support systems that surround the two common runtime environments: J2EE and the .NET Framework.