The following sections introduce WebLogic Server domains and their contents:
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.
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:
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.
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.
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.|
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.
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.
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:
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
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.
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, seein Managing Server Startup and Shutdown.
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. Seein 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, seein Using WebLogic Server Clusters.
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:
The domain configuration also includes information about resources and services associated with applications hosted on the domain. Examples of these resources and services include:
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.
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:
If you have created multiple domains, each domain must reference its own database schema. 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.