Overview Guide: Netscape Application Server Architecture

Contents

Index

Netscape Application Server Architecture

This chapter describes the processes, systems, and services that make up the architecture of NAS.

The chapter contains the following sections:

Server Processes

System Components

Server Processes

The architecture of NAS includes four internal servers, which are often called engines or processes. They are responsible for all processing within Netscape Application Server. The following table summarizes the internal servers:


Internal Server	Process Name	Description
Executive Server	KXS	Provides most system services (some services are managed by the Administrative Server).
Administrative Server	KAS	Provides system services for NAS administration and failure recovery.
Java Server	KJS	Provides services to Java applications.
C++ Server	KCS	Provides services to C++ applications.

Summary of Process Interactions The following figure shows how the four NAS processes interact to handle requests from clients:

When a web server forwards requests to NAS, the requests are first received by the Executive Server process (KXS). The KXS process forwards the request either to a Java Server process (KJS) or to a C++ Server process (KCS). A KJS process runs Java programming logic, whereas a KCS process runs C++ programming logic.

Each KJS and KCS process maintains a specified number of threads and runs the programming logic to completion on those threads. The results are returned to the web server and sent on to the client browser.

The NAS technique of processing application requests is the key to reducing the load on a web server, thereby providing faster response time. A server administrator can configure the NAS environment for best performance by

adding any number of NAS machines.

specifying any number of KCS and KJS processes.

maintaining any number of threads on each process.

In addition to providing high performance, the internal processes make it possible for NAS to remain available 24 hours a day, 7 days a week. If a KCS or KJS process goes down, the KXS process restarts it. And if the KXS process itself fails, then it is restarted by an additional process—the Administrative Server process (KAS). Additional monitoring in NAS makes sure that the KAS process is always running.

If all NAS processes go down, then other NAS machines in the cluster will take over. (This assumes a multiserver environment.) In addition, NAS can send notifications by email and FAX to alert the system administrator.

The next several sections describe the internal servers in more detail.

The Executive Server The Executive Server is the main engine in the Netscape Application Server. The Executive Server is responsible for hosting many of the system-level services as they are needed by NAS.

The Executive Server process (KXS) also distributes application requests to the appropriate application process, either the Java Server or C++ Server process.

For example, here is what happens when an application request comes into Netscape Application Server:

The Executive Server invokes the request manager, a system-level service.

The request manager assigns a thread to the request and forwards the request to the appropriate application process, which is either the Java Server or the C++ Server.

When the request manager is finished, it is dismissed from the Executive Server, providing a dynamic-usage model for increased server performance.

The Administrative Server The Administrative Server enables administration of one or more Netscape Application Servers. It registers with the appropriate server or servers all changes made to the system and application settings using Netscape Application Server Administrator (NASA), the GUI administration tool.

The Administrative Server also hosts the failure-recovery service that restarts the other server processes if they become unavailable. This failure-recovery service provides a high degree of fault tolerance for Netscape Application Server.

The Java Server and C++ Server The Java Server and C++ Server processes are the application servers. Business logic components written in Java are hosted in the Java Server, whereas components written in C++ are hosted in the C++ Server. Business logic components are the core of the application, holding the compiled code instructions written by the developer.

The Java Server and C++ Server processes (KJS and KCS) also host the application-level services. These services are dynamically loaded into the appropriate process as needed by an application component. For example, when an EJB requires access to a database, the Java Server loads in the data access engine, uses its services, and then dismisses it. The database connection provided by the data access engine is cached in the Java Server active memory. If another request enters the system and accesses the same database, the cached connection is used. In this way, NAS reduces the need to invoke the data access engine, thereby increasing the performance of request processing.

System Components

This section describes the main internal systems that make up the NAS architecture. These systems are shown in the following figure:

This section describes the following topics:

Protocol Manager

Load Balancing System

Request Management System

Application Components

Application Services

System Services

Transaction Management System

Security

Administrative Services

Protocol Manager Communication between a web server and Netscape Application Server occurs through NSAPI, ISAPI, and optimized CGI. Optimization and superior performance are achieved through listeners, web connectors, the streaming service, and the Protocol Manager, as described here:

Web connectors and listeners manage the passing of requests from the web server to the Netscape Application Server. Listeners distribute and handle requests from the web connectors. New listeners can be added with the HTTP handler.

The HTTP streaming service handles data streams from the Netscape Application Server to the web server and to the web browser.

The NAS Protocol Manager manages and provides services for all active, loaded listeners. The Protocol Manager supports HTTP, HTTPS (HTTP over SSL), and IIOP.

The following figure shows how the Protocol Manager enables communication between NAS and a client (whether web-based or not):

