Component Management: Managing Application Servers.

For the past 10 years, there have been drastic transformations in managing a company's infrastructure. In the beginning, much of the focus was placed on the network. Gathering hundreds of statistics across routers, hubs, and switches was commonplace. Eventually, when network stability was established, the management focus changed to servers and desktops. Basic information of server health was important to the overall performance of the network. However, this information proved inadequate, yielding way to applications management products. These products would supply detailed information about an application, including statistics from the application, outages, as well as end-to-end response time. Although these management products deliver incredible amounts of information about applications, the popularization of the Internet, specifically e-commerce, requires even more scrutiny and detail about application performance. Thus management products must evolve into managing the individual components of an application.

Along with the expansion of the Internet, a new breed of software framework has emerged. In the past, a large majority of applications were developed using database technologies from Oracle and Microsoft. As companies continue to improve their Internet presence, the challenge of developing applications that could be accessed through the web, while continually accessing a database has forced a new technology, called Application Servers. Application Servers facilitate the merger of web and database technologies through a series of smaller software objects called components. Components, in their simplest form, are small pieces of software that operate within an application server. Each component is generally responsible for a very explicit task, such as verification of a credit card transaction.

Application Servers

Application Servers are developed using many different types of technologies. However, they can easily be broken up into several different logical elements. At the core of the application server is the transaction engine. The Web Interface allows web browsers to connect to the application server invoking components within each web application. In turn, each component connects, through connection pools, to the backend database. Figure 1 details the different parts of most Application Servers, and their relationship between them.

The core of an application server is the transaction engine. It is a traditional system process (NT Service or Unix Daemon). It has several responsibilities including message routing, component and database connection management, and traditional transactional processing.

The Web Interface provides a mechanism for web browsers to invoke different operations within each web application, for example buying books or database searches. Web interfaces are implemented differently based on the type of Application Server. For example, Java based Application Servers (such as BEA Web Logics or IBM WebSphere), use a combination of Java Server Pages (JSP) or servlets to access the web applications. Microsoft uses Visual Basic Script (vbscript) or Active Server Pages to communicate with each web application.

The most important pieces of Application Servers are the web applications and their components. Each Web Application is comprised of a series of components that perform a variety of specific tasks. All of the application knowledge resides within each component. In Java based platforms, these components are Enterprise Java Beans (EJB). Microsoft uses their Common Object Model (COM+) objects to perform the individual tasks.

Finally, the transaction engine communicates to the database through a series of connection pools. Each pool consists of a series of dedicated connections, which are allocated to components when necessary. This improves overall application server performance as well as abstracting the complexity of the database from each web application and its components.

Predefined rules will be composed for each supported Application Server. These rules (or SAMs) can be deployed to any number of Application Servers through the Proctor policy hierarchy. Furthermore, these SAMs will be available for use by other Proctor based products including xSPress and RelyENT. The first of targeted application servers are BEA's Web Logics, Allaire's JRun, IBM's WebSphere, Arts & Technology Group's Dynamo, and Microsoft's COM+/MTS.

The new component management product will allow the user to monitor the application server using SAM technology, as well as examine usage and failure statistics on servlets, enterprise Java beans, COM+ objects, and connection pools. Figure 2 details the relationships between the new components' management features.

A new Application Server Model rule will be added to the list of existing management rules. This new rule will contain configuration information for the Application Server, such as connection criteria. This model also contains statistical information about the operation of the application server as a whole entity.

At the Proctor Management Console (PMC) a series of pages will be added to configure the application server model. While at the Proctor Managed Node (PMN), pages will be added to display the Web Applications and their components based on which Application Server they reside in. Users can closely examine individual component statistics through a special set of web pages.

The subagent will be broken into several different sections, with a major distinction placed upon the type of application server (Java or COM+ based). COM+ based application servers will use the NT/W2K event subscriber mechanism to learn about Web Applications and COM+ objects. Java based application servers will be managed through accessing a series of Management Servlets contained within the Application Server. The communication method used to access the servlets is XML over HTTP.

When started, the subagent will connect to each application server on the server through the defined connection parameters in the new Application Server model. Once connected, individual web applications and their components will be automatically discovered. Since the number of web applications and components tends to be relatively large, they will not be stored in the configuration database. In addition to individual statistics, component statistics across web applications can be accessed through a series of additional table instances.

Paul LaFrance is the CTO of Dirig Software (Nashua, NH).