Sun Java Enterprise System 2005Q4 Installation Planning Guide

Installation Planning Issues

The goal of the installation and configuration process is the distributed system described in the deployment architecture. The distributed system is composed of component instances that run on multiple computers and interoperate with each other. To achieve a functioning distributed system, you must install the component instances on multiple computers and perform the basic configuration that establishes interoperation among the component instances.

The procedures for installation and configuration are determined by the behavior of the Java ES installer and the requirements of the individual components. To ensure that you achieve a functioning distributed system, you must develop an installation plan that uses the installer appropriately and considers the requirements of the components used in the solution. Your plan must describe the correct order for installing the component instances and performing basic configuration. The plan must also specify the configuration values that configure the component instances to interoperate.

This section describes the major issues you must consider when developing an installation plan.

Distributed Installations

The quality-of-service requirements for production Java ES solutions lead to architectures that place component instances on more than one computer. For example, to achieve reliable messaging services the architecture might require two instances of Messaging Server on two different computers and use load balancing to establish a failover relationship between the two instances.

The Java ES installer, however, operates on only one computer at a time. Therefore, when you install a distributed solution, you must run the installer on every computer used in the solution.

In many cases, you must install a component or components on a computer and then run configuration wizards to perform the basic configuration. You typically complete installation and configuration on one computer before you proceed to install and configure another set of components on another computer. To install and configure distributed component instances, you might perform a sequence of tasks similar to the one illustrated in Figure 3–1.

Figure 3–1 Distributed Installation Procedure Example

On computer 01, install Messaging Server and Calendar Server,
configure Messaging Server, configure Calendar Server. On computer 02, repeat procedure.

Configuring for Interoperation

The goal of the installation process is a system of interoperating component instances. When you install components and perform basic configuration, you supply configuration values that result in component instance interoperation.

The configuration values that result in interoperation include such values as the URLs or port numbers that one component instance uses to communicate with another component instance and the administrator account IDs and passwords that one component instance uses to authorize access to another component instance. For example, if your solution uses Access Manager, you must first install and configure an LDAP repository, such as a Directory Server instance. Then, when you install and configure an Access Manager instance, you must provide configuration values that tell the instance where to find the LDAP directory you prepared.

The Java ES installer does not know what components are installed on the other computers used in the solution. For example, when you install Access Manager, the installer does not know where the appropriate LDAP directory is located. To ensure the success of your installation and configuration process, you must plan in advance which components are installed on each computer. As you add a components to the solution, you configure them to interoperate with the components already installed on the other computers.

You might perform a sequence of installation and configuration tasks similar to the one illustrated in Figure 3–2.

Figure 3–2 Configuring Components to Interoperate

Computer 01: Directory Server. Computer 02: install and configure
Access Manager to interoperate with Directory Server instance on computer 01.

Whatever the architecture of your solution, you must develop an installation plan that includes all the configuration values needed to configure the components and achieve an interoperating, distributed solution.

Component Dependencies

Some Java ES components cannot be installed and configured unless other components are installed and configured first. Dependencies occur for several reasons:

Notice that some of these dependencies are solution-wide and some are local. You consider system-wide dependencies and local dependencies differently when you develop your installation plan. The difference is described in the following example:

The dependency of Access Manager on Directory Server is a system-wide dependency. When you install Access Manager, you supply a URL for a directory service provided by one or more instances of Directory Server. Once Directory Server is installed and configured, the directory service is available to all components in the solution. This type of dependency determines the solution-wide sequence for installing and configuring component instances: Directory Server is installed and configured before Access Manager. In your installation plan, solution-wide dependencies determine the overall sequence of installation and configuration steps.

The dependency of Access Manager on a web container is a local dependency. To satisfy this dependency, a web container must be installed on the computer that runs Access Manager. This web container, however, does not provide services for the entire solution. In a distributed solution, web containers are typically installed on multiple computers. Each web container supports a different component locally. Therefore, in a distributed solution there is no single location for web container installation, and there is no single point in the installation sequence for installing the web container.

To develop an installation plan for a solution, you analyze the deployment architecture that describes a solution and identify dependencies among the components. Your plan must install and configure components in a sequence that satisfies all of the dependencies. In general, you develop the overall installation sequence from the solution-wide dependencies. Then you consider the local dependencies that might exist on each computer.

The component dependencies are listed in Table 3–1. For more information about working with these dependencies, see the descriptions of the individual components in Developing an Installation Plan.