When a request comes in from a web browser, the request is passed to the web server via the HTTP or HTTPS protocol. The request is processed by the appropriate web connector. Web connectors include the NSAPI web connector, ISAPI web connector, and optimized CGI web connector for Netscape, Microsoft, and CGI-compatible web servers, respectively.

The request is then forwarded to the corresponding listener on NAS. Listeners on NAS include NSAPI listeners, ISAPI listeners, and optimized CGI listeners that communicate with Netscape, Microsoft, and CGI-compatible web connectors, respectively.

Load Balancing System In an environment with multiple NAS installations, incoming requests first pass through the Load Balancing System. The Load Balancing System directs the request to the server best suited to process it. The Load Balancing System includes a Load Monitor and a Load Balancer.

The Load Monitor takes a snapshot of server load based on administrator-configured interval settings. The Load Monitor then tabulates resource availability and system performance.

The Load Balancer uses the load and performance statistics retrieved by the Load Monitor to determine the server with the most available resources to handle an incoming request. Each instance of NAS has its own load balancing module which makes routing decisions based on load balancing parameters. Administrators can tune these parameters using NAS Administrator.

After a request is routed to the appropriate NAS machine, the request is passed to the Request Management System.

Request Management System Incoming requests are handled by the Request Management System. NAS is multi-threaded, and the Request Management System assigns threads from a dynamic thread pool to process the requests. The Request Management System enables the simultaneous processing of a high volume of requests. System administrators can configure thread pool parameters for optimal request processing. The Request Management System includes the following subsystems:

Thread Manager

The Thread Manager provides a dynamic pool of threads. From this pool, a thread is assigned to process the request.

Queue Manager

The Queue Manager gets involved when requests must be queued until a thread becomes available.

The Queue Manager manages the list of pending requests and descriptive information. This information includes things such as the unique request ID and a request's current processing status, such as waiting, in process, finished, and so on.

Request Logging

Request Logging, if enabled by the system administrator, keeps an information log of web server requests in a back-end database or in log files.

Application Components Each incoming request identifies one or more application components. These components, in turn, are identified by their globally unique identifier, or GUID. GUIDs are checked against NAS's Global Directory Service (GDS) and Netscape Directory Server, an LDAP server.

GDS determines the language of the application component and then loads the appropriate language-specific handler for the request. For example, on Windows NT, a .class file is loaded for Java application logic, and a .dll is loaded for C++ application logic. On UNIX, a .class file is loaded for Java application logic, and a shared library (a .so file) is loaded for C++ application logic.

If necessary, Netscape Directory Server authenticates the request by checking against known access control lists (ACLs).

The appropriate application component is then executed to process the request. For example, the request may invoke a servlet, which in turn may call one or more EJBs.

Typically, request processing involves calling functions from among the application services, transaction management system, or other system services. For example, the application may make use of state and session management or may connect to a database to update a user's account.

For more information about application components, see "Application Model". In addition, see the Programmer's Guide.

Application Services Application services enable management of application functions, such as user sessions, application states, cookies, email notification, result caching, and so on. These services are invoked by application components using API calls. Application services are loaded into either a KJS process, a KCS process, or both. The following sections summarize the services available to Java and C++ applications:

Services Hosted by Either KJS or KCS
The following services are available to applications written in Java or C++:


Application Service	Description
State and session management	Manages user session information, such as user login, page navigation information, and "shopping cart" selections. Manages persistent state information. Distributed NAS machines can use a state workspace to share information.
Cookie management	Generates HTTP cookies for cookie-aware web browsers. For non-cookie aware browsers, emulated cookies are embedded in URLs or hidden fields.
Data access management	Provides and manages access to databases.
Transaction management	Manages database transactions, providing commit and rollback support for those transactions. See "Transaction Management System" for more information.
Template management	Manages the merging of result-set data with templates before data is returned to the user.
Database connection caching	Caches database connections so that future access for the same database is provided immediately.
Result caching	Caches result-set data so future requests can be processed more efficiently. If the request has been stored in the result cache, the previously computed result is returned immediately. Otherwise, the application logic is executed and the result is processed. System administrators can configure result cache settings such as the number of cache slots, time-outs, and cache cleaning interval.
Application events	Based on time criteria or other event criteria, allows applications to send and receive emails, to invoke an AppLogic, or (for Java applications) to invoke a servlet. This is useful for administration.
HTML streaming	Provides streaming of data back to HTML clients so as to return data more efficiently.
Extensions	Allow enterprise applications to integrate with applications deployed on NAS. Extensions are persistent modules that are dynamically loaded into NAS and are accessed by multiple AppLogics or EJBs over the life of the extension. Although extensions act as application services, extensions can also be considered as application components.

