Chapter 2 The Implementation Specifications

The deployment architecture is a high-level technical description of your Java ES solution, and it does not have all of the information needed to install and configure the solution. This chapter describes the process of analyzing a deployment architecture and developing a set of implementation specifications. The purpose of the implementation specifications is to help you develop the additional information that is needed to install and configure your solution.

Notice that none of the implementation specifications are implemented in a single installation step. Instead, you implementation the specifications by systematically installing and configuring all of the components used in the solution. For example, you accomplish configuration of your LDAP directory by sequentially installing and configuring Directory Server, Access Manager, Messaging Server, Directory Preparation Tool, and Delegated Administrator.

This chapter describes the implementation specifications in the following sections:

• Analyzing a Deployment Architecture

• Developing Your Computer Hardware and Operating System Specification

• Developing a Network Connectivity Specification

• Developing Your User Management Specifications

Analyzing a Deployment Architecture

A typical deployment architecture is illustrated in Figure 2–1. This deployment architecture defines a Java ES solution that provides communications services. This particular example uses Access Manager to provide single sign-on to the communications services, and it uses both Portal Server and Communications Express to deliver the messaging and calendar services to end users.

Figure 2–1 Example Deployment Architecture

The example deployment architecture diagram contains much information about the solution, including the following:

• each computer used in the solution

• the number of CPUs and the amount of RAM required for each computer

• the component instances installed on each computer

• the solution includes multiple instances of the components

• the solution employs all three of the available redundancy strategies (load balancing, Directory Server multi-master replication, and Sun Cluster technology) to meet quality-of-service requirements

• the solution distributes the subcomponents of Messaging Server, also to meet quality-of-service requirements.

These characteristics of the example deployment architecture affect how the solution is installed and configured. You begin planning for installation by analyzing your deployment architecture in the same way, noting how many computer systems are used, how many component instances are installed on each computer system, which redundancy strategies are used, and so on. Chapter 3, The Installation Plan describes how these features of a deployment architecture influence your installation plan.

Developing Your Computer Hardware and Operating System Specification

In addition to the information that appears in the deployment architecture, you must specify the operating system that will be used on each computer used in your solution. You must also develop more information about the hardware. Your decisions will be based on your quality of service requirements, and represent your best guess at the hardware and operating system required to satisfy your qualify of service requirements.

For the example deployment architecture shown in Figure 2–1, the quality of service requirements were stated as:

To meet these quality of service requirements, the operating system and computer hardware specifications in Table 2–1 were developed.

Table 2–1 Computer Hardware/OS Specification for the Sample Deployment Architecture

Computer System	Hardware Model	Number of CPUs	RAM (in Gigabytes)	Number of Disks	Operating System
mscs01 mscs02	Sun Fire V440 Server	4	16	4	Solaris 9
commx01 commx02	Sun Fire V240 Server	2	4	2 4	Solaris 10
ds01 ds02	Sun Fire V240 Server	2	8	4	Solaris 10
am01 am02	Sun Fire V240 Server	2	8	4	Solaris 10
ms-mmp01 ms-mmp02	Sun Fire V240 Server	2	4	2	Solaris 10
ms-mtai01 ms-mtai02	Sun Fire V240 Server	2	4	2	Solaris 10
ms-mtao01 ms-mtao02	Sun Fire V240 Server	2	4	2	Solaris 10
ps01 ps02	Sun Fire V440 Server	4	16	4	Solaris 10
protect	Sun Fire V240	2	4	2	Solaris 10

You must develop similar information for the computer systems used in your solution.

---

Tip –

The Computer Hardware/OS specification is complete in itself. Once the specification is complete, the computer systems can be set up. Memory and disk drives can be installed, operating system can be installed, and the system made ready for installation of Java ES components.

---

Developing a Network Connectivity Specification

The deployment architecture contains much of the information needed to connect all of the hardware used in a solution. To help you develop the additional information you need to connect your network, you need to prepare a network connectivity specification like the example in Figure 2–2.

Figure 2–2 Example Network Connectivity Specification

The network connectivity specification for the example deployment architecture adds the following information that is not found in the deployment architecture diagram:

• IP addresses for every computer and hardware load balancer used in the solution

• load balancer port numbers that are used to connect the computers to the load balancers

• The IP addresses for the load balancers show the logical addresses that are used to access the services provided by load-balanced computers

You must develop similar information for your solution.

---

Tip –

When the network connectivity specification is complete, the network can be connected and made ready for the installation and configuration of your Java ES components.

---

Developing Your User Management Specifications

Installing and configuring Java ES components creates both your LDAP schema and your LDAP directory tree. This section describes how the directory schema and the directory tree structure are established by the values that you input when you install and configure a solution. Specifications for the schema and the directory tree structure must be developed before installation begins, and your installation plan must list input values that create the specified schema and directory tree structure.

The directory tree structure and the schema must support the services your solution provides. This section provides basic descriptions of the options that are available, and the services that each option supports. The main purpose of this section, however, is describing how to select input values for the installation and configuration tools in order to create a specified schema and a directory tree structure.

For more information on choosing a schema and designing a directory tree, see additional documentation, such as Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide and Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.

Specifying the LDAP Schema for a Solution

Java ES solutions that use Directory Server can use either of two versions of a standard LDAP schema, which are known as Schema 1 and Schema 2. The user management specification for a solution specifies whether the solution uses Schema 1 or Schema 2. The configuration values in the installation plan ensure that the installation process creates the correct schema.

Schema 2 supports the use of Access Manager, and Access Manager's single sign-on to feature. If a solution uses single sign-on, it must use Schema 2.

The installation process configures the directory for the specified schema as follows:

• To establish a Schema 1 directory, simply install Directory Server. Schema 1 is the default schema version.

• To establish a Schema 2 directory, install Directory Server and Access Manager. Installing Access Manager modifies the directory and converts it to a Schema 2 directory.

  ---

  Tip –

  If Directory Server and Access Manager are installed on one computer in one installer session, the directory is configured for Schema 2.

  If the solution is distributed, Directory Server is installed first, on one computer. Access Manager is installed next, on a separate computer. Installer input values for the Access Manager installation specify the existing directory, and the directory's schema is modified.

  ---

Depending on the solution, the following procedures for extending the schema might be necessary:

• If the solution uses Messaging Server and or Calendar Server, the installation process must apply some additional schema extensions with the Directory Preparation Tool. These extensions are applied before Messaging Server or Calendar Server is installed. They can be applied to either Schema 1 or Schema 2 directories. For more information on adding instructions for running the Directory Preparation Tool to an installation plan, see Messaging Server. The installation plan includes instructions for running Directory Preparation Tool.

• If the solution uses Schema 2, the installation process must apply some additional schema extensions with Delegated Administrator to support Access Manager authentication and authorization for the messaging and calendar services. For an example of the commands that apply these schema extensions, see Chapter 7, User Management for the Evaluation Solution, in Sun Java Enterprise System 2005Q1 Deployment Example Series: Evaluation Scenario. The installation plan includes instructions for these schema extensions. These extensions are applied after Delegated Administrator is installed and configured, but before Delegated Administrator adds any user data. For more information on adding instructions for extending the schema to an installation plan, see Adding Procedures for Delegated Administrator to Your Installation Plan.

The LDAP schema specification identifies the schema used in the solution and any schema extensions required by the solution. The installation plan includes procedures that establish the correct schema and perform any specified schema extensions.

Specifying the Directory Tree Structure for a Solution

The LDAP directory for a Java ES solution can be simple or complex, depending on the solution's needs for organizing user data. LDAP directories are, by their nature, flexible in structure. Java ES does not impose structure on the directory, but the installation and configuration process does implement the specified structure. The structure must be specified before the installation and configuration process begins, and the installation plan must list the input values that create the specified directory structure.

The installation and configuration process establishes the directory structure as follows:

1. Running the installer to install Directory Server requires an input value for the directory's base suffix (also referred to as root suffix or root DN). The Java ES installer uses the input value to establish the directory's base suffix. The installation plan includes the includes the base suffix name.

   ---

   Tip –

   Solutions with simple directory trees, that do not use Messaging Server or Calendar Server, can store user and group data directly under the base suffix.

   ---

2. Running the Messaging Server configuration wizard to create a Messaging Server instance requires an input value for an LDAP organization DN. The configuration wizard branches the directory tree and creates an LDAP organization using the DN input in the wizard. This organization represents the email domain managed by the Messaging Server instance. The wizard also configures the Messaging Server instance to use the email domain organization for user and group data. The installation plan includes the DN for the email domain organization. For an example of a directory tree structure created by this process, see Figure 2–3. In the example, the base suffix created by the installer is o=examplecorp. The email domain organization created by the Messaging Server configuration wizard is o=examplecorp.com,o=examplecorp.

3. The configuration wizards for Calendar Server, Communications Express, Instant Messaging, and Delegated Administrator require an input value for an LDAP DN. (The names that appear in the wizards vary.) If a solution uses single sign-on, the same value is input in all of the configuration wizards. The input value is the email domain organization created by the Messaging Server wizard. The result of this configuration is that all of the components store and look up user data in the same LDAP organization. All of the information about a user can be stored in a single directory entry, and the Access Manager single sign-on feature can be used.

An example of a directory tree structure created by this process is illustrated in Figure 2–3. In this example, the Java ES installer established the base suffix o=examplecorp and the Messaging Server configuration wizard added the organization o=examplecorp.com,o=examplecorp. This organization represents the email domain named examplecorp.com. The user data for the mail domain is stored in ou=people,o=examplecorp.com,o=examplecorp. The other Java ES components in the solution are also configured to look up user data in ou=people,o=examplecorp.com,o=examplecorp.

Figure 2–3 Example LDAP Directory Tree

To create the directory tree shown in Figure 2–3, the names for the base suffix and the organization representing the email domain are chosen and added to the user management specification. When the installation plan is prepared, it includes instructions to input the specified LDAP names in the appropriate installer and configuration wizard fields. For information on adding the LDAP names to an installation plan, see Choosing Configuration Values for Directory Server, Choosing Configuration Values for Access Manager,Choosing Configuration Values for Messaging Server,Choosing Configuration Values for Calendar Server,Choosing Configuration Values for Communications Express,Choosing Configuration Values for Instant Messaging, and Choosing Configuration Values for Delegated Administrator.

The example directory tree includes only one mail domain. Many solutions require more complex trees to organize user data. The same basic installation and configuration procedure can establish more complex directory structures. For example, a directory can be configured to support multiple email domains if the solution requires it.

To establish multiple email domains, configure multiple instances of Messaging Server. Each instance manages one email domain.

It is possible to use other LDAP directories in a Java ES solution, if the solution uses Access Manager to interact with the directory. The directory server must be an LDAP version 3 (LDAP v3) compliant directory server. For more information about the directory tree structure required for such a solution, see Sun Java System Access Manager 7 2005Q4 Technical Overview