Table 3–1 Java ES Component Dependencies

Product Component

Dependencies 

Nature of Dependency 

Must be Local? 

Access Manager

Directory Server 

To store configuration data; to store and enable lookup of user data 

No 

 

J2EE web container, one of: 

-Application Server 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

Access Manager must be deployed to one of these web containers 

Yes 

Access Manager SDK

Access Manager 

To provide Access Manager services 

No 

 

J2EE web container, one of: 

-Application Server 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

Access Manager SDK must be deployed to one of these web containers 

Yes 

Administration Server

Directory Server 

To provide a configuration directory 

No 

Application Server

Message Queue

To provide reliable asynchronous messaging 

Yes 

 

Web Server (optional)

To provide load balancing between Application Server instances 

Yes 

 

High Availability Session Store (optional)

To store session state, which supports failover between Application Server instances 

Yes 

Calendar Server

Directory Server

To store user data used for authentication and authorization 

No 

 

Directory Preparation Tool

Prepares the LDAP directory for use with Calendar Server 

No 

 

Access Manager (optional)

Required if your solution uses single sign-on 

No 

 

Messaging Server (optional)

To provide email notifications 

No 

 

Delegated Administrator (optional)

To mange LDAP schema; to provision users of calendar services 

No 

Communications Express

J2EE web container, one of:

-Application Server 

-Web Server 

Communications Express must be deployed to a web container 

Yes 

 

Directory Server

To store user data, such as address books 

No 

 

Directory Preparation Tool

To prepare the LDAP directory for Communications Express 

No 

 

Either Access Manager or Access Manager SDK

To provide authentication and authorization services and single sign-on; a local Access Manager SDK provides access to remote Access Manager 

Yes 

 

Messaging Server

To provide underlying messaging service 

No 

 

Calendar Server

To provide underlying calendar service 

No 

Delegated Administrator

J2EE web container, one of: 

-Application Server 

-Web Server 

Delegated Administrator must be deployed to one of these web containers 

Yes 

 

Directory Server 

To store the LDAP data that Delegated Administrator works with 

No 

 

Directory Preparation Tool 

To prepare the LDAP directory for Delegated Administrator 

No 

 

Either Access Manager or Access Manager SDK 

To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager 

Yes 

Directory Preparation Tool

Directory Server 

Directory Preparation Tool prepares the directory for use with Java ES communications components 

Yes 

Directory Proxy Server

Administration Server 

To configure Directory Proxy Server 

No 

 

Directory Server 

To provide underlying LDAP directory services 

No 

Directory Server

Administration Server 

To configure Directory Server 

No 

High Availability Session Store 

None 

   

Instant Messaging

Directory Server 

To store user, conference room, and news channel data 

No 

 

Access Manager or Access Manager SDK (optional) 

To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager 

Yes 

 

J2EE Web Container, one of: 

-Application Server 

-Web Server (required for delivery of Instant Messenger client resources) 

To support distribution and downloading of Instant Messenger client resources. 

Yes 

 

Calendar Server (optional, if calendar pop-ups feature is used) 

To support Calendar Server pop-ups 

No 

 

Messaging Server (optional, if offline delivery of instant messages is used) 

To support offline delivery of instant messages as email messages 

No 

Message Queue 

None 

   

Messaging Server

Directory Server 

To store configuration data; To store and lookup user data for authentication and authorization 

No 

 

Administration Server 

To store configuration data in Directory Server configuration directory 

Yes 

 

Directory Preparation Tool 

To prepare the LDAP directory for Messaging Server 

No 

 

Access Manager (if your solution uses single sign-on) 

To provide single sign-on authentication and authorization service 

No 

 

Delegated Administrator (optional) 

To manage user and group data; to manage the directory schema 

No 

Portal Server

J2EE web container, one of:

-Application Server 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

Portal Server must be deployed to one of these web containers 

Yes 

 

Directory Server 

To store user data used for authentication and authorization 

No 

 

Access Manager or Access Manager SDK 

To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager 

Yes 

 

Communications Express 

To provide messaging and calendar channels for the portal desktop 

No 

Portal Server Secure Remote Access

Portal Server 

To provide the underlying portal service. 

Yes 

 

Either Access Manager or Access Manager SDK 

To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager 

Yes 

Service Registry 

Application Server 

 

Yes 

Sun Cluster Software 

None 

   

Sun Cluster Agents

Sun Cluster 

To recognize components installed on Sun Cluster nodes 

Yes 

Web Proxy Server