Services Hosted by KJS Only
The following services are available only to applications written in Java:


Application Service	Description
JSP compiler	Interprets JSP tags, the HTML-like tags that determine the layout of pages sent to a web browser. The compiler supports Version 0.92 of the JavaServer Pages specification.
Servlet container	Contains and manages servlets through their life cycle by providing network services over which requests and responses are set, by decoding MIME-based requests, and by formatting MIME-based responses. Supports HTTP and HTTPS.
EJB container	Provides a home for EJBs and manages the beans it contains. Management involves registering beans, providing a remote interface for them, creating and destroying instances, checking security, managing their active state, and coordinating distributed transactions. The EJB container can also manage all persistent data within the bean and includes a full global transaction manager.
Distributed transactions	Supports transactions involving multiple databases (of different types or in different locations). A distributed transaction is invoked from an EJB and uses the built-in transaction processing manager of NAS.
LDAP support	Eases management and security by providing a central repository for information about users, groups, and access control lists. LDAP clients that ship with NAS include NAS Administrator and Netscape Directory Server.

System Services System services increase the efficiency with which application requests are processed. These services are not directly used by applications, but rather provide additional application support outside the scope of application logic. There is no API access to system-level services. A description of these services is provided in the following table. (Note that some of the following services are described elsewhere in this chapter.)


System Service	Description
Protocol management	Manages communications with clients by supporting the various protocols used by the Netscape Application Server.
Request management	Manages requests as they arrive at the server, routing them to the proper processes (either the Java Server or the C++ Server) and managing request thread allocations.
Global Directory Service	Determines the programming language of an application component so it can be loaded into the appropriate server process, KJS or KCS.
JNDI	The Java Naming and Directory Interface (JNDI) is a standard extension to the Java platform. The JNDI API provides Java applications with a unified interface to multiple naming and directory services in the enterprise.
Event logging	Maintains a log of application logic execution. Application developers can enable logging in their application logic to assist with debugging and tuning. In addition, system administrators can enable automatic event logging, which records the messages generated by dynamically loadable modules (DLMs) and application logic objects when processing user requests. Event logging can run in all processes.
Load balancing	Determines how application request loads are balanced among multiple servers.
Application request caching	Caches application requests so that future requests for the same application components by the same user are handled immediately.
Asynchronous processing	Provides processing of multiple requests at the same time when they arrive at varying times.
Failure recovery	Restarts the Executive Server, Java Server, or C++ Server processes if they ever become unavailable.
Distributed data synchronization	Supports failure recovery by synchronizing data. Data is synchronized not only across all KJS or KCS processes running in NAS, but also across all NAS installations within a cluster.
SNMP support	Provides access to NAS via SNMP agents, thereby allowing remote management from third-party administration tools.
Kernel services	Provide low-level services to all other services and subsystems. Examples of kernel services include language-binding engines and the lock manager.

Transaction Management System The transaction management system supports access to back-end databases.

C++ applications access databases using classes and interfaces provided in the NAS API, also called the Foundation Class Library.

Java applications access databases using the standard JDBC API.

Local versus Global Transactions
For Java applications, NAS supports both local transactions and global (also called distributed) transactions.

Global transactions span multiple databases (optionally of different types). Global transactions occur using a two-phase commit from Encina, a transaction manager built into NAS. Local transactions involve access to a single database. They provide better application performance because they are less complex.

Global transactions can only be begun declaratively through EJBs. By contrast, local transactions can only be begun programmatically, from either servlets, JSPs, or EJBs.

Architectural Details
The following figure shows the architectural details of the transaction management system:

Both the JDBC and NAS APIs rely on the Data Access Engine to interact with database drivers. NAS provides native support for the following database drivers: Oracle, DB2, Informix, Sybase, and (on Windows NT only) SQLServer.

The transaction management system also includes the Java Transaction API (JTA). JTA is used for connections to a single database. JTA specifies local Java interfaces between the transaction manager the other transaction elements (which include NAS and the transactional application). JTA provides a Java mapping of the industry-standard X/Open XA protocol, which is used by the Encina transaction manager.

For more information about accessing databases, see the Programmer's Guide.

Security In NAS, security is supported across all subsystems through the use of LDAP and other secure protocols. For more information, see "Security".

Administrative Services Administrative services run in KAS, the Administrative Server process. KAS enables remote administration of servers and applications. KAS also supports other services, such as application partitioning, event logging, request monitoring, and dynamic configuration of key server settings.

Clients that access administrative services include NAS Administrator, Netscape Directory Server, and third-party SNMP agents. For more information, see "Management Capabilities".