Administrator's Guide


Server Configuration

This chapter describes basic hardware configurations for the Novell exteNd Application Server and explains how the server operates in the Web environment. It contains sections on:

Top of page

Server configurations

This section describes the recommended application server configurations for production. For simplicity, the descriptions assume a single (standalone) application server.

Top of section

Production environment

In a production environment, it is best to configure your application server and database server(s) on separate machines. (This is called a multiple-host configuration.)

The figure below shows the preferred application server configuration with two database server connections:


The SilverMaster database (shown above with the application server) is a master database for the entire system. For a description of SilverMaster, see SilverMaster functions.

Having another Web server in this configuration would have little impact on the application server. The application server can coexist with Web servers as long as you change the application server's listening port from the default (port 80) to another port. For more information, see Specifying general server properties.

Benefits   Configuring the application server and database servers on separate machines results in the following benefits:

Drawback   One drawback to configuring application servers and database servers on separate machines is that you must maintain extra machines.

For more information    For more information about possible configurations for your production application server environment, see Network configurations.

Top of page

Firewalls and proxy servers

Firewalls are critical for regulating network access. You must make many decisions about how you will use firewalls, how the application server will communicate with database servers, and what if any access you will allow Anonymous users through the firewall.

In a typical large-scale Web environment, a static traffic routing service is placed between the network service provider's router and the internal network. The traffic routing service may be implemented at an IP level using screening rules in a router—or at an application level using proxy gateways and services.

About proxy servers   A proxy server is an application that mediates traffic between a protected network and the Internet. Proxy servers are used primarily to consolidate Internet connections, provide users a general level of anonymity (by shielding information normally passed from the browser to the Web server), and enforce enhanced security about Web traffic (such as what sites users can access).

Many proxies contain extra logging or support for user authentication. Since proxies must understand the application protocol being used, they can also implement protocol-specific security. The proxy machine provides a higher level of audit and security, but it also increases configuration costs and reduces the level of service—because a proxy needs to be developed for each desired service.

NOTE:   The proxy server software you use with the application server should support HTTP 1.1, such as the Microsoft Proxy Server or the Netscape Proxy Server.

About firewalls   A firewall is a hardware or software facility used to regulate access to a network. Firewalls are traditionally used to protect the company's intranet from public Internet traffic. Policies are configured on the firewall to allow only certain traffic to pass through. The actual mechanism involved varies, but in principle the firewall can be thought of as two mechanisms: one that exists to block traffic and another that exists to permit traffic. Administrators can configure a firewall to notify them of security breaches and monitor overall traffic.

Top of section

Configuration with a firewall and proxy server

The application server should run inside any firewalls your site has, with the HTTP requests from extranet customers to the application server either allowed through the firewall or proxied. This way the database connections need not go through the firewall. The figure below shows how an application server might be configured with a firewall and proxy server:


Top of page

Network configurations

This section presents several possible ways to configure your network based on your application's needs and includes these sections:

Top of section

Simple intranet configuration

Small companies, departments, and small teams of developers can work against a single application server. The following figure shows a simple network configuration with the application server (agsrv1) hosting a simple Web application serving users on a local area network (LAN). The application server leverages an existing Windows security domain (on pdc1) and e-mail server (mailsrv1) for user authentication/access control and pushing application data to users via e-mail:


The server's SilverMaster resides on the database server machine (dbsrv1) where the line-of-business database resides. The application is deployed to SilverMaster.

When this configuration makes sense   This type of configuration is suitable when:

Benefits of this configuration   This configuration has several benefits:



Simple administration

Administration of a single application server machine is easier than maintaining a group of computers hosting a cluster of servers.

Simple network topology

Because the number of users is small and the application complexity is low, there is no additional network configuration to make beyond ensuring proper TCP/IP connectivity.

Limitations of this configuration   This configuration may be suitable for small companies or departmental applications, but there are some limitations to this approach:



Load balancing and failover

This solution offers no provision for maintaining application availability in the event of server downtime. A hardware failure on agsrv1, for example, would mean that no users could access the application until the problem was resolved.