Web Server 

To provide remote access to web applications 

Yes 

Web Server 

None 

   

Redundancy Strategies

Most solutions intended for production use include some type of redundancy. Redundancy strategies use multiple instances of a component to provide a single service. Redundancy is used to satisfy quality of service requirements. For example, redundancy is used to increase throughput in order to satisfy performance requirements, or to avoid a single point of failure to in order satisfy reliability requirements.

Three strategies are available for using redundant instances of Java ES components: load balancing, clustering with Sun Cluster software, and Directory Server multi-master replication. The recommended installation and configuration procedure for each of these strategies is outlined briefly in the following paragraphs:

When your deployment architecture uses any of these redundancy strategies, you must develop a plan for installing multiple instances of a component and configuring the instances to operate as a single service.

Distributed Subcomponents

Some Instant Messaging components have subcomponents that can be separately installed and configured. For example, Messaging Server has four subcomponents, Message Transfer Agent, Message Multiplexor (MMP), Messenger Express Multiplexor (MEM), and Message Store. A deployment architecture might place these subcomponents on separate computer systems to satisfy quality of service reasons. For example, the sample architecture in Figure 2–1 places instances of MEM on computer systems CX1 and CX2, outbound Message Transfer Agent on computer systems MTA1 and MTA2, the inbound Message Transfer Agent on computer systems MTA3 and MTA4, the MMP on computer systems MMP1 and MMP2, and the message store on computer systems STR1 and STR2.

Table 3–2 lists the Java ES components that have separately installable subcomponents. Analyze the deployment architecture for your solution and determine whether it uses distributed subcomponents. If your solution uses distributed subcomponents, you need to develop a plan to install the subcomponents on the correct computer systems, in the correct order, and configure the subcomponents to interoperate. For more information on configuring distributed subcomponents, see the descriptions of individual components in Developing an Installation Plan.

Table 3–2 Components with subcomponents

Component 

Subcomponent 

Instant Messaging

Instant Messaging Multiplexor 

Instant Messaging Resources 

Instant Messaging Server 

Messaging Server

Message Transfer Agent (MTA) 

Message Store 

Messaging Multiplexor (MMP) 

Messenger Express Multiplexor (MEM) 

Subcomponents are separately installable. If your deployment architecture calls for distributed subcomponents, run the installer on each computer and select the subcomponents specified in the architecture. The input values required by the installer or configuration wizard are a subset of values for the complete component. For the components that are not configured by the installer, start the configuration wizard, select the subcomponents to be configured on the computer and supply the input values required by the configuration wizard.

LDAP Schema and LDAP Directory Tree Structure

Most Java ES solutions include Directory Server. Installing and configuring a solution requires input values that establish both the directory schema and the directory tree structure. Your installation plan must list input values that result in the correct LDAP schema and directory tree structure.

The LDAP schema and directory tree structure are specified before you begin the installation plan. For examples of specifications, see Developing Your User Management Specifications.

The LDAP schema is established by the following installation and configuration processes:

  1. Installing Directory Server automatically establishes a directory with Schema 1. No input is required to select the schema.

  2. Installing Access Manager automatically modifies the directory, and converts it to Schema 2. No input is required to select the schema.

  3. Running the Directory Preparation Tool extends the schema for use with Messaging Server, Calendar Server, and Communications Express. The Directory Preparation Tool extends both Schema 1 and Schema 2 directories. Input values for the Directory Preparation Tool are listed in your installation plan.

  4. Running Delegated Administrator extends the schema with object classes and attributes used to authorize and authenticate users for specific services. The input values depend on the service provided by your solution. The input values are listed in your installation plan. For more information on the input values, see Adding Procedures for Delegated Administrator to Your Installation Plan.

The installation and configuration process also establishes the basic directory tree structure:

  1. Installing Directory Server creates the base suffix, or directory tree root. The base suffix is a required input value when the Java ES installer installs Directory Server. Your installation plan lists the base suffix as one of the input values for the installation process.

  2. Installing and configuring Messaging Server branches the directory tree and creates an LDAP organization. This organization represents the email domain managed by the Messaging Server instance. The name of the organization is a required input for the Messaging Server configuration wizard. Your installation plan lists the organization DN as one of the input values for the Messaging Server configuration process.

  3. Installing and configuring Calendar Server, Communications Express, Delegated Administrator, and Instant Messaging specifies where in the directory these components look up user data. An LDAP DN is required input for each component's configuration wizard, and your installation plan lists the DN as an input value for each configuration wizard. If the solution uses Access Manager single sign-on, all of these components must be configured to use the same location for user data, which is the organization that the Messaging Server configuration wizard created. The same LDAP DN is input in all of these configuration wizards. Your installation plan lists the organization DN as one of the input values for all of the configuration wizards.

