Weblogic Domain by hedongchenchen


									Weblogic Server Domain
You manage a WebLogic Server installation by creating WebLogic Server domains --
a logically related group of WebLogic Server resources managed as a unit. A domain
includes one or more WebLogic Server instances and can also include WebLogic
Server clusters. You deploy and manage your applications as part of a WebLogic
Server domain.

The purpose of config.xml is to store changes to managed objects so that they are
available when WebLogic Server is restarted.

Each time you use the Administration Console or other WebLogic Server utilities to
modify the config.xml file, WebLogic Server archives the older version. You can
configure the number of archived files WebLogic Server keeps.

Introduction to System Administration: You manage a WebLogic Server
installation by using any of several system administration tools provided with
WebLogic Server. A WebLogic Server installation can consist of a single WebLogic
Server instance or multiple instances, each hosted on one or more physical
machines. The system administration tools include the Administration Console,
command line utilities, and an API, with which you manage security, database
connections, messaging, transaction processing, and the runtime configuration of
your applications. The tools also allow you to monitor the health of the WebLogic
Server environment to ensure maximum availability and performance for your

System Administration Infrastructure
System administration infrastructure in WebLogic Server is implemented using the
Java Management Extension (JMX) specification from Sun Microsystems. The JMX
API models system administration functions with Java objects called MBeans.
Knowledge of this implementation as described in this discussion of system
administration infrastructure is not necessary to manage a WebLogic Server

The Administration Server and Managed Servers
One instance of WebLogic Server in each domain acts as an Administration Server.
The Administration Server provides a central point for managing a WebLogic
Server domain. All other WebLogic Server instances in a domain are called
Managed Servers. In a domain with only a single WebLogic Server instance, that
server functions both as Administration Server and Managed Server.
For a typical production system, Oracle recommends that you deploy your
applications only on Managed Servers. This practice allows you to dedicate the
Administration Server to configuration and monitoring of the domain, while one or
more Managed Servers service your applications.
Administration Console
The Administration Console is a Web Application hosted by the Administration
Server. You access the Administration Console from any machine on the local
network that can communicate with the Administration Server through a Web
browser (including a browser running on the same machine as the Administration
Server). The Administration Console allows you to manage a WebLogic Server
domain containing multiple WebLogic Server instances, clusters, and applications.
The management capabilities include:
      Configuration
      Stopping and starting servers
      Monitoring server health and performance
      Monitoring application performance
      Viewing server logs
      Assistants, which step you through the following tasks:
      Creating JDBC connection pools and DataSources
     Deploying your applications, Configuring SSL etc
Through the Administration Console, System administrators can easily perform all
WebLogic Server management tasks without having to learn the JMX API or the
underlying management architecture. The Administration Server persists changes to
attributes in the config.xml file for the domain you are managing.

Starting the Administration Console
This section contains instructions for starting the Administration Console.
   To start the Administration Console:
   1. Start an Administration Server.
   2. Open one of the supported Web browsers and open the following URL:
Where hostname is the DNS name or IP address of the Administration Server
and port is the listen port on which the Administration Server is listening for
requests (port 7001 by default). If you have configured a domain-wide
Administration port, use that port number. If you configured the Administration
Server to use Secure Socket Layer (SSL) you must add s after http as follows:
   3. When the login page appears, enter the user name and the password you
      used to start the Administration Server (you may have specified this user
      name and password during the installation process) or enter a user name
      that belongs to one of the following security groups: Administrators,
      Operators, Deployers, or Monitors. These groups provide various levels of
      access to system administration functions in the Administration Console.
       Using the security system, you can add or delete users to one of these
       groups to provide controlled access to the console.
  Elements of the Administration Console
  The Administration Console user interface includes the following panels.

  Change Center
  This is the starting point for using the Administration Console to make changes
  in WebLogic Server

Change Center

  Domain Structure
  This panel contains a tree structure you can use to navigate to pages in the
  Administration Console. Select any of the nodes in the Domain Structure tree to
  view that page. Click a + (plus) icon in the Domain Structure to expand a node
  and a - (minus) icon to collapse the node.

Domain Structure
How do I... :
  This panel includes links to online help tasks that are relevant to the current
  Console page.
System Status
The System Status panel reports on the number of information, error, and
warning messages that have been logged.

Using the Change Center
The starting point for using the Administration Console to make changes in your
WebLogic Server domain is the Change Center. The Change Center provides a
way to lock a domain configuration so you can make changes to the
configuration while preventing other accounts from making changes during your
edit session. The domain configuration locking feature is always enabled in
production domains. It can be enabled or disabled in development domains. It is
disabled by default when you create a new development domain.
To change a production domain’s configuration, you must:
      1.   Locate the Change Center in the upper left of the Administration Console

       2.  Click the Lock & Edit button to lock the configuration edit hierarchy for the

       3.  Make the changes you desire on the relevant page of the Console. Click
       Save on each page where you make a change.

       4.  When you have finished making all the desired changes, click Activate
       Changes in the Change Center.

As you make configuration changes using the Administration Console, you click
Save (or in some cases Finish) on the appropriate pages.

Undoing Changes
You can revert any pending (saved, but not yet activated) changes by clicking
Undo All Changes in the Change Center.
 Releasing the Configuration Lock
 You release the configuration lock as follows:

           Before you make changes, click Release Configuration in the Change
        Center to release the lock explicitly.

           After you save changes, click Activate Changes or Undo All Changes in the
        Change Center to release the lock implicitly.

How Change Management Works
 To provide a secure, predictable means for distributing configuration changes in
 a domain, WebLogic Server imposes a change management process that loosely
 resembles a database transaction. The configuration of a domain is represented
 on the file system by a set of XML configuration files, centralized in the
 config.xml file, and at run time by a hierarchy of Configuration MBeans. When
 you edit the domain configuration, you edit a separate hierarchy of
 Configuration MBeans that resides on the Administration Server. To start the
 edit process, you obtain a lock on the edit hierarchy to prevent other people
 from making changes. When you finish making changes, you save the changes
 to the edit hierarchy. The changes do not take effect, however, until you
 activate them, distributing them to all server instances in the domain. When you
 activate changes, each server determines whether it can accept the change. If
 all servers are able to accept the change, they update their working
 configuration hierarchy and the change is completed.

 Dynamic and Non-Dynamic Changes
 Some changes you make in the Administration Console take place immediately
 when you activate them. Other changes require you to restart the server or
 module affected by the change. These latter changes are called non-dynamic
 changes. Non-dynamic changes are indicated in the Administration Console with
 this warning icon,    .
 Changes to dynamic configuration attributes become available once they are
 activated, without restarting the affected server or system restart. These
 changes are made available to the server and run-time hierarchies once they
 are activated. Changes to non-dynamic configuration attributes require that the
 affected servers or system resources be restarted before they become effective.
 Note that WebLogic Server’s change management process applies to changes in
 domain and server configuration data, not to security or application data.

 Viewing Changes
 You can view any changes that you have saved, but not yet activated, by
 clicking the View Changes and Restarts link in the Change Center. The View
 Changes and Restarts link presents two tabs, Change List and Restart Checklist:

            The Change List tab presents all changes that have been saved, but not
        yet activated.
             The Restart Checklist lists all servers for which non-dynamic changes have
         been activated, but which require restarts before the changes become

Server Life Cycle
At any time, a WebLogic Server instance is in a particular operating state.
Commands—such as start, stop, and suspend—cause specific changes to the state
of a server instance. The following sections describe WebLogic Server states, state
transitions, life cycle commands.

Life Cycle Overview
The series of states through which a WebLogic Server instance can transition is
called the server life cycle. Figure illustrates the server life cycle and the
relationships between WebLogic Server operating states.
Understanding WebLogic Server States
WbLogic Server displays and stores information about the current state of a server

SHUTDOWN: In the SHUTDOWN state, a server instance is configured but inactive. A
server instance reaches the SHUTDOWN state as a result of a graceful shutdown or
forced shutdown.

  STARTING: During the STARTING state, a WebLogic Server instance transitions
  from SHUTDOWN to STANDBY, as a result of a Start, Start in Admin, or Start in
  Standby command.
  In the STARTING state, a server instance cannot accept any client or
  administrative requests.
  The server instance obtains its configuration data:
             An Administration Server retrieves domain configuration data, including
         the domain security configuration, from its config directory.

             A Managed Server contacts the Administration Server for its configuration
         and security data. If the Managed Server is configured for SSL
         communications, it uses its own certificate files, key files, and other SSL-
         related files and contacts the Administration Server for the remaining
         configuration and security data.

  STANDBY: A server instance in STANDBY does not process any request—its
  regular Listen Port is closed. The Administration Port is open, and accepts life
  cycle commands that transition the server instance to either the RUNNING or the
  SHUTDOWN state. Other Administration requests are not accepted.

  Starting a server instance in standby is a method of keeping it available as a
  “hot” backup, a useful capability in high-availability environments.
  The only life cycle command that causes a server instance to enter the STANDBY
  state and remain in that state is the Start in Standby command. A server
  instance transitions through the STANDBY state when you issue a Start or a Start
  in Admin command. A server in the STANDBY state does not accept requests
  from external clients.

  ADMIN: In the ADMIN state, WebLogic Server is up and running, but available
  only for administration operations, allowing you to perform server and
  application-level administration tasks. When a server instance is in the ADMIN
             The Administration Console is available.

            The server instance accepts requests from users with the admin role.
         Requests from non-admin users are refused.
           Applications are activated in the application ADMIN state. They accept
       requests from users with the admin and AppTester roles. Users with these
       roles, accessing an application in the application ADMIN state, have access to all
       application functionality, not just administrative functions.

           The JDBC, JMS, and JTA subsystems are active, and administrative
       operations can be performed upon them. However, you do not have to have
       administrator-level privileges to access these subsystems when the server is in
       the ADMIN state.

           Deployments or re-deployments are allowed, and take effect when you
       transition the server instance from the ADMIN to the RUNNING state (using the
       Resume command).

           ClusterService is active and listens for heartbeats and announcements
       from other cluster members. It can detect that other Managed Servers have
       joined the cluster, but is invisible to other cluster members.

