Learn about Oracle WebLogic Server domains and their contents, which include an Administration Server and usually one or more Managed Servers.
The following topics provides an overview of WebLogic Server domain, its contents, and certain restrictions associated to the domain configuration:
An Oracle WebLogic Server administration domain is a logically related group of Oracle WebLogic Server resources.
Domains include a special Oracle 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 Oracle WebLogic Server instances called Managed Servers. You deploy Web applications, EJBs, Web services, and other resources onto the Managed Servers and use the Administration Server for configuration and management purposes only.
You can use a single Oracle WebLogic Server installation to create and run multiple domains, or you can use multiple installations to run a single domain.
See Figure 2-1.
Figure 2-1 Oracle WebLogic Server Installations and Domains
How you organize your Oracle 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 Oracle 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. Each physical location requires its own Oracle WebLogic Server installation. A domain can be made up from multiple domain directories spanning multiple physical hosts. They all just need to be configured for the same domain.
Size. You might find that domains organized in small units 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.
You can create a simple domain that consists of a single server instance. This single instance acts as an Administration Server and hosts the applications that you are developing. The wl_server domain that you can install with Oracle WebLogic Server is an example of this type of domain.
An Oracle WebLogic Server domain might consist of an Administration Server, Managed Servers, and the resources and services that Managed Servers and deployed applications require.
Figure 2-2 shows a production environment that contains an Administration Server, three stand-alone Managed Servers, and a cluster of three Managed Servers.
Figure 2-2 Content of a Domain
Although the scope and purpose of a domain can vary significantly, most Oracle WebLogic Server domains contain the components described in this section.
The Administration Server operates as the central control entity for the configuration of the entire domain. It maintains the domain's configuration documents and distributes changes in the configuration documents to Managed Servers. You can also use the Administration Server as a central location from which to monitor all resources in a domain.
To interact with the Administration Server, you can use any of the administration tools listed in Summary of System Administration Tools and APIs in Understanding Oracle WebLogic Server. See System Administration in Understanding Oracle WebLogic Server for information about modifying the domain's configuration.
Each Oracle WebLogic Server domain must have one server instance that acts as the Administration Server.
For more information about the Administration Server and its role in the Oracle WebLogic Server JMX management system, see System Administration in Understanding Oracle WebLogic Server.
The failure of an Administration Server does not affect the operation of Managed Servers in the domain but it does prevent you from changing the domain's configuration. 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.
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. Periodically, the Managed Servers attempt to reconnect to the Administration Server. 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.
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 the domain's 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 information on starting a Managed Server without a running Administration Server, see Managed Server Independence Mode in Administering Server Startup and Shutdown for Oracle WebLogic Server. For information about re-starting an Administration Server, see Avoiding and Recovering From Server Failure in Administering Server Startup and Shutdown for Oracle WebLogic Server.
Managed Servers host business applications, application components, Web services, and their associated resources. To optimize performance, Managed Servers maintain a read-only copy of the domain's configuration document. When a Managed Server starts up, it connects to the domain's Administration Server to synchronize its configuration document with the document that the Administration Server maintains.
For production environments that require increased application performance, throughput, or high availability, you can configure two or more Managed Servers to operate as a cluster. A cluster is a collection of multiple Oracle WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability. In a 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 Oracle 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 an Oracle WebLogic Server cluster, see Understanding WebLogic Server Clustering in Administering Clusters for Oracle WebLogic Server.
In addition to the Administration Server and Managed Servers, a domain also contains the resources and services that Managed Servers and deployed applications require.
Managed Servers can use the following resources:
Machine definitions that 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 Node Manager Overview in the Administering Node Manager for Oracle WebLogic Server.
Network channels that define default ports, protocols, and protocol settings that a Managed Server uses to communicate with clients. After creating a network channel, you can assign it to any number of Managed Servers and clusters in the domain. See Configuring Network Resources in Administering Server Environments for Oracle WebLogic Server.
Virtual hosting, which defines a set of host names to which Oracle WebLogic Server instances (servers) or clusters respond. When you use virtual hosting, you use DNS to specify one or more host names that map to the IP address of a server or cluster. You also specify which Web applications are served by each virtual host.
Applications can use the following resources and services:
Security providers, which are modular components that handle specific aspects of security, such as authentication and authorization.
Resource adapters, which are system libraries specific to Enterprise Information Systems (EIS) and provide connectivity to an EIS.
Diagnostics and monitoring services.
JDBC data sources, which enable applications to connect to databases.
XML entity caches and registry of XML parsers and transformer factories.
Messaging services such as JMS servers and store-and-forward services.
Persistent store, which is a physical repository for storing data, such as persistent JMS messages. It can be either a JDBC-accessible database or a disk-based file.
Startup classes, which are Java programs that you create to provide custom, system-wide services for your applications.
Work Managers, which determine how an application prioritizes the execution of its work based on rules you define and by monitoring actual run-time performance. You can create Work Mangers for entire Oracle WebLogic Server domains or for specific application components.
Work Contexts, which enable applications to pass properties to a remote context without including the properties in a remote call.
In designing your domain configuration, note the restrictions mentioned.
Each domain requires its own Administration Server for performing management activities. When you use the WebLogic Server Administration Console or Fusion Middleware Control (FMWC) 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. See Relationship Between Clusters and Domains.
All Managed Servers in a domain must run the same version of the Oracle WebLogic Server software. The Administration Server may run either the same version as the Managed Servers in the domain, or a later patch set.
Server instances cannot have the same name as the domain.
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 data source in one domain, you cannot use it with a Managed Server or cluster in another domain. Instead, you must create a similar data source in the second domain. Furthermore, two or more system resources cannot have the same name.
When naming a domain or a server instance, note the restrictions and considerations mentioned.
Use alphanumeric names for domain and server instances.
Apart from the alphanumeric characters, a valid domain or server name can include only the following characters:
Use a unique name for each server instance. Within a domain, all configuration objects, including server instances, machines, clusters, JDBC connection pools, virtual hosts, and other resource types, must have unique names and must not use the same name as the domain.
Server names are for identification purposes only. Server names are not used as part of the URL for applications deployed on the server instance. The server name displays in the Administration Console or Fusion Middleware Control. If using WebLogic Server command-line utilities, you use the server name to identify the server instance.
Once you have created a server instance, you cannot change its name. To use a new name, clone the server instance and provide a new name for the clone.
You can configure a WebLogic domain to run in one of two modes: development mode or production mode. When in production mode, you can choose to further secure your domain by enabling secured production mode.
The domain mode determines default settings regarding security and logging. In development mode, the security configuration is more relaxed. You can start the Administration Server using a boot identity file or deploy an application using the
autodeploy directory. In production mode, the security configuration is more stringent, such as requiring a username and password to deploy applications and start the Administration Server. In secured production mode, your production domain is highly secure because the default authorization and role mapping policies are more restrictive, and the security configuration defaults are more secure.
There are also several differences between the default settings in development mode, production mode, and secured production mode, including:
The number of threads in an execute queue
Log settings, including the maximum number of files saved during log rotation, the minimum size of the log file that triggers log rotation, and whether logs are rotated at startup
The default for server lifecycle operations timeout
SNMP security level
Servlet reload check periods
For details about how the domain mode you select determines the default security configuration for your domain, see How Domain Mode Affects the Default Security Configuration in Securing a Production Environment for Oracle WebLogic Server. This topic explains how the default settings for SSL, the administrative and listen ports, auditing, logging, deployment of internal applications, the domain configuration lock, and other configuration settings differ depending on the domain mode that is enabled.
Oracle recommends that you do not enable the Web Services Test Client in production mode. See Using the Web Services Test Client in Administering Web Services.
Modifying Domain Modes
You can configure the domain mode at the time you create the domain, or you can also change the domain mode any time later. To select the domain mode using the Configuration Wizard, see Domain Mode in Creating WebLogic Domains Using the Configuration Wizard.
WebLogic Server supports modifying a domain from production mode to development mode, from development mode to production mode, and from production mode to secured production mode. To modify a domain from development mode to production mode using the WebLogic Server Administration Console, see Change to production mode in the Oracle WebLogic Server Administration Console Online Help.
After changing to production mode, Oracle recommends that you enable secured production mode to ensure higher security standards for your production environment. However, you cannot upgrade existing domains to run in secured production mode; only the domains created in 220.127.116.11.0 can be configured for secured production mode.
You can modify your production domain to run in secured production mode by using one of the following methods:
Use the WebLogic Server Administration Console to enable secured production mode for your production domain. See Secure your production domain in the Oracle WebLogic Server Administration Console Online Help.
Use the Fusion Middleware Control to enable secured production mode and configure related security settings for your domain. See Configure domain security in Administering Oracle WebLogic Server with Fusion Middleware Control.
setOption WLST command. While creating the domain, you can use the
ServerStartMode option in WLST command to start your server in secured production mode. See setOption in WLST Command Reference for Oracle WebLogic Server.
Use WLST online to enable secured production mode for your domain. See Using WLST Online to Update an Existing WebLogic Domain in Understanding the WebLogic Scripting Tool.
all, modify the domain start scripts. This change enables bytecode verification. For more information about bytecode verification, see Java Language Security and Bytecode Verification in the Java Security Overview at
-Dweblogic.system.RemoveBootIdentity=trueargument, which removes the boot identity file. The boot identity file only must be removed on the first restart after changing the configuration to production mode. You can use either of the following methods:
Open a separate command shell and include this argument in the
weblogic.Server startup command for each server instance.
JAVA_OPTIONS variable to include
-Dweblogic.system.RemoveBootIdentity=true and then invoke the start script of the server.
When you change a domain from development mode to production mode:
The domain start scripts (and the value of the
-Xverify flag) do not change.
boot.properties file remains in use.