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 applications for 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.
The future: Commoditisation and specialisation
Based on prior technology trends (like the relational database and the operating system before that), a period of wide-open innovation, product creation, and market growth will almost certainly lead toward commoditisation and specialisation.
Companies like BEA and Silverstream will not be able to continue charging outrageously high prices for value-added application server features, while companies like Oracle, IBM, and Microsoft build these same capabilities into their core platforms (Oracle 9i AS, WebSphere, and Windows .NET Server, respectively). They will be forced to either pursue being acquired or find specific markets for products. (Witness the continuing success of NCR's TeraData in the RDBMS market as a high-end, high-volume provider.)
In fact, we've already seen some of this taking place. IBM is repackaging the WebSphere product line for small-to-midsize businesses with templates and development guidance. SilverStream has released Extend for RosettaNet, a customised, lower-cost version of their flagship application server targeted for companies who do business in the electronic supply chain or public and private trading networks.
The companies who are the most vulnerable are those who have no tie to the front end (client development tools) or the back end (databases or operating systems) and must stand alone in the middle, such as BEA and ATG. The companies with the best chance of survival have their feet in all four spaces: development tools, application services, databases, and operating systems.
Do you need one or not?
The answer about need, as always, has become, -It depends." From a Microsoft perspective, the functionality included in an application server really belongs in the OS. Being able to tightly bind functionality like load balancing or database connectivity to the OS has some significant performance and security advantages. So, if you're working primarily in a Microsoft environment, the answer is no.
But if you work in a heterogeneous environment, where you have to support a mix of J2EE and Microsoft applications, or you work primarily with J2EE applications, then you really have no choice but to adopt someone's application server platform in order to get the functionality required for enterprise environments.
And that, of course, is the ultimate irony. In your quest to get the -best of breed" applications by using J2EE as the standard runtime for applications, you can't get the best performance and interoperability without standardising on a single vendor, most likely IBM or Oracle.
Companies who made early bets on smaller application server providers (like ATG or BlueStone) have already been forced to reevaluate their decisions as IBM and Oracle add more application server features to their platforms.
Within five years, I think the application server world will look a whole lot like the database world. There will be three or four primary vendors (Microsoft, IBM, and Oracle) who have basically moved application server functionality into their environments, and lots of niche players for specialty markets or special application scenarios. The real long-term losers become BEA and Sun. The company that launched the Java revolution (Sun) will ultimately be swept away by the companies who perfect the application server environment that makes truly scalable enterprise applications possible (IBM, Microsoft, and Oracle).
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2001 TechRepublic, Inc.
4%
4%
