Administrator's Guide
CHAPTER 3
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:
This section describes the recommended application server configurations for production. For simplicity, the descriptions assume a single (standalone) application server.
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:
The application server does not compete with the database servers for CPU and memory resources.
The machine that hosts each database server can be configured to match that application server's memory requirements.
Database servers can be optimized and tuned without affecting the application server.
You can run your database servers on operating system platforms other than the one the application server is running on. For example, you can run UNIX database servers and the application server on Windows.
Drawback One drawback to configuring application servers and database servers on separate machines is that you must maintain extra machines.
For more information about possible configurations for your production application server environment, see Network configurations.
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.
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:
This section presents several possible ways to configure your network based on your application's needs and includes these sections:
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:
The amount of data returned to the clients is small (such as a standard departmental application).
Failover capabilities are not required. In some cases it may be acceptable to take the server down for infrequent administrative tasks such as a hardware upgrade or tape backup. So a clustered server arrangement is not a requirement.
All users are authenticated against a single, existing security model. A department or site may have a preexisting server listing of users and groups (for example, a Windows domain), so this directory can be leveraged and used by the application server.
Benefits of this configuration This configuration has several benefits:
Limitations of this configuration This configuration may be suitable for small companies or departmental applications, but there are some limitations to this approach:
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:
Limitations of this configuration This configuration has some limitations:
No firewall or additional security mechanism is provided to protect unauthorized access to unsecured LAN resources.
While this configuration could be used for Internet applications, there is no provision for DNS masking, such as the kind needed with a more advanced dispatcher. As such, all application servers and Dispatchers would need to be DNS-registered on the Internet.
To learn more For more information about clusters and load balancing, see Administering a Cluster.
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:
The user accesses an application server URL from one of the Web servers outside the firewall.
The WSI module responds to the browser with an HTTP redirection to the application server.
The browser automatically requests the URL directly from the application server, through the firewall.
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:
Limitation of this configuration This configuration has the following limitation:
Load balancing and failover Given that users inside the company and external business partners both use this application, the lack of load balancing and failover capabilities means that server downtime results in users not accessing the application.
To learn more For more information about WSI modules, see Using the Web Server Integration Modules.
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.
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:
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.
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 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.
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 .
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 information on URL rewriting for servlets and JSP pages, see How session tracking works next.
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:
http://server/db/foo;pparam=foo?qparam=bar&rparam=bar
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 ...