Platforms Because both WebSphere and Domino can be run on several platforms, we will discuss the most popular platforms for these productsWindows, UNIX, and Linux. Windows The minimum hardware required for the WebSphere and Domino computers for the Windows platform consists of -
Pentium II or higher with a minimum of 256MB RAM (at least 512MB recommended). -
At least 600MB free space on the hard drives used to install the products. Here are the hard drive space requirements after installation: | DB2 | 475MB | | Domino | 300MB | | IBM HTTP Server | 20MB | | WebSphere | 220MB |
The DB2 space requirements can be reduced by 12MB if you choose to install the DB2 Administration client on a separate machine. The space requirements for Domino also can be reduced to a certain extent by choosing to install fewer components . For example, it is possible not to install the help files. These files alone require 50MB. Also the space for WebSphere specified here includes documentation files of about 60MB, which would not be needed in a production installation. The Windows software required can be Microsoft Windows NT, Windows 2000, Windows 2003, or Windows XP. Either workstation or server code can be usedalthough usually server code would be used. In addition, the normal assumption for Web servers applies in that the configuration would be for TCP/IP networking with a fixed IP address for each computer. UNIX (AIX) The minimum hardware required for the WebSphere and Domino computers for the UNIX (AIX) platform is the following: -
IBM RS/6000 or RS/6000 SP running IBM AIX, Version 4.3.3 with the 4330-10 recommended maintenance package; IBM AIX, Version 5.1 with the 5100-02 recommended maintenance package or 5100-03 and APAR IY36884; or IBM AIX, Version 5.2 -
IBM RS/6000 604e workstation at 375MHz or faster -
CD-ROM drive -
Minimum of 512MB available disk space for installation (including IBM Software Developer Kit) -
Minimum of 256MB memory, 512MB recommended -
Support for an appropriate network interface IBM AIX, Versions 5.1 and 5.2 Linux Domino is supported by IBM on several Linux distributions for Intel processors. The supported distributions for versions prior to Domino 6.02 are Red Hat Linux, Version 7.2 or SuSE Linux, Version 8.0. In addition to these, Domino versions 6.02 and later are supported on Red Hat Advanced Server, Version 2.1 ( uniprocessor only) and United Linux, Version 1.0. (It is possible to install and run Domino on other Linux distributions that provide the same level of Linux kernel and key library software as the supported distributions, but only the distributions mentioned here are supported by IBM. Other distributions could be used for experimentation, development, or testing work.) For Domino on Linux, IBM recommends at least 192MB of system memory and 1.5GB of disk space for acceptable performance. Based on our experience, to run any substantial application code on Domino requires more system memorythe more the better. We'd recommend at least 512MB of system memory. An installation of Domino code requires approximately 500MB of disk space on the Linux filesystem. Software Levels Red Hat Linux Operating Environment on Intel -
Red Hat Linux Advanced Server 2.1, SuSE 7.3 or SLES 7.0, based on kernel 2.4; Red Hat 8.0; UnitedLinux 1.0; Connectiva Linux Enterprise Edition, powered by UnitedLinux 1.0; SCO Linux Server 4.0, powered by UnitedLinux 1.0; or SuSE SLES 8.0, powered by UnitedLinux 1.0 -
Intel x86 processor at 500MHz or faster -
CD-ROM drive -
Legacy application support RPMs installed (provided on SuSE and Red Hat distribution CD-ROMs) -
Minimum of 300MB available disk space (including IBM Software Developer Kit) -
Minimum of 256MB memory, 512MB recommended -
Support for TCP/IP and an appropriate communications adapter Red Hat Linux on IBM zSeries Operating Environment Red Hat Advanced Server, Version 2.1 (using uniprocessors only) and UnitedLinux, Version 1.0SP2 on 390 -
128MB memory (192MB or more recommended) -
1GB hard disk space (1.5GB recommended) -
IBM zSeries server running Linux distribution SuSE SLES 7.0 or Red Hat Linux 7.2, based on kernel 2.4 -
G5, G6, or higher processor -
Legacy application support RPMs installed (provided on SuSE and Red Hat distribution CD-ROMs) -
CD-ROM drive -
Minimum of 512MB available disk space for installation -
Minimum of 256MB memory, 512MB recommended Domino Software requirement Lotus Domino Versions 6.0 to 6.5.1 AIX Software requirement IBM AIX, Versions 5.1 and 5.2 Linux -
Red Hat Advanced Server, Version 2.1 (using uniprocessors only) -
All "United Linux/Powered by United Linux 1.0 SP2 for Linux on Intel distributions." That includes SuSE Linux Enterprise Server (SLES) 8.0, Turbo Linux Enterprise Server, Connectiva Linux Enterprise Server. -
United Linux/Powered by United Linux 1.0 SP2 for S/390 Administration WAS Administration The WebSphere Administrative Server (admin server) for WAS V4 runs in a JVM on each node in a WebSphere Administrative Domain (see Appendix A for WAS V5 admin details). The admin server is responsible for providing run-time support for JNDI service, security, transaction logging, Location Service Daemon, and EJB workload management. The admin server also provides system management support initiated from administrative interfaces, including the Administrative Console, XMLConfig, and WSCP. Communications with the admin server take place using RMI/IIOP. The second major function of the admin server is to provide a single administration point for all of the objects within the WebSphere domain. The admin server allows for administration of information stored in the WebSphere repository. Types of System Administration Clients Administrative Console (admin console) The admin console is the graphical user interface for systems administration. It uses the bootstrap server and the name server in the admin server to perform JNDI (Java Naming and Directory Interface) operations. User operations on the admin console are relayed to the EJBs on the admin server and possibly indirectly to another admin server if the request affects another node. If security is enabled, the security runtime in the admin server uses the security server in the admin server to authenticate the user. If the admin server fails during admin console initialization, the console will fail to bootstrap to the admin server. This prevents the console from starting up altogether. Failover is achieved by restarting the admin console to bootstrap to a different admin server. The command-line options are as follows : After the admin console successfully starts up, workload management of the admin server takes effect. If an operation on the admin console fails, retrying the console allows the workload management runtime to reroute the request to a different admin server to complete the operation. Note that requests involving the applications on the node where the admin server failed, such as querying the state of the servers on that node, will fail until the admin server is restarted. But requests affecting other nodes will succeed. XMLConfig XMLConfig allows the system administrator to perform application management functions, such as application installation. If the admin server fails, XMLConfig operations will fail as well. If the operations of XMLConfig affect the node where the admin server is running, the admin server needs to be restarted before those operations can succeed. However, if the operations do not affect the applications on the same node as the failed admin server, XMLConfig may be rerun to bootstrap to a different admin server with the following parameter: -adminNodeName host. WebSphere Control Program WebSphere Control Program (WSCP) is used by the system administrator to perform administration operations, such as stopping and starting servers. If the operation affects the node where the admin server fails, the admin server needs to be restored before the operation can complete. If the operation does not affect the node of the failed admin server, WSCP can be rerun to bootstrap to a different admin server by setting the following properties either from the command line, or via the configuration property file: wscp.hostName=host. Domino 6 Administration Domino 6 allows you to apply and manage standard corporate policies by providing a new technology called policy-based system administration. This feature gives you a way to centrally define, organize, and manage user settings throughout your organization. All information required for policy-based system administration is stored in your Domino Directory, giving you a single place to control administration activity, from user setup to mail archiving. Policy-Based System Administration In broad functional terms, policy-based system administration is exactly what its name impliesa way for you as a Domino administrator to manage and apply corporate policies for your employees . These corporate policies define the way Domino enforces user settings, which ensures that your established corporate standards and practices control how your technology works (and not the other way around).This important Domino enhancement on policies was also touched on in Chapter 4 and is discussed in detail in Appendix B. In Domino 6, you enforce corporate policies through individual Policy documents and Settings documents in the Domino Directory. To create a policy, you use a Policy document to specify which Settings documents to include. A Policy document defines a set of corporate information you want to apply to your users. It does this by specifying which Settings documents to include in the policy. Each Settings document contains detailed information applicable to a specific area of Domino administration, for example archiving or security. This information defines user settings for that area. You can consider policy-based system administration as a way to create and apply rules within your user community. The Settings documents contain the rules; the Policy document organizes these rules. So when you create a Policy document, you have a single place to list these rules. You can then apply the rules to establish and enforce administrative standards by distributing them throughout your organization. To change an existing policy, all you need to do is edit the Policy document and/or one or more Settings documents. No more running around to each user's computer, making the same change over and overyou can now do this all centrally. You can use policy-based system administration to manage five major areas of Domino administration: archiving, desktop, setup, registration, and security. Again, please see Appendix B for details on Domino 6 Policy Administration. Management WAS Management Managing Administrative Agents If your system uses administrative or repository services, you can specify settings for the services. Steps for this task are to In order to understand this task, it is important to go through the details of cell and node . Cells Cells are arbitrary, logical groupings of one or more nodes in a WebSphere Application Server distributed network. A cell is a configuration concept, a way for administrators to logically associate nodes with one another. Administrators define the nodes that make up a cell, according to the specific criteria that make sense in their organizational environments. Administrative configuration data is stored in XML files. A cell retains master configuration files for each server in every node in the cell. The nodes and servers also have their own local configuration files. Changes to a local node or to a server configuration file are temporaryif the server belongs to the cell. While in effect, local changes override cell configurations. Changes to server and node configuration files at the cell level are permanent. Synchronization occurs at designated events, such as when a server starts. Nodes A node is a logical grouping of managed servers. A node usually corresponds to a physical computer system with a distinct IP host address. Node names usually are identical to the host name for the computer. A node agent manages all WebSphere Application Server servers on a node. The node agent represents the node in the management cell. Managing HTTP Sessions IBM WebSphere Application Server provides a service for managing HTTP sessions: Session Manager. The key activities for session management are summarized below. Before you begin these steps, make sure you are familiar with the programming model for accessing HTTP session support in the applications following the Servlet 2.3 API (see, for example, http://www.onjava.com/pub/a/onjava/2001/03/22/servlets23.html , for good background information on this API). Steps for this task include the following: - Plan your approach to session management, which could include session tracking and session recovery.
- Create or modify your own applications to use session support to maintain sessions on behalf of Web applications.
- Assemble your application.
- Deploy your application.
- Ensure the administrator appropriately configures session management in the administrative domain.
- Adjust configuration settings and perform other tuning activities for optimal use of sessions in your environment.
Managing Using Command-Line Tools There are several command-line tools that you can use to start, stop, and monitor WebSphere server processes and nodes. These tools only work on local servers and nodes and cannot operate on a remote server or node. To administer a remote server, you can use the wsadmin scripting program connected to the deployment manager for the cell in which the target server or node is configured. Managing Object Request Brokers An object request broker (ORB) is a middleware technology that manages communication and data exchange between objects. ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objectsfrom different vendors that communicate with each other via the ORB. The implementation details of the ORB are generally not important to developers building distributed systems. The developers are only concerned with the object interface details. This form of "information hiding" enhances system maintainability since the object communication details are hidden from the developers and isolated in the ORB. For WAS, default property values are set when the product is started and the Java Object Request Broker (ORB) service is initialized . These properties control the run-time behavior of the ORB and can also affect the behavior of product components that are tightly integrated with the ORB, such as security. It might be necessary to modify some ORB settings under certain conditions. In every request/response exchange, there is a client-side ORB and a server-side ORB. It is important that the ORB properties be set for both sides as necessary. After an ORB instance has been established in a process, changes to ORB properties do not affect the behavior of the running ORB instance. The process must be stopped and restarted in order for the modified properties to take effect. Domino Management Since Lotus Domino is a combination of groupware and e-business applications that together give you e-mail, shared freeform databases, and Web site support, Domino management must cover a wide range of capabilities. In addition to the "built-in" management tools for Lotus Notes and Domino, there are several very comprehensive third-party products available such as CA Unicenter Management for Lotus Notes/Domino, and BMC PATROL. | 