Chapter 3   Architectural Details


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

The chapter contains the following sections:

• Server Processes

• System Components

Server Processes

---

The architecture of iAS includes three main types of internal servers, which are often called engines or processes. They are responsible for all processing within iPlanet Application Server. The following table summarizes the internal servers:

Internal Server	Process Name	Description
Executive Server	KXS	Provides most system services such as Load balancing Dsync, repository and failover.
Administrative Server	KAS	Provides system services for iAS administration and failure recovery.
Java Server	KJS	Provides services to Java applications.

Note that C++ applications are supported in iPlanet Application Server 6.0 for compatibility. All new applications should be developed using J2EE tools.

Summary of Process Interactions

The following figure shows how the four iPlanet Application Server processes interact, and the relationship of the application server to other complementary services:

When a web server forwards requests to iAS, the requests are first received by the Executive Server process (KXS). The KXS process forwards the request either to a Java Server process (KJS). A KJS process runs Java programming logic. Note that for migration purposes a KCS, C++ engine exists and runs C++ programming logic. KCS runs in a similar manner to the KJS engine.

Each KJS 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 iAS 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 iAS environment for best performance by

• adding any number of iAS machines.

• specifying any number of KJS processes.

• maintaining any number of threads on each process.

In addition to providing high performance, the internal processes make it possible for iAS to remain available 24 hours a day, 7 days a week. If a 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 iAS makes sure that the KAS process is always running.

If all iAS processes go down, then other iAS machines in the cluster will take over, (this assumes a multiserver environment.) In addition, iAS can replace the index page with a redirected page and also send notifications by email and FAX to alert the system administrator and redirect the system to a different site.

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

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 iAS.

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

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

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

2. The request manager assigns a thread from the pool to the request and forwards the request to the appropriate Java Server which loads the application class if necessary and executes the application logic.

3. When the request completes, the thread is returned to the thread pool.

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 iAS Administrator Tool (iASAT), 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

The Java Server processes is the application server. Business logic components written in Java are hosted in the Java Server. Business logic components are the core of the application, holding the compiled code instructions written by the developer.

The Java Server (KJS) also hosts 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, iAS 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 iAS 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 iPlanet Application Server occurs through NSAPI, ISAPI, and optimized CGI. Optimization and superior performance are achieved through optimized communication via a plug-in on top of the internal protocol. Internal components manages different protocols as they are encountered.

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.

Load Balancing System

In an environment with multiple iAS 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. There are a number of types of load balancing:

iAS employs several load balancing methods for optimum performance:

• Weighted round robin load balancing

• Response time load balancing

• System load based load balancing

In addition, the following load balancing types are supported

• Intraserver process level load balancing

• JSP load balancing

• Rich client load balancing

Administrators can choose the best method and once implemented requests are routed to the most appropriate iAS machine.

Request Management System

Incoming requests are handled by the Request Management System. iAS 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:

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

• 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, 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 iAS's Global Directory Service (GDS) and iPlanet Directory Server, an LDAP server. 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.

For more information about application components, 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 a KJS process. The following sections summarize the services available to Java applications:

Services Hosted by KJS

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

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 iAS 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.
Database connection pooling	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 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 iAS. Connectors are persistent modules that are dynamically loaded into iAS and are accessed by multiple EJBs over the life of the extension. Although connectors act as application services, connectors can also be considered as application components.

S

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 1.1 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 iAS.
LDAP support	Eases management and security by providing a central repository for information about users and groups.

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.)

Table 3-1

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 (the Java Server) and managing request thread allocations.
Global Directory Service	Repository for all application server metadata information
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 result caching	Caches application results so that future requests for the same application components by the same user are handled immediately.
Failure recovery	Restarts the Executive Server, or Java Server processes if they ever become unavailable.
Distributed data synchronization	Supports failure recovery by synchronizing data. Data is synchronized not only across all KJS processes running in iAS, but also across all iAS installations within a cluster.
SNMP support	Provides access to iAS 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 provides support for the EJB transaction model. It is also responsible for the transparent propagation of the transaction context across processes and two phase commit coordination.

Local versus Global Transactions

For J2EE applications, iAS supports both local transactions and global transactions.

Global transactions can span multiple databases of potentially heterogeneous types,. Global transactions are managed and coordinated by the transaction manager, and can span multiple databases and processes. The transaction manager typically uses the XA protocol to interact with database back-ends. 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. Local transactions are native to a single database and are restricted within a single process.

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

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. There is also an ODBC driver. iPlanet Application Server can automatically configure the drivers if they are installed before iPlanet Application Server.

The transaction management system also includes the Java Transaction API (JTA). JTA is used for managing connections to a single database. JTA specifies local Java interfaces between the transaction manager and 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 for distributed database applications.

Architectural Details

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

Both the JDBC and iAS APIs rely on the Data Access Engine to interact with database drivers. iAS 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 user transaction interface specified in the JTA specification. This interface allows the application developer to explicitly demarcate transactions. For more information see the JTA specification and Programmer's Guide.

Security

Security in iAS is role based as specified in the J2EE specifications. Roles are defined by the application assemblers and are accorded permissions to access bean methods, servlets and JSPs. These roles are mapped at deployment time to LDAP users and groups.

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