Most Read This Week
Java Industry News
Next Generation Application Servers
Next Generation Application Servers
By: Jon Maron
Jan. 1, 2000 12:00 AM
The methods of accessing this information also changed. Previously, information residing in legacy systems and databases was accessed via limited, expensive, and proprietary solutions. As web technology matured, the information could now be provided to users via applications that accessed the back-end datasources and presented the information to client browsers. These first web-based reporting front-ends for legacy databases ultimately grew in functionality and yielded the first application servers.
This article will explore the evolution of the application server from these initial reporting tools to the robust standardized platforms they have become. We will then define the requirements for the next generation of application servers given today's dynamic business environment and the heterogeneity of system architectures.
First Generation Application Servers
These first efforts addressed the need to provide a rapid development environment for the web tier given that initial in-house efforts by developers were rather complex and hard-to-manage combinations of scripting languages (e.g. perl, tcl) and native executables written in C or C++. The development tools provided with application servers supplied a coherent platform on which to develop and a repeatable process for generating the target applications.
Although the emerging application server market offered some exciting new possibilities, there were still some distinct shortcomings to the technology. The initial offerings were CGI based and therefore did not address the failure recovery and scalability requirements expected of existing enterprise applications. Additionally, and possibly most importantly, the initial offerings did not offer a cohesive, standardized platform for web application development. Each of the vendors offered a proprietary solution that required a fairly advanced developer to learn a new set of skills in order to fully leverage the given solution; the knowledge the user gained was generally not transferable. As a consequence, choosing software for a web-based application was a rather ambitious task of sorting through and evaluating many products from different vendors such as Web Servers, web page templating engines, business component frameworks and databases.
Recognizing the need for a uniform approach to web application development, Sun pulled together a collection of enterprise APIs and created the Java 2 Enterprise Edition (J2EE) platform.
Second Generation Application Servers
The development of the J2EE standard also yielded a strong impetus for continued innovation as vendors attempted to differentiate themselves from one another in order to fight the effects of commoditization. Various companies attempted to set themselves apart by providing advanced enterprise features such as load balancing, clustering, and legacy data access. In addition, tailored solutions for customer management, business-to-business integration, and XML support were put forth as significant differentiators.
As application servers grew in acceptance and as more APIs were rolled into the J2EE platform, developers wished to leverage them in increasingly varied deployment environments. Often the incorporation of a new or modified J2EE API meant the disassembly of mature working parts of the server so that a new technology could be integrated into the existing components. Moreover, rapidly evolving requirements for supporting heterogeneous client devices, deployment platforms, and back end data sources further steered vendors to constantly re-tool and adapt the existing application servers. Certain companies recognized the need to create a new, much more adaptable architecture in order to more rapidly and effectively address the customers' needs for rapid support of emerging technologies.
Third Generation Application Servers
A services framework hosts a set of independent but cooperating services. Each service remains isolated and exposes only specific declared interfaces to other services. Thus, architects are able to engineer new services quickly by adhering to an explicitly defined interface. In addition, since services are isolated components (with potentially some dependencies on other services) architects can tailor the footprint of the application server to match the business needs mandated by the deployed application or the memory footprint of the deployment platform. For example, an application server instance that has no deployed EJB components can have its EJB container service (and any supporting services) removed, yielding a more streamlined and lightweight platform.
Furthermore, this architecture provides a foundation for not only supporting existing requirements but also dynamically extending the platform to meet specific business needs. Services can be added or removed without disrupting the design or operation of other services. Moreover, all services in the framework share the same support services afforded by the underlying service framework. There is no need to address evolving requirements not directly supported by the J2EE model by integrating some third party application. Rather, the application server itself can be easily extended to support this new facility.
The Web services initiatives currently under way are a prime example of technology that can benefit from this rapid deployment and availability model; as the components that encompass new Web services are created they can be dynamically linked into existing application servers with little effort.
Recognizing the utility of this architecture, many vendors (including Apache, HP, Lutris, IBM, ATG, Sun, and others) have begun an effort to standardize the service API through the Java Community Process (JCP). Java Specification Request (JSR) 111 puts forth the concept of the Java Services Framework. This initiative aims to formalize the service model and standardize the way in which service components are written and deployed. When completed, the Java platform will provide standardized support for service development.
This granular approach to application server assembly, in addition to the JSR standardization effort, yields exciting opportunities for vendors to offer best-of-breed application server components. The breadth and growth rate of the J2EE platform has made it increasingly difficult for any company to effectively keep pace with the requirements made of a fully compliant application server. A service-based approach opens the door for vendors to specialize in a particular J2EE or enterprise technology and offer it as a pluggable service that can be leveraged by a compliant services framework. One can also envision open source projects that produce pluggable enterprise domain services that customers can use in their application server infrastructure.
Thus, the next generation of service oriented application servers appearing on the market today yield a highly secure, reliable, extensible, and maintainable platform. As the set of APIs and technologies that application servers offer continue to evolve, they will define the platform to which developers design, develop, and deploy their business applications. These next generation application servers define a new operating environment - a highly adaptable and configurable environment on which future generations of Web services will reside.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads