Creating and Configuring WebLogic Server Domains

Overview of WebLogic Server Domains

The following sections describe WebLogic Server domains and their contents:

• What Is a Domain?

• Domain Restrictions

• Domain Administration Tasks

What Is a Domain?

A domain is the basic administration unit for WebLogic Server instances. A domain consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server. You can define multiple domains based on different system administrators' responsibilities, application boundaries, or geographical locations of servers. Conversely, you can use a single domain to centralize all WebLogic Server administration activities.

If you create multiple domains, keep in mind that each domain is represented in a separate configuration file (config.xml), and you cannot perform configuration or deployment tasks in multiple domains at the same time. When you use the Administration Console to perform a configuration task, the changes you make apply to the currently selected domain. To make changes in a different domain, you must select that domain. For this reason, the servers instances, applications, and resources in one domain should be treated as being independent of servers, applications, and resources in a different domain.

Contents of a Domain

A domain can include multiple WebLogic Server clusters and non-clustered WebLogic Server instances. Strictly speaking, a domain could consist of only one WebLogic Server instance—however, in that case that sole server instance would be an Administration Server, because each domain must have exactly one Administration Server. Although the scope and purpose of a domain can vary significantly, most WebLogic Server domains contain the components described in this section.

The following figure shows a production environment that contains an Administration Server, three standalone Managed Servers, and a cluster of three Managed Servers.

Administration Server

Each WebLogic Server domain must have one server instance that acts as the Administration Server. You use the Administration Server, programmatically or via the Administration Console, to configure all other server instances and resources in the domain.

Role of the Administration Server

Before you start the Managed Servers in a domain, you start the Administration Server. When you start a standalone or clustered Managed Server, it contacts the Administration Server for its configuration information. In this way, the Administration Server operates as the central control entity for the configuration of the entire domain.

You can invoke the services of the Administration Server in the following ways:

• Domain Configuration Wizard—The Domain Configuration Wizard is the recommended tool for creating a new domain or cluster.

• WebLogic Server Administration Console—The Administration Console is a graphical user interface (GUI) to the Administration Server.

• WebLogic Server Application Programming Interface (API)—You can write a program to modify configuration attributes using the API provided with WebLogic Server.

• WebLogic Server command-line utility—This utility allows you to create scripts to automate domain management.

Whichever method is used, the Administration Server for a domain must be running to modify the domain configuration.

When the Administration Server starts, it loads the config.xml for the domain. It looks for config.xml in the current directory. Unless you specify another directory when you create a domain, config.xml is stored in:

BEA_HOME/user_projects/mydomain

where mydomain is a domain-specific directory, with the same name as the domain.

Each time the Administration Server starts successfully, a backup configuration file named config.xml.booted is created in the domain directory. In the unlikely event that the config.xml file should be corrupted during the lifetime of the server instance, it is possible to revert to this previous configuration.

For more information about the Administration Server and its role in the WebLogic Server JMX management system, see "System Administration Tools" in the Administration Guide.

What Happens if the Administration Server Fails?

The failure of an Administration Server for a domain does not affect the operation of Managed Servers in the domain. If an Administration Server for a domain becomes unavailable while the server instances it manages—clustered or otherwise—are up and running, those Managed Servers continue to run. If the domain contains clustered server instances, the load balancing and failover capabilities supported by the domain configuration remain available, even if the Administration Server fails.

If an Administration Server fails because of a hardware or software failure on its host machine, other server instances on the same machine may be similarly affected. However, the failure of an Administration Server itself does not interrupt the operation of Managed Servers in the domain.

For instructions on re-starting an Administration Server, see Restarting an Administration Server When Managed Servers are Running .

Managed Servers and Clustered Managed Servers

In a domain, server instances other than the Administration Server are referred to as Managed Servers. Managed Servers host the components and associated resources that constitute your applications—for example, JSPs and EJBs. When a Managed Server starts up, it connects to the domain's Administration Server to obtain configuration and deployment settings.

Note: Managed Servers in a domain can start up independently of the Administration Server if the Administration Server is unavailable. See Recovering Failed Servers for more information.

Two or more Managed Servers can be configured as a WebLogic Server cluster to increase application scalability and availability. In a WebLogic Server cluster, most resources and services are deployed to each Managed Server (as opposed to a single Managed Server,) enabling failover and load balancing. To learn which component types and services can be clustered—deployed to all server instances in a cluster—see "What Types of Objects Can Be Clustered?" in Using WebLogic Server Clusters.

You can create a non-clustered Managed Server and add it to a cluster by configuring pertinent configuration parameters for the server instance and the cluster. Conversely, you can remove a Managed Server from a cluster by re-configuring the parameters appropriately. The key difference between clustered and non-clustered Managed Servers is support for failover and load balancing—these features are available only in a cluster of Managed Servers.

Your requirements for scalability and reliability drive the decision on whether or not to cluster Managed Servers. For example, if your application is not subject to variable loads, and potential interruptions in application service are acceptable, clustering may be unnecessary.

