What are app servers? And where did they come from?
A beginner's guide to this newly popular product category
December 21, 1998
by Todd Sundsted
(IDG) -- When Tim Berners-Lee invented the technology and built the infrastructure that would become the World Wide Web, he envisioned nothing more than a global application that would allow its users to publish and link documents without regard for location and platform.
It was a bold vision, and like many great ideas, it vastly underestimated the true utility of the World Wide Web.
With the benefit of hindsight, one may be surprised by the narrowness of the original vision. The benefits delivered by the technology underlying the Web are obvious in retrospect.
The Web is built upon a family of simple, robust, nonproprietary protocols. The HyperText Transfer Protocol, or HTTP (which overlays a number of more complicated transport protocols), unifies communication between clients and servers. The Uniform Resource Locator, or URL, solves the difficult problem of uniquely identifying resources and data on a widely dispersed network without centralized control and organization. The HyperText Markup Language (HTML) provides a presentation layer that is lightweight and independent of the client platform.
These characteristics made the World Wide Web and Web technology the ideal catalyst for a set of trends that had been developing in corporate computing circles for a number of years.
Web technologies could easily replace limited, expensive, proprietary tools and protocols for sharing information over the corporate LAN with robust, open protocols and tools. This was the beginning of the corporate intranet.
Then, with the intranet in place, Web technologies provided a platform that enabled users with desktop machines to access the information and resources present on legacy systems. Tools that began as simple, Web-based reporting front-ends for legacy databases quickly grew in functionality until they were capable of integrating multiple back-end systems under a single interface. HTML made this step possible. HTML made the activity of designing attractive, lightweight user interfaces relatively painless. And the resulting screens were both portable across client platforms and free of the problems that often came with distributing and updating traditional client code.
Beyond the bounds of the corporate intranet, the World Wide Web allowed companies to bring these applications to remote users without the trouble of a dedicated wide-area network (WAN) or dialup connections. More importantly, the ubiquitous nature of the World Wide Web, and the now-universal nature of the protocols and technologies upon which it was built, made it possible to extend these same corporate applications out to suppliers, partners, and customers.
Where did application servers come from?The family of tools that we now call application servers is the result of two originally independent lines of development that converged atop the World Wide Web.
One line of development begins with Web site development tools.
The first Web applications were built with handmade tools. They were developed as needed and written in C, C++, Perl, or whatever else happened to be available. These handmade tools eventually gave way to the first integrated Web development tools. Integrated tools sported fancy user interfaces, streamlined the generation of HTML, and added rudimentary back-end integration. The heirs to this line still maintain the family resemblance. They tend to provide a rich development environment and generate high-quality, dynamic user interfaces but provide weaker support for enterprise application integration.
The other line grew from n-tier application architectures.
N-tier architectures are a natural evolution of the client/server paradigm. Three-tier architectures consist of a back-end system (or systems), a user interface, and a middle-tier consisting of a server executing the business logic. The middle tier was responsible for integrating the data provided by the back-end systems into a single whole.
Originally, the middle-tier software was written (and rewritten) by hand. It handled security, interfacing, and a host of other (fairly generic) responsibilities for itself. Successors to these early tools unloaded most of these generic responsibilities onto a standard platform and occasionally provided tools to aid in the generation of the business logic. Once again, the family resemblance is still apparent. The heirs tend to excel at back-end integration while being weaker on presentation.
It is likely that what we now call application servers could have arisen from either of these two separate lines of development, since both strove to solve the same problem -- that of creating effective distributed applications -- for different reasons. Critical mass developed, however, when the two lines met, and the resulting explosion created a market in which 30-plus companies claim to be players.
A third line of application server has appeared recently. Often springing do novo from very large, established companies, this line is the result of the identification of application servers as a strategic trend in the marketplace and the subsequent introduction of products that target that market. IBM's WebSphere is perhaps the best example of this line. Sun could have taken the same route and developed and introduced its own product, but opted instead to acquire NetDynamics. Microsoft is still without a clear product in this market, but may eventually provide a competitor.
What is an application server?
An application server, then, is a middle-tier application that combines three components: pieces for communicating with back-end systems; pieces for communicating with front-end clients (often, but not necessarily Web clients); and a framework upon which business logic can be hung. The result is a system that is modular, highly scalable, robust, and dynamic enough to meet the needs of today's businesses.
As it turns out, JavaTM technology plays nicely in this space. An application server based on Sun's enterprise APIs takes these trends to their logical conclusion -- a common, ubiquitous, platform-independent substrate upon which enterprise applications can be built. The open nature of the APIs enables developers to select from best-of-breed solutions without fear of vendor lock-in. It also opens the door for component-based application development, with emphasis on the server side. This is a trend that has never quite materialized but holds great promise for accelerating the speed at which quality applications can be written.
What they do and how they're used
At this point it's worth taking a look at application servers in terms of both their functional role and their place in an n-tier architecture.
Functionally, application servers host business logic and consolidate the raw information provided by back-end systems and databases into a form that has real business meaning -- hence the term "application" in application server. This used to mean code written to a proprietary API. It now means Java code written to the Enterprise JavaBeansTM (EJB) specification.
Application servers increasingly are responsible for providing adapters for communicating with external systems, including legacy systems and applications from vendors like PeopleSoft and SAP. They also provide tools for dynamic HTML generation and client communication.
Architecturally, application servers reside on the middle tiers of an n-tier architecture.
Trends and expectations
Three major trends currently seem to shape the application server space.
First, all vendors seem to be committed to supporting the JavaTM 2 platform and Sun's enterprise APIs. Many players, however, are taking a conservative approach -- they are committed but intend to tailor implementation to the level of demand they see from their customers. Therefore, expect to see companies adopt the technology in a piecemeal fashion.
Second, the products are converging in terms of the features they support. With Sun's enterprise APIs as a catalyst and customer needs usually spanning the range from back to front, application servers increasingly will provide one-stop shopping. This will force vendors to compete in terms of stability, security, and performance instead of proprietary features.
Third, expect the field to make more sense in a year's time. As I write this, there are 30-plus (perhaps even 40-plus) vendors who claim to provide "application servers" (and many such products showcased at the JavaSM Business ExpoSM conference) -- each dramatically different from the next. The field is full and the consolidation of features mentioned above should reduce the ranks of vendors, not increase it. The suite of features that application servers provide also should become more standard, allowing any application written to Enterprise JavaBeans to run on any number of app servers supporting it -- extending Write Once, Run AnywhereSM to the enterprise middleware arena.
Back to the top
© 2000 Cable News Network. All Rights Reserved.
Terms under which this service is provided to you.
Read our privacy guidelines.