You can transition a server instance to the ADMIN state using the Start in Admin,
Suspend, or Force Suspend commands.
A server instance transitions through the ADMIN state as a result of Start,
Shutdown, and Force Shutdown commands.
You can transition a server instance in the ADMIN state to RUNNING with the
Resume command, or to SHUTDOWN, with the Shutdown or Force Shutdown

RESUMING: During this transitional state, WebLogic Server performs the
operations required to move itself from the STANDBY or ADMIN state to the
RUNNING state.

A server instance transitions to the RESUMING state when you issue the Resume
command. A server instance transitions through the RESUMING state when you
issue the Start command.

RUNNING: In the RUNNING state, WebLogic Server is fully functional, offers its
services to clients, and can operate as a full member of a cluster.
A server instance transitions to the RUNNING state as a result of the Start
command, or the Resume command from the ADMIN or STANDBY states.

You can transition a server instance in the RUNNING state to the SUSPENDING
state or the FORCE_SUSPENDING state using graceful and force Suspend and
Shutdown commands.

SUSPENDING: During this transitional state, WebLogic Server performs the
operations required to place itself in the ADMIN state, suspending a subset of
WebLogic Server subsystems and services in an ordered fashion, and completing
a predefined portion of the application work currently in process (“in-flight”
  A server instance transitions to the SUSPENDING state when you issue the
  Suspend command. A server instance transitions through the SUSPENDING state
  when you issue a Shutdown command.

  During this transitional state, WebLogic Server performs the operations required
  to place itself in the ADMIN state, suspending a subset of WebLogic Server
  subsystems and services in an ordered fashion. During the FORCE_SUSPENDING
  state, WebLogic Server does not complete in-flight work gracefully; application
  work in progress is abandoned.
  A server instance transitions through the FORCE_SUSPENDING state when you
  issue the Force Suspend or Force Shutdown command.

  SHUTTING_DOWN : During this transitional state, WebLogic Server completes the
  suspension of subsystems and services and does not accept application or
  administration requests.
  A server instance transitions to the SHUTTING_DOWN state when you issue a
  Shutdown or Force Shutdown command.
  FAILED: A running server instance can fail as a result of out-of-memory
  exceptions or stuck application threads, or if one or more critical services
  become dysfunctional. A server instance monitors its health, and upon detecting
  that one or more critical subsystems are unstable, it declares itself FAILED.

  A FAILED server instance cannot satisfy administrative or client requests.

  When a server instance enters the FAILED state, it attempts to return to a non-
  failed state. If it failed prior to reaching the ADMIN state, the server instance
  shuts itself down with an exit code that is less than zero.

  If the server instance fails after reaching the ADMIN state, but before reaching
  the RUNNING state, by default, it returns to the ADMIN state, if the administration
  port is enabled.

Lifecycle commands:

Start: When a server instance starts, it: Retrieves its configuration data.
An Administration Server retrieves domain configuration data, including security
configuration data, from the config.xml for the domain.
A Managed Server contacts the Administration Server for its configuration and
security data. Starts its kernel-level services, which include logging and timer
Initializes subsystem-level services with the configuration data that it retrieved
in step 1. These services include the following:
                    Security Service                     JCA Container
                   RMI Service                          JDBC Container
                   Cluster Service                      EJB Container
                   IIOP Service                         Web Container
                   Naming Service                       Deployment
                   RMI            Naming
          Service                                        JMS Provider
                   File Service                       Remote
                                                         Transaction Service

Deploys modules (applications, ex: .war, .ear files) in the appropriate container
and in the order that you specify in the WebLogic Server Administration Console.

Graceful Shutdown
A graceful shutdown gives WebLogic Server subsystems time to complete certain
application processing currently in progress. The work that it completes during
graceful shutdown is referred to as in-flight work. During a graceful shutdown,
subsystems complete in-flight work and suspend themselves in a specific sequence
and in a synchronized fashion, so that back-end subsystems like JDBC connection
pools are available when front-end subsystems are suspending themselves.

Forced Shutdown
A forced shutdown is immediate—WebLogic Server subsystems suspend all
application processing currently in progress.

To top