The names for the LDAP base suffix and email domain organization are taken from the user management specification and added to the installation plan. For more information about the user management specification, see Developing Your User Management Specifications. For more information about adding the LDAP base suffix to your installation plan, see Table 3–5. For more information about adding the email domain organization to your installation plan, see Table 3–9, Table 3–10, Table 3–11, Table 3–13, and Table 3–14.

Java ES Installer Behavior

This section describes some behaviors of the Java ES installer that affect installation planning.

The Installer is Local

The Java ES installer installs component software on one computer at a time. For most solutions, this means the installer runs more than once. The installation plan must indicate how many times to run the installer. This section describe how to analyze a deployment architecture and determine how many times the installer is run to install and configure a solution.

A few solutions are installed on one computer only, and the installation plans for these solutions provide procedures for running the installer runs only once. The solutions that require running the installer only once are the following:

Most solutions are distributed across several computers. Installation plans for these solutions must describe running the installer multiple times to install and configure the complete solution. To analyze these solutions, use the following guidelines:

The purpose of this section is to introduce the idea that installation plans must sometimes describe running the installer and the configuration wizards on one computer, or running the installer multiple times on one computer. For more information on the actual installation procedures for different component combinations, see Developing an Installation Plan.

Installer Operating Modes

The installer runs in two different modes, known as configure now and configure later. The modes differ in the following ways:

The selected configuration option applies to an entire installation session. If you need to select different configuration options for some components, you might need to run additional installation sessions.

Installer Compatibility Checking

The installer performs some dependency and compatibility checking. Can only check what is installed locally. For example, if your solution is using a remote Directory Server instance, the installer cannot check whether the remote Directory Server is compatible with the Access Manager you are installing. If you are installing and configuring an all-new solution. It might be an issue if you are adding a new component to an established solution, or building a Sun Java System around existing components. For example, if you are already using Directory Server, and you are building a solution using Access Manager, Messaging Server, Calendar Server, and Communications Express around the existing Directory Server, compatibility among the components becomes an issue.

Other Installation Issues

This section lists a number of specific issues that occur in some solutions with references to detailed information.

Table 3–3 Installation Issues to Consider

Solution Requires 

Guidelines or Instructions 

Using Solaris 10 zones 

If you will be installing into Solaris 10 zones, refer to Solaris 10 Zones in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Using Directory Server encryption 

Configuring LDAPS (SSL over LDAP) on the Directory Server instance 

Note: If Directory Server encryption is a requirement, Administration Server must be installed when Directory Server is installed. 

Using a third-party web container with Access Manager

Third-party web containers (BEA WebLogic Server or IBM WebSphere Application Server) can be used with Portal Server and Access Manager. These containers must be installed and running before installing any Java ES components that depend on them.

To use a third-party web container for Access Manager SDK, you must configure Access Manager SDK manually after installation. See Access Manager SDK With Container Configuration Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX

Note: Portal Server can only use third-party web containers on Solaris OS. 

Note: Access Manager and Portal Server should use the same type of web container. 

Using Apache Web Server for load balancing plugin

The Apache Web Server can be used with the Application Server load balancing plugin. In this case, the Apache Web Server must be installed and running before installing any Java ES components that depend on it. For additional information, refer to Installation Prerequisites in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Using Schema 1 LDAP

An installation example based on LDAP Schema 1 is described in Calendar-Messaging Schema 1 Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. For a Schema 1 deployment, you cannot use Access Manager.

Configuring single user entry and single sign-on

Procedures for setting up single sign-on, can be found in the Chapter 8, Configuring and Using Single Sign-On, in Sun Java Enterprise System 2005Q1 Deployment Example Series: Evaluation Scenario. Access Manager is required for single sign-on.

Configuring High availability using HADB 

An example of setting up HADB for high availability is contained in Web and Application Services Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Application Serverload balancing 

An example that includes using the Application Server load balancing plugin is contained inWeb and Application Services Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Non-root ownership 

If non-root ownership will be required for Application Server or Web Server, refer to one of the following examples:

Access Manager Configured to Run as a Non-root User Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX, or

Portal Server on a Non-root Owned Web Server or Application Server Instance Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.