Appendix A       iPlanet Application Server Architecture


This appendix describes the following topics:

• Server Processes

• System Components

Server Processes

---

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

Table A-1    iPlanet Application Server servers and their descriptions

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 iPlanet Application Server administration and failure recovery.
Java Server	KJS	Provides services to Java applications.

Summary of Process Interactions

The iPlanet Application Server processes figure shows how the four iPlanet Application Server processes interact to handle requests from clients:

Figure A-1   

iPlanet Application Server processes

When a web server forwards requests to iPlanet Application Server, 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 iPlanet Application Server 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 iPlanet Application Server environment for best performance by:

• Adding any number of iPlanet Application Server machines.

• Specifying any number of KJS and KCS processes.

• Maintaining any number of threads on each process.

In addition to providing high performance, the internal processes make it possible for iPlanet Application Server to remain available 24 hours a day, 7 days a week. If a KJS or KCS process goes down, the Administrative Server process (KAS) will restart it. Additional monitoring in iPlanet Application Server makes sure that the KAS process is always running.

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

The following sections describe the internal servers in more detail:

• The Executive Server

• The Administrative Server

• The Java Server and C++ Server

The Executive Server

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

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 iPlanet 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 iPlanet Application Servers. It registers with the appropriate server or servers all changes made to the system and application settings using iPlanet Application Server Administrator Tool (iPlanet Application ServerA), 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 iPlanet 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, iPlanet Application Server 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 iPlanet Application Server architecture. These systems are shown in the iPlanet Application Server architecture figure:

Figure A-2   

iPlanet Application Server

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

The following is a list of connectors, the protocols used and their functions that are managed by the Protocol Manager to enable communication between iPlanet Application Server and a client:

• Communication between a web server and iPlanet 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 iPlanet 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 iPlanet Application Server to the web server and to the web browser.

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

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

Figure A-3   

Protocol manager

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 iPlanet, Microsoft, and CGI-compatible web servers, respectively.

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

Load Balancing System

In an environment with multiple iPlanet Application Server 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.

Load Manager

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.

Load Balancer

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 iPlanet Application Server has its own load balancing module which makes routing decisions based on load balancing parameters. Administrators can tune these parameters using iPlanet Application Server Administrator.

After a request is routed to the appropriate iPlanet Application Server machine, the request is passed to the Request Management System.

Request Management System

Incoming requests are handled by the Request Management System. iPlanet Application Server 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 iPlanet Application Server's Global Directory Service (GDS) and iPlanet 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 file 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, iPlanet Directory Server authenticates the request by checking against known role information.

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 iPlanet Application Server Developer's Guide (Java).

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 table, Services available to Java or C++ clients, lists the services that are available to applications written in Java or C++:

Table A-2    Services available to Java or C++ clients

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 iPlanet Application Server 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.
Connectors	Allow enterprise applications to integrate with applications deployed on iPlanet Application Server. Connectors are persistent modules that are dynamically loaded into iPlanet Application Server and are accessed by multiple AppLogics or EJBs over the life of the extension. Although connectors act as application services, connectors can also be considered as application components.

Services Hosted by KJS Only

The table, Service available only to Java applications, lists services that are available only to applications written in Java:

Table A-3    Service available only to Java applications

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 iPlanet Application Server.
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 iPlanet Application Server include iPlanet Application Server Administration Tool and iPlanet 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 table, System services. (Note that some of the following services are described elsewhere in this chapter.)

Table A-4    System services

System Service	Description
Protocol management	Manages communications with clients by supporting the various protocols used by the iPlanet 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 iPlanet Application Server, but also across all iPlanet Application Server installations within a cluster.
SNMP support	Provides access to iPlanet Application Server 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 iPlanet Application Server API, also called the Foundation Class Library.

• Java applications access databases using the standard JDBC API.

Local versus Global Transactions

For Java applications, iPlanet Application Server 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 iPlanet Application Server. 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 Transaction Management System shows the architectural details of the transaction management system:

Figure A-4    Transaction Management System

Both the JDBC and iPlanet Application Server APIs rely on the Data Access Engine to interact with database drivers. iPlanet Application Server 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 iPlanet Application Server 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 iPlanet Application Server Developer's Guide and iPlanet Application Server Administrator's Guide.

Security

In iPlanet Application Server, security is supported across all subsystems through the use of LDAP and other secure protocols. For more information, see the iPlanet Application Server Developer's Guide and iPlanet Application Server Administrator's Guide.

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 iPlanet Application Server Administration Tool, iPlanet Directory Server, and third-party SNMP agents.