Internet use

While suitable for smaller, intranet applications, this scenario provides no security mechanism for external use by Internet users. No firewall is provided to protect unauthorized access to unsecured LAN resources. And the Intranet security server (pdc1) is not used to authenticate external Internet or extranet users.

Top of section

Intranet cluster configuration

In order to provide basic load balancing and failover capabilities, the application server provides a Dispatcher, Load Manager, and Cache Manager. The figure below shows a typical network diagram of several application servers (agsrv1, agsrv2, and agsrv3) in a cluster with traffic directed by the application server's software Dispatcher (dispatch1). The Cache Manager and Load Manager can reside on just about any machine in the network, though it is preferable to have them on the same physical subnet as the cluster of application servers.


In this scenario, a browser on one of the corporate workstations would access the application by connecting to the application server's software Dispatcher (dispatch1) using a browser or a Java application running in the SilverJ2EEClient container. Depending on the load plan, the Dispatcher would reply with an HTTP redirection to one of the available servers in the cluster.

To establish a connection, the client needs to resolve the TCP/IP host name of the target server using standard means. On Windows workstations, for example, the client would request the TCP/IP address of the target server from the WINS (Windows Internet Naming Service) or DNS (Domain Naming Service) server, or perform an NBT (NetBIOS over TCP/IP) broadcast to resolve the name and address. When they are resolved, the client would access the server directly. No subsequent trips to the Dispatcher would be made.

HTML application example   A corporate user opens a browser to http://dispatch1/Accounting/default.html in order to log in to the company's accounting HTML application. The software Dispatcher (dispatch1) returns an HTTP redirect signal back to the client, which in turn establishes a connection directly to http://agsrv2/Accounting/default.html. Notice that not only was the browser redirected to the application server (agsrv2); the full URL address information (database name, Accounting, and page name) was also passed along.

The next user to access the application would be directed in round-robin fashion to the next available server according to the load plan: http://dispatch1/Accounting/default.html would be redirected to http://agsrv3/Accounting/default.html.

Benefits of this configuration   This configuration has several benefits:



Server redundancy

In this load-balanced scenario, administrators are free to take down one or even two of the application servers for maintenance, because the other servers would be available for incoming requests provided that the remaining servers could accommodate the load.

Ease of administration

Setting up the cluster is extremely easy: initial configuration is wizard-based, and every aspect of server administration is done using the SMC.

There's no additional hardware or software (such as a third-party dispatcher or firewall) required to install and maintain this configuration.

Load balancing

This configuration is flexible: as the number of users grows, the number of servers can expand to accommodate them. The distribution of load across servers means that no one user can cause the server to be a bottleneck for other users in the organization.

Limitations of this configuration   This configuration has some limitations:

To learn more   For more information about clusters and load balancing, see Administering a Cluster.

Top of section

Simple Internet configuration

The figure below shows how a single application server can be used to provide extranet Web application functionality for both internal users (running a Java application using SilverJ2EEClient) and external business partners (accessing the HTML application over the Internet).

In this scenario, the application server (agsrv1) provides Web application services in conjunction with existing static content served from the corporate Web site servers (www1 and www2). The application server (agsrv1) is DNS-registered; so when an extranet user is linked from the Web site to the application logon page (hosted on the application server), the browser knows what route to take in order to connect to the application server. In this case, Internet clients must pass through the firewall (gatekeeper1) in order to gain access to the application server.


To facilitate this connection, the firewall (gatekeeper1) has been configured so that only HTTP traffic on TCP/IP port 80 can pass through to the application server. This way system administrators are assured that the application-sensitive data will not be intercepted by someone other than the end user—and that incoming traffic cannot access other corporate resources.

The user accesses the application from a link on the corporate Web site (www1 and www2). A Web server integration (WSI) module has been installed and configured on both Web servers and offers redirection capabilities to the logon page on agsrv1. Once redirected, browsers will establish a connection to the application server.