For more information about the benefits and capabilities of a WebLogic Server cluster, see "Introduction to WebLogic Server Clustering" in Using WebLogic Server Clusters A single domain can contain multiple WebLogic Server clusters, as well as multiple Managed Servers that are not configured as clusters.

Resources and Services

In addition to the Administration Server and Managed Servers, a domain also contains the resources and services required by Managed Servers and hosted applications deployed in the domain.

Examples of domain-level resources include:

• Machine definition identify a particular, physical piece of hardware. A Machine definition is used to associate a computer with the Managed Server(s) it hosts. This information is used by Node Manager in restarting a failed Managed Server, and by a clustered Managed Server in selecting the best location for storing replicated session data. For more information about Node Manager, see Managing Server Availability with Node Manager .

• Network channels, an optional resource that can be used to define default ports, protocols, and protocol settings. After creating a network channel, you can assign it to any number of Managed Servers and clusters in the domain. SeeConfiguring Network Resources for more information.

Managed Servers in the domain host their own resources and services. You can deploy resources and services to selected Managed Servers or to a cluster. Examples of deployable resources include:

• application components, such as EJBs

• connectors, startup classes,

• JDBC connection pools,

• JMS servers

Common Domain Types

There are two basic types of domains:

• Domain with Managed Servers: A simple production environment can consist of a domain with several Managed Servers that host applications, and an Administration Server to perform management operations. In this configuration, applications and resources are deployed to individual Managed Servers; similarly, clients that access the application connect to an individual Managed Server.

  Production environments that require increased application performance, throughput, or availability may configure two or more of Managed Servers as a cluster. Clustering allows multiple Managed Servers to operate as a single unit to host applications and resources. For more information about the difference between a standalone and clustered Managed Servers, see Managed Servers and Clustered Managed Servers.

• Standalone Server Domain: For development or test environments, you may want to deploy a single application and server independently from servers in a production domain. In this case, you can deploy a simple domain consisting of a single server instance that acts as an Administration Server that, and also hosts the applications you are developing. The examples domain that you can install with WebLogic Server is an example of a standalone server domain.

Note: In production environments, BEA recommends that you deploy applications only on Managed Servers in the domain; the Administration Server should be reserved for management tasks.

Domain Restrictions

Many WebLogic Server installations consist of a single domain that includes all the Managed Servers required to host applications. If you create more than one domain, note the following restrictions:

• Each domain requires its own Administration Server for performing management activities. When you are using the Administration Console to perform management and monitoring tasks, you can switch back and forth between domains, but in doing so, you are connecting to different Administration Servers.

• All Managed Servers in a cluster must reside in the same domain; you cannot "split" a cluster over multiple domains.

• You cannot share a configured resource or subsystem between domains. For example, if you create a JDBC connection pool in one domain, you cannot use it with a Managed Server or cluster in another domain. (Instead, you must create a similar connection pool in the second domain.)

Domain Directory and config.xml

The configuration of a domain is stored in the config.xml file for the domain. config.xml specifies the name of the domain and the configuration parameter settings for each server instance, cluster, resource, and service in the domain. The config.xml for a domain is stored in the domain directory, which you specify when you create the domain.

The domain directory also contains default script files that you can use to start the Administration Server and Managed Servers in the domain. For more information about these scripts and other methods of starting a server instance, see "Starting and Stopping WebLogic Server" in the Administration Guide.

Domain Directories Structure

In releases prior to WebLogic Server 7.0, domain directories were created within the directory structure of the Weblogic Server installation. With WebLogic Server 7.0 and later, you can set up domain directories outside the product installation directory tree, in any location on the system that can access the Weblogic Server installation and the JDK.

This new directory structure is more flexible. It allows you to store your application code in a directory structure separate from WebLogic Server executables and related files—this practice is recommended.

The domain directory structure should have:

• A root directory with the same name as the domain, such as mydomain or petstore. This directory should contain the following:

  • The configuration file (usually config.xml) for the domain.

  • Any scripts you use to start server instances and establish your environment.

• A subdirectory for storing applications for the domain, typically named applications.

Note: If you plan to use the WebLogic Server's auto-deployment feature—available when a domain is running in development mode—the subdirectory for applications must be named applications. For information about auto-deployment, see "Auto-Deployment" in Developing WebLogic Server Applications.

You can create other directories within the domain directory structure, as desired. When you start a server instance in a domain for the first time, Weblogic Server creates the following subdirectories in the domain directory:

• data for storing security information

• logs for storing domain-level logs

• server_name for each server running in the domain, for storing server-level logs

• temp for storing temporary files

For example:

You can use the Configuration Wizard to create and configure domains. At the end of a custom installation, you are prompted to run the Configuration Wizard. You can also start the Configuration Wizard from the Start menu or by using a script. For more information, see Creating New Domains Using the Configuration Wizard.

When you use the Configuration Wizard to create a domain, it creates the user_projects directory in the BEA Home directory as a container for your domains. It also creates a root directory for the new domain and any other directories specified in the domain template that you select to create the domain.

Domain Administration Tasks

Refer to the following sections to learn about common domain administration tasks:

• Creating New Domains Using the Configuration Wizard

• Configuring Network Resources

• Recovering Failed Servers

• Managing Server Availability with Node Manager