Hardware/Operating System Requirements Both Domino and WebSphere run on a variety of hardware and software platforms. In particular, Domino runs on Windows 2000/2003, AIX, Solaris, HP-UX, Linux, Netware, OS/2, OS/400 (IBM iSeries), and z/OS (IBM zSeries), while WebSphere runs on Windows 2000/2003, AIX, Solaris, HP-UX, and Linux for Intel and IBM iSeries, pSeries, and zSeries processors. Linux is becoming an operating system to seriously consider for both WAS and Domino. Linux on Intel or AMD servers is popular for low to mid-range servers (up to eight processors) because of generally lower cost. Moreover, Linux spans the widest range of server types, from blade server to enterprise mainframe so that common system administration resources can be applied. It is important to note that as a complete operating system, Linux is provided in various combinations of specific component ( especially kernel and library) versions, referred to as "distributions." For both WAS and Domino, IBM provides support for only certain Linux distributions, namely RedHat, SuSE, and distributions conforming to the United Linux 1.0 standard. It is likely, however, that WAS and Domino will run without problem on Linux distributions similar to these, such as Mandrake Linux, which is similar to RedHat. The basic hardware requirements are what you would expect for large, sophisticated system applications. System memory size is the most important hardware requirement. Both WAS and Domino specify a recommended amount of 512MB, but for best performance you should provide the most memory you can afford. Processor speed is recommended to be at least equivalent to a 500MHz Intel PentiumAE processor but again should be as high as affordable. Disk space requirements vary by the specific operating system platform but are in the range of 600-800MB for WAS and 500MB for Domino. The disk drives and interfaces themselves should be high-performance, as usually found in most server systems. Careful consideration should be given to the use of external storage systems such as storage area networks or network file systems as repositories for WAS or Domino data because they may degrade application performance. A set of hardware requirements often overlooked in the design of WAS and Domino systems is that related to the network hardware. The speed and bandwidth capacity of the network routers and firewalls should be sufficient so as not to introduce delays in the data paths to or between the WAS and Domino system components . WAS and Domino Product Coexistence Domino and WAS have long had product features that allow them to work together, but in order for the features to work properly, the correct versions of Domino and WAS are required. Sometimes the versions must be at a specific service update level. For example, Single Sign-On (SSO) is one very important feature for applications built on Domino and WAS. (The SSO feature lets Domino and WebSphere recognize when either server has already authenticated a user , as is described in detail in Chapter 12, "Security and Single Sign-On.") The first version for which SSO could be enabled for Domino was R5.0.5. The first version of WAS (Advanced Edition) for which SSO could be enabled was version 3.5 with service update (fix pack) number 1, or version 3.5.1. The SSO feature of iSeries was first available with Domino for AS/400 5.0.6a and WAS 3.5. Servlet access to Domino databases was first available on iSeries with Domino for AS/400 5.0.4 and WAS 3.0.2. The ability to use Domino HTTP Server to access WAS resources was first available on iSeries with Domino for AS/400 5.0.5 and WebSphere 3.5.1. In order to have Domino and WAS work together, the requirements are as follows : But this is somewhat ancient history now. Significant new releases of both Domino and WAS were made available at the end of 2002 with the Domino R6 and WAS V5 products and continue on almost a yearly basis. HTTP Server Considerations Another area of interoperability between WAS and Domino is the HTTP server plug-in, which enables J2EE servlet and JSP requests to be forwarded to WAS for processing. WAS provides various plug-in modules for different HTTP server products such as Apache, IBM HTTP Server, Microsoft IIS, and Domino's integrated HTTP server. In the case of the Domino HTTP server, the WAS plug-in is provided as part of the Domino product package. Various plug-in modules are provided corresponding to the different WAS versions and operating systems. Table 6-1 lists the set of plug-in modules provided by WAS V5. Table 6-1. Plug-in Modules Provided by WAS V5 | System | Web Server | Plug-in Executable File | | Windows | IBM HTTP Server | mod_ibm_app_server_http.dll | | | Lotus Domino | libdomino5_http.dll | | | Apache | mod_app_server_http.dll | | | iPlanet (Netscape) | libns41_http.dll | | | Microsoft IIS | iisWASPlugin_http.dll | | IBM AIX | IBM HTTP Server | mod_ibm_app_server_http.so | | | Lotus Domino | libdomino5_http.a | | | Apache | mod_app_server_http.so | | | iPlanet (Netscape) | libns41_http.so | | | HP-UX IBM HTTP | Server mod_ibm_app_server_http.sl | | | Lotus Domino | libdomino5_ http.sl | | | Apache | mod_app_server_http.sl | | | iPlanet (Netscape) | libns41_http.sl | | Solaris | IBM HTTP Server | mod_ibm_app_server_http.so | | | Lotus Domino | libdomino5_http.so libdomino6_http.so | | | Apache | mod_app_server_http.so | | | iPlanet (Netscape) | libns41_http.so | | Linux | IBM HTTP Server | mod_ibm_app_server_http.so | | | Apache | mod_app_server_http.so | | Note that there is no WAS plug-in provided for the Domino HTTP server on the Linux platform. Most of these modules are also shipped with the Domino product (except for the HP-UX modules). |
With the recent versions of WAS, the communication mechanism between the WAS HTTP server plug-in and WAS itself has been changed from a proprietary mechanism to HTTP. This change has greatly simplified the configuration and setup of WAS and the plug-in. The use of HTTP makes it easier to configure the network layer, especially firewall systems, to support the plug-in connection to WAS. The implication that WAS now provides its own HTTP server is true. Although the WAS HTTP server is far from a full-fledged HTTP server, it is sufficient to provide a quick and easy means for accessing WAS without having to set up a separate HTTP server. As we will see later, the built-in WAS HTTP server is also used to provide a Web administration interface instead of a separate administration process and corresponding client. Given that the Domino HTTP server is the only HTTP server that can provide Web access to Domino databases (like a client's mail or address book database), the situation arises where you need to provide both a "standard" HTTP server and the Domino HTTP server. In this case, you can simply configure the Domino HTTP at a different port or (virtual) host from the other HTTP server. Then the application can supply URLs for Domino resources specifying this alternate port or hostname. Another approach available on Windows systems is to use Microsoft IIS as the HTTP server and configure it to use a plug-in that redirects Domino requests. This IIS Domino plug-in can be used in addition to the IIS WAS plug-in. For certain IBM platforms, namely the iSeries (OS/400) and zSeries (z/OS), it is difficult to run multiple HTTP servers because the HTTP server is essentially built into the operating system. In these cases, there are also HTTP plug-in modules available for Domino on the iSeries platform (refer to the IBM Redbook, "Domino and WebSphere Integration on iSeries," for details) and the zSeries, similar to the Domino plug-in for IIS. These Domino plug-ins can be run in combination with the WAS plug-ins on these platforms. See the section on configuring the Domino HTTP server plug-in later in this chapter for details on how the HTTP plug-in can be configured to work with WAS. Networking Considerations Prior to installing WAS and Domino, it is a good practice to establish your network naming conventions. For most applications, you will want to use fully qualified host names for the WAS and Domino servers, that is, names consisting of a TCP/IP host name and domain name. If you don't have a domain name system (DNS) server set up, it is possible to configure each server operating system with the host/domain name to IP address mappings (e.g., via the /etc/ hosts file on both Unix and Windows systems). Certain features in WAS and Domino require fully-qualified host names to work, especially SSO. If Domino servers don't already exist in your network, you'll want to establish a Domino naming convention for the servers. Here you'll need to pick a common Domino domain name and server names for the planned Domino servers. For those new to Domino, the Domino domain name is altogether different than a DNS domain name, although conceptually they are quite similar. The Domino servers will need to be given fully qualified TCP/IP host names in addition to their Domino server names. If you plan to use SSO across your WAS and Domino servers, you will need to put all of the WAS and Domino servers in a single DNS domain and all of the Domino servers in a single Domino domain. One area of network planning often overlooked until deployment is that of firewall rule configuration. As mentioned previously, WAS and Domino servers are usually deployed to a tiered network where the tiers are separated by firewall systems. As a result, a Web application can easily span every tier , and the communication between the components running on WAS and Domino will need to be permitted to pass through the firewalls. Since the firewall systems control TCP/IP sessions by their source and destination host addresses, and ports and TCP/IP protocols are usually associated with specific ports or port ranges, you should understand which protocol types must be allowed to pass to, from, or between WAS and Domino. Besides HTTP, WAS and Domino servers may make use of several other Internet (and proprietary) protocols, such as LDAP, SMTP, DIIOP, SSL, etc. TCP/IP protocols used by other components such as database servers or chat servers must be taken into account as well. Domino Server Configuration and Set-Up Considerations The Lotus Domino R6 Server family consists of the Domino Mail Server, the Domino Application Server, and the Domino Enterprise Server. Most likely you will want to do more with Domino than just use its HTTP server to integrate with WebSphere, so you will want to install either the Application or the Enterprise server. The Domino server supports various features, especially Internet protocols, which may be useful for your planned applications. These features and protocols include the following: -
Access to the Domino directory via the Lightweight Directory Access Protocol (LDAP) . LDAP access may be used with SSO. (We discuss SSO in detail in Chapter 12.) -
Simple Mail Transfer Protocol (SMTP) . Web applications could make use of SMTP, especially via the JavaMail API, for sending e-mail. -
Post Office Protocol (POP) . An e-mail client-to-server protocol. -
Internet Mail Access Protocol (IMAP) . Another e-mail client-to-server protocol. -
Domino Internet Inter-Object Protocol (DIIOP) . DIIOP is a communication mechanism for invoking Domino functions in a client-server model. It is required if J2EE components running on a WAS server make use of the Domino Java API to access remote Domino servers. Depending on your application requirements, you may want to enable or disable a specific set of Domino features or protocols. WAS Configuration and Set-Up Considerations The deployment options for a WAS installation are many. With just the WAS Advanced Server edition, it is possible to set up multiple application server instances on a single system. This can be done even among different WAS versions. Or it can be done where the instances are at the same level and share a common runtime. With the Network Deployment edition, WAS can be installed and managed across multiple systems. A network deployment consists of " cells " containing "nodes" containing application server instances. The WAS deployment options are flexible enough to accommodate almost any installation requirements. You can plan a deployment to suit your needs ”be they performance, capacity, or compatibility with previous deployments. We do not cover the deployment options in detail in this book and restrict our discussion to a single-server deployment. The WAS administrative interface allows an administrator to manage WAS nodes, cells, and servers, as well as the applications running in them. It provides the means to monitor application server activities, manage security, and adjust the configuration. With WAS V5, the administrative interface is now a Web interface, the administration application is a Web application running on the application server, and the configuration data is maintained as a set of XML files on the server's filesystem. It is accessed directly on the server by specifying the server's host name and the port for the administrative application. Note that with the use of XML files to store configuration data, WAS is no longer dependent on a database system such as IBM's DB2. WAS requires a database system only if applications require it, such as for EJB entity beans. For SSO support, there are a number of considerations involving the set up of the user registry used for user authentication. Please refer to Chapter 12 for the details. General Installation Procedure for WAS and Domino This section describes in general steps the installation of WAS and Domino on separate systems. The steps presented here will give you an overall idea of how to build each server. For a detailed description of the installation for WAS 5.0 and Domino 6.5, see Appendix C. The steps are as follows: -
Check for necessary hardware and software prerequisites.
-
Verify the network configuration.
Working with the WAS system: -
Log on as a user with administration privileges (e.g., as "root" for Unix systems).
-
If a database is required, install the database software.
-
Install WebSphere via the install utility (Java GUI).
-
Install the latest service update (fixpack) and any relevant e-fixes.
-
Start WAS, and verify that WAS resources are accessible. The "snoop" servlet sample can be used for this.
Working with the Domino computer: -
If not available on any system, install a Notes Administration client.
-
Install the Domino server.
-
Using the Notes Administration client, configure the Domino server, and populate the directory.
-
If the Domino HTTP server will be used with WAS, ensure the plug-in module and configuration file are available to the server, and configure Domino to use the plug-in via the Administration client. Modify the plug-in configuration file if necessary.
-
Verify Domino resources can be accessed. If the plug-in was installed, verify that WAS resources can be accessed (e.g., the "snoop" servlet).
There is nothing in the installation procedure that prevents WAS and Domino from being installed on the same computer. Hardware and Software Prerequisite Details In this section, we list the hardware and software requirements for the computer you want to install on, as well as the different product software levels required. Platform Hardware: -
Pentium III or higher, with an absolute minimum of 256MB, but 512MB is recommended for WebSphere 3.5. We used 512MB for the computer on which we installed WebSphere and DB2 and 385MB for the computer on which we installed Domino for our testing, with satisfactory results. -
At least 600MB free on the drive or drives used to install the products. The disk space requirements of the products after installation are DB ”475MB, Domino ”300MB, IBM HTTP Server ”20MB, and WebSphere ”220MB. The DB2 space requirements can be reduced by 125MB if you choose to install the DB2 Administration client on a separate machine. The space requirement for Domino also can be reduced to a certain extent by choosing to install fewer components. For example, it is possible to not install the help files. These files alone require 50 MB. Similarly, the space for WebSphere specified above includes documentation files of about 60MB, which would not be needed in a production installation. Platform Software: Product Software Levels The product software levels we used were as follows: Higher versions of the products should also work. The highest currently available product level should be used except where specifically stated otherwise . Care should be taken, however, to check WebSphere for recent e-fixes. Creating a User with Administration Rights WAS, Domino, and DB2 must run under the permissions of a user or as system services. For testing purposes, it is more flexible to use a user ID with rights to run as an extension of the operating system than load the products as system services (however, WAS and DB2 must run as system services). For a production system, these products should run as services so that they will automatically load when the system is started without operator sign-on. Installing WebSphere Application Server V5 You can either install WebSphere from a product CD or one large installation file. If you use a product CD, the installation program should start automatically when you insert the CD. If not, you have to run the setup.exe program on the CD. If you have one big file, simply start the installation by running the file. It will automatically unpack itself and start the installation program. Note that the installation process itself requires 70MB or more free in the system temporary directory, even if installation is to another drive or volume. Step by step details are given in Appendix C. Installing and Configuring Domino 6 We now turn our attention to our Domino computer and the installation of Lotus Domino. The Lotus Domino R6 Server family consists of Domino Mail Server, Domino Application Server and Domino Enterprise Server. If you want to do more with Domino than just use its HTTP stack to integrate with WebSphere, you should install the application or the enterprise server. To use the Domino HTTP stack and enable Single Sign-On, WebSphere V5 requires Domino Server R5.0.5 or higher. Step by step details for the installation of Domino Enterprise Server R6.5 are given in Appendix C. You need to install the Domino administration client on your server or another workstation (Lotus recommends using a separate workstation for administration). This will allow you to change the server's settings easily, especially those in the Domino directory; although much, but not all of the testing we describe can be managed by direct access to the server's text console. We will not describe the installation of Domino Administrator in detail. Be sure that the Administration Client is selected for installation; you can accept all other default values during the installation. One of the first things you can do after installing Domino Administrator is allow your users to run Java programs on the Domino server. Configuring Domino to Use the WebSphere Plug-In The plug-in itself is provided as a shared library (DLL for Windows, .a for AIX, .so for Solaris, and as of this writing no plug-in exists for Domino on Linux) and a default configuration file: plugin-cfg.xml. The plug-in files are packaged with both the Domino and WAS product. The plug-in files can be found under the Domino install path : ./Domino/Data/domino/plugins/was5. There are two essential steps to installing the plug-in: 1) specifying the plug-in library file to the Domino HTTP server and 2) specifying the location of the plug-in configuration file to the plug-in itself. The first step is straightforward and simply requires a change to the Domino server document in the Domino Directory database (names.nsf). You specify the plug-in library file as a DSAPI filter file on the Internet Protocols/HTTP page of the Server document. The second step is not as straightforward and is operating system-dependent. The plug-in library itself looks for the plug-in configuration file via an operating system environment variable (registry key on Windows). Unfortunately, these variable names are not well advertised in the WebSphere or Domino documentation. For IBM iSeries systems, the configuration file location is specified in the Domino notes.ini file. See Chapter 10 and Appendix C for the details on how to specify the plug-in file location and the plug-in configuration settings themselves. Once these settings have been made, you can restart the Domino HTTP server task to have it load the WebSphere plug-in as a DSAPI filter. If the settings are correct, you will see the following messages at the Domino console:
HTTP Server: Java Virtual Machine loaded WebSphere HTTP DSAPI filter loaded HTTP Server: DSAPI WebSphere HTTP DSAPI Filter Loaded successfully HTTP Server: Started
| 