Application – page 2

But that's not all. In the early days of application servers, it was realized that applications themselves, the programs people were using to get work done, were becoming bigger and more complex -- both to write and maintain. At the same time, pressure was increasing for applications to share more of their data and sometimes functionality. More applications were either located on a network or used networks extensively. It seemed logical to have some kind of program residing on the network that would help share application capabilities in an organized and efficient way -- making it easier to write, manage, and maintain the applications.

The end result of this thinking is what is now called an application server. However, these servers first appeared in client/server computing and on LANs. At first, they were often associated with "tiered" applications, when people described the functionality of applications as two-tiered (database and client program), three-tiered (database, client program, and application server), or n-tiered (all of the above plus whatever). This was (and still is) a complex model of application development, and it resisted wide-scale implementation. Then along came the World Wide Web. The Web is automatically three-tiered (database, client program, and Web server) and managing data along with application functionality suddenly became not only an esoteric exercise in better program design, but also a downright necessity. This vaulted the application server from obscurity to the top of a pedestal, and literally scores of companies jumped in to develop products.

Not surprisingly, these companies did not, and still do not, see the role of the application server in the same way. They weren't competing just to make something different. Application servers have different roles, and not every company requires the same functionality. Scalability is a good example. Some companies might want an application server that simply helps them organize their applications for the Web, give them better control over the business logic they contain, and make it easier to monitor and secure the data. They don't need thousands of servers. Other companies, especially big ones, do need to manage thousands of servers. For them, the scalability of an application server is crucial. So some application servers feature scalability, others feature other things, and some try to do everything.

Thus, when you look through the reviews of application servers on ServerWatch, you really need to form your own opinion about what your organization and situation require. What's most important: security, scalability, business logic management, or database connectivity?

One more thing (yet another complication), application server products belong to a variety of programming regimes. Most, though not all, are written in Java. Some are Microsoft friendly; others are not. This latter distinction shows up in support for either CORBA or Microsoft COM+ (and of course some support both). It's relatively important to consider these servers in the light of an organization's programming preferences.