This process can be summarized as follows:

  1. The user accesses an application server URL from one of the Web servers outside the firewall.

  2. The WSI module responds to the browser with an HTTP redirection to the application server.

  3. The browser automatically requests the URL directly from the application server, through the firewall.

  4. For user authentication, upon connecting through the firewall to the application server (agsrv1), the user is prompted to log on to the application. A listing of extranet users is maintained in the server's SilverMaster database. This database, like the database serving the e-commerce application, is maintained on dbsrv1. The user enters the logon credentials and is logged on and can commence using the application.

Internal to the company, corporate users interact with extranet users using a Java application (using the SilverJ2EEClient container). For administrative purposes, corporate IT uses the SMC on HTTP port 80.

Benefits of this configuration   This configuration has several benefits:



Secure e-commerce application

HTTP traffic between extranet users and the application server can pass safely over the Internet through the firewall. Administrators can log all logon activity using the firewall.

Ease of administration

Configuring the application server for use with the existing network was a simple case of adding a policy to the firewall configuration (for example, allow HTTP traffic to pass to agsrv1 on TCP/IP 80 and log all activity).

Limitation of this configuration   This configuration has the following limitation:

To learn more   For more information about WSI modules, see Using the Web Server Integration Modules.

Top of section

Internet cluster configuration

Larger-scale e-commerce applications usually require a very high degree of functionality, throughput, and availability. This requires an underlying system architecture that is more robust and complex than those previously shown.

The figure below shows an example of a large-scale Internet application served from a cluster of application servers. Internet users access the application using links from the two Web servers (www1 and www2) located outside the firewall (gatekeeper1).


In order to implement transparent session-level failover and reduce overall DNS and firewall administration, the system administrators install a third-party hardware dispatcher that supports DNS masking, as opposed to using the application server's software dispatcher. This way traffic to all application servers can be localized to a single TCP/IP address and host name on the Intranet (www3). In addition, with this type of device only one TCP/IP address and host name have to be DNS registered, as opposed to four machines when using the application server's software dispatcher (dispatch1, agsrv1, agsrv2, and agsrv3).

When any incoming requests are linked to the Web application itself (on www3), the browser establishes a connection through the firewall to the Web dispatcher. Based on its own load plan, the hardware dispatcher connects the browser to an available server in the cluster. Unlike the application server's software dispatcher, the hardware dispatcher controls the flow of all HTTP traffic. In the event that the server goes down, the dispatcher can automatically route the browser session to a different server in the cluster. Since the dispatcher uses DNS masking, the failure is completely transparent to the end user.

To learn more   For more information about clusters and load balancing, see Administering a Cluster.

Top of section

Demilitarized Zone (DMZ) Internet configuration

The complexity of Internet security and network infrastructure is often related to the size of a company. Larger companies with complex e-commerce Internet and extranet applications, for example, may have a two-tiered approach to firewall security.

The following figure shows such an example. All Internet traffic is routed through an Internet firewall (gatekeeper1). This firewall allows only Web traffic and Internet mail through to the Demilitarized Zone (DMZ), the area between the two firewalls. For security purposes, all Web and application servers reside in the DMZ.


It would have been possible to add a third network card to the firewall and have it protect Intranet traffic as well. However, for security reasons, this company decided to use separate devices.

DNS-masking hardware dispatchers (www and apps) are used to route traffic in a load-balanced fashion. It is also possible to use one device configured for multiple TCP/IP addresses and route traffic to both clusters. For redundancy purposes, however, two separate devices are used.

The Intranet firewall (gatekeeper2) allows e-mail traffic and database connections from the application servers (agsrv1 and agsrv2) to pass through. This way the system administrators can be assured that only e-mail traffic and database calls from the secured DMZ (the application servers) can access corporate information.

External users can be authenticated by obtaining a browser certificate from the certificate server (cert1). The application servers can authenticate these users based on their certificates and encrypt the network traffic from the browser to the application server.

Benefits of this configuration   This configuration is beneficial where there are the following requirements:




System administrators have carefully designed this architecture to ensure that traffic from the outside world can only pass into the DMZ. For example, this multitier approach to security allows for tighter control over the origin of database access.


