Understanding Domain Configuration
|
 |
 |
|
|
 |
 |
Understanding WebLogic Server Domains
The following sections introduce WebLogic Server domains and their contents:
What Is a Domain?
A WebLogic Server administration domain is a logically related group of WebLogic Server resources. Domains include a special WebLogic Server instance called the Administration Server, which is the central point from which you configure and manage all resources in the domain. Usually, you configure a domain to include additional WebLogic Server instances called Managed Servers. You deploy Web applications, EJBs, and other resources onto the Managed Servers and use the Administration Server for configuration and management purposes only.
Multiple Managed Servers can be grouped into clusters, which enable you to balance loads and provide failover protection for critical applications, while using a single Administration Server simplifies the management of the Managed Server instances.
System administration in WebLogic Server is based on the J2EE Management model, in which each instance of a Web application server resource type is represented by a J2EE Managed Object (JMO). In WebLogic Server, each JMO is a wrapper for a corresponding MBean. You accomplish many WebLogic Server administration tasks by accessing MBeans, either directly using JMX, or through a JMX client like the WebLogic Administration Console or WebLogic Scripting Tool (WLST). For more information, see Monitoring and Managing with the J2EE Management APIs and WebLogic Server MBean Reference.
Organizing Domains
How you organize your WebLogic Server installations into domains depends on your business needs. You can define multiple domains based on different system administrators' responsibilities, application boundaries, or geographical locations of the machines on which servers run. Conversely, you might decide to use a single domain to centralize all WebLogic Server administration activities.
Depending on your particular business needs and system administration practices, you might decide to organize your domains based on criteria such as:
- Logical divisions of applications. For example, you might have one domain devoted to end-user functions such as shopping carts and another domain devoted to back-end accounting applications.
- Physical location. You might establish separate domains for different locations or branches of your business.
- Size. You might find that domains organized in small units that can be managed more efficiently, perhaps by different system administrators. Contrarily, you might find that maintaining a single domain or a small number of domains makes it easier to maintain a consistent configuration.
A domain can consist of an Administration Server and one or more Managed Servers, or of a single standalone server that both acts as Administration Server and runs deployed applications.
- Domain with Separate 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 should 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 standalone and clustered Managed Servers, see Managed Servers and Managed Server Clusters.
- 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
wl_serverdomain 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.
Contents of a Domain
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 through the Administration Console or WLST, 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.
When the Administration Server starts, it loads the config.xml file for the domain. Unless you specify another directory when you create a domain, config.xml is stored in:
BEA_HOME/user_projects/domains/mydomain/config
where mydomain is a domain-specific directory, with the same name as the domain. The config.xml file refers to other configuration files, which are located in subdirectories of the domain's config directory.
Each time the Administration Server starts successfully, a backup configuration file named config-booted.jar is created in the domain directory. In the unlikely event that the configuration files should be corrupted during the lifetime of the server instance, it is possible to revert to this previous configuration.
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 stops running while the Managed Servers in the domain continue to run, each Managed Server periodically attempts to reconnect to the Administration Server.
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. Also, you can start a Managed Server even if the Administration Server is not running. In this case, the Managed Server uses a local copy of its configuration files for its starting configuration and then periodically attempts to connect with the Administration Server. When it does connect, it synchronizes its configuration state with that of the Administration Server.
For instructions on re-starting an Administration Server, see Avoiding and Recovering From Server Failure in Managing Server Startup and Shutdown.
Managed Servers and Managed Server Clusters
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 Avoiding and Recovering From Server Failure in Managing Server Startup and Shutdown 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 identically to each Managed Server (as opposed to a single Managed Server), enabling failover and load balancing. A single domain can contain multiple WebLogic Server clusters, as well as multiple Managed Servers that are not configured as clusters. 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. For more information about the benefits and capabilities of a WebLogic Server cluster, see Understanding WebLogic Server Clustering in Using WebLogic Server 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.
The domain configuration includes information about the networked computer environment in which the domain runs, such as:
- Machine definitions identify a particular, physical piece of hardware. A machine definition is used to associate a computer with the Managed Servers 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 Using Node Manager to Control Servers in Managing Server Startup and Shutdown.
- 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. For more information, see Configuring Network Resources in Configuring WebLogic Server Environments.
The domain configuration also includes information about resources and services associated with applications hosted on the domain. Examples of these resources and services include:
- application components, such as EJBs
- security providers
- resource adapters
- JDBC data sources
- JMS servers or other messaging resources
- store-and-forward service
- persistent store
- startup classes
- diagnostics and monitoring services
Resources and services can be limited to one or more Managed Servers in the domain, rather than being available to the domain as a whole. You can deploy resources and services to selected Managed Servers or to a cluster.
Domain Restrictions
A WebLogic Server environment may consist of a single domain that includes all the Managed Servers required to host applications, or multiple domains. You might choose to create multiple domains divided by organizational units, system administrator responsibilities, application boundaries, or other considerations. In designing your domain configuration, note the following restrictions:
- Each domain requires its own Administration Server for performing management activities. When you use 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.
- All Managed Servers in a domain must run the same version of the WebLogic Server software. The Administration Server may run either the same version as the Managed Servers in the domain, or a later service pack.
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. Furthermore, two or more system resources cannot have the same name.