Server clusters are used for both static Web content and application services. Even the hardware dispatchers provide redundancy among themselves.

Session-level failover

The DNS-masking capabilities of the hardware dispatchers allow for this e-commerce application to run continuously, even in the event that a server fails (the user is automatically rerouted to another server).

High volume

The scalability of a multicluster server arrangement means that user load can be distributed among many servers. This is especially beneficial during peak periods of application usage.

This architecture is complex and more difficult to maintain than the average intranet site. However, you might want to set up this type of architecture to ensure the benefits listed above. Downtime often equates to loss of business. Maintaining a well-designed network infrastructure often pays for itself very quickly.

To learn more   For more information about clusters and load balancing, see Administering a Cluster.

Top of page

Session management

The application server stores information about each client connection in a session object. A session is initiated when a client first connects to the server. Information in the session object includes information like user authentication. Applications can also store application-specific data in the session object. If a session containing a servlet or JSP page is idle for more than five minutes (the default), it is terminated. Use the SMC to change the session timeout value (by setting the Timeout on server request value).

For more information    For more information on setting the Timeout on server request value, see Setting performance parameters.

The application server can use either cookies or URL rewriting to keep track of the state of multiple Web browser clients. Both cookies and URL rewriting use session IDs. All calls to the server within a browser session will operate under the same session ID. For secure data, authentication occurs once per active session for sessions requiring user authentication.

Authentication is the process through which the server and client verify one another's identities. Authentication is described in Enabling authentication.

Top of section


The application server uses cookies to track sessions if the user's browser supports them. A cookie is a piece of information sent by a Web server to a Web browser. The browser client stores the cookie and sends it back to the server whenever an additional request is made to the server. The application server uses the cookie as a session ID. When the server receives a request from a client that includes a cookie, it is able to use the information stored in the cookie to reconnect with the session.

IMPORTANT:   The application server cookies are kept in memory and are never written to disk. There is no personal user or tracking information in the cookie.

If you or your users are concerned about the contents of cookies, you can set your browser not to accept cookies or to warn on cookies. For details about cookie, see your browser documentation .

Top of section

URL rewriting

To support browsers that do not accept cookies, the application server rewrites URLs (with an appended jsessionid parameter) to correctly associate a request with a session. Application developers writing servlets or JSP pages need to understand how to use URL rewriting to support clients that do not accept cookies.

For more information    For information on URL rewriting for servlets and JSP pages, see How session tracking works next.

Top of section

How session tracking works

The application server uses cookies if the user's browser supports them and uses URL rewriting if the browser does not. This determination happens at runtime for each user. The first time the application server receives a request, it sets a cookie—and also appends a jsessionid to the URL (because it does not yet know whether or not the client supports cookies).

When a client supports cookies, the application server will use them for session tracking (although it will rewrite the URL when it receives the first request). Once the client returns a cookie, the server will stop rewriting URLs for the client in this session.

NOTE:   Cookies use the value JSESSIONID (all uppercase); URL rewriting uses jsessionid (all lowercase).

Administrator notes   If the server determines that the client does not accept cookies, it uses the jsessionid in the URL for session tracking whenever the user clicks a link that is contained on a page.

The first time a client establishes a session, the URL jsessionid is appended to the URL and is visible to the client user. On subsequent interactions between server and client, the URL rewriting keeps track of the session ID, and the jsessionid is visible only when a user's mouse is held over a link on the page.

When a browser client does not accept cookies, servlets and JSP pages that use HTML links need to call one of two standard encode methods (described in Developer notes next) to rewrite URLs.

Developer notes   The following encode methods enable the server to check for the existence of either a cookie or a jsessionid:

One of these encode methods is needed when servlets or JSP pages explicitly create or embed URLs in their responses.

The jsessionid in the URL is a path parameter, not a query parameter. Query parameters are usually at the end of the URL and separated by a ?. Path parameters are at the end of a component of the URL and before any query parameters. In the following example:


pparam is a path parameter and qparam and rparam are both query parameters.

Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved.  more ...