Weblogic Domain Activity

Editor's Notes

• #4: 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. 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 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. 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 much more stringent, such as requiring a username and password to deploy applications and start the Administration Server.
• #5: A domain can include multiple WebLogic Server clusters and non-clustered WebLogic Server instances. A minimal domain can contain only one WebLogic Server instance, which functions both as an Administration Server, and as a Managed server—such a domain can be useful while developing applications, but is not recommended for use in a production environment. Terms:- Managed Server: Any weblogic server instances apart from Admin server. Admin Server: Administration Server is WebLogic Server instance that maintains configuration data for a domain. You can deploy your application on administration Server but it is recommended to create managed Server and deploy your application in managed server and leave Administration domain for configuration and maintenance Cluster: Group of WebLogic Managed Server Instances that work together to provide high availability and scalability for applications is called cluster. Node Manager: Node Manager is a Java utility that runs as a separate process from Oracle WebLogic Server and allows you to perform common operations for a Managed Server, regardless of its location with respect to its Administration Server, and for system components If you run Node Manager on a computer that hosts Managed Servers, you can start and stop the Managed Servers remotely using the Administration Console, Fusion Middleware Control, or the command line. Node Manager can also automatically restart a Managed Server after an unexpected failure.
• #6: You can invoke the services of the Administration Server in the following ways: WebLogic Server Administration Console—The Administration Console is a browser-based graphical user interface (GUI) you use to configure a domain. For more information WebLogic Server Application Programming Interface (API)—You can write a Java class to modify configuration attributes using the API provided with WebLogic Server. For more information, WebLogic Server command-line utility—This utility (weblogic.Admin) allows you to create scripts to automate domain management. SNMP—You can use Simple Network Management Protocol, versions SNMPv1 and SNMPv2 to monitor a WebLogic Server domain.
• #8: 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.
• #11:  A server instance reaches the SHUTDOWN state as a result of a graceful shutdown or forced shutdown A graceful shutdown can be initiated when the server instance is in the RUNNING or the STANDBY state. The graceful shutdown process consists of the following state transitions: RUNNING—>SUSPENDING—>STANDBY—>SHUTTING DOWN—>SHUTDOWN A forced shutdown can be initiated from any server state. The forced shutdown process consists of the following state transitions: any state—>STANDBY—>SHUTTING DOWN—>SHUTDOWN In the STARTING state, a server instance prepares itself to accept requests and perform application processing. A server instance cannot accept requests while in the STARTING state. A server instance can enter the STARTING state only from the SHUTDOWN state as a result of a Start command. SHUTDOWN—>STARTING—>RUNNING In the STANDBY state, a server has initialized all of its services and internal applications (such as the Administration Console), can accept administration commands, and can participate in cluster communication. Non-internal applications are partially deployed; when you move the server to the RUNNING state it completes the remainder of the deployment process. A server in the STANDBY state does not accept requests from external clients. A server instance enters the RESUMING state as a result of the Resume command. A server instance that is resumed from the STANDBY goes through the following state transitions: When a server instance is in the RUNNING state, it offers its services to clients and can operate as a full member of a cluster. A server instance can enter the RUNNING state if: It is started using the Start command. During the regular startup process, a server instance goes through the following state transitions: SHUTDOWN—>STARTING—>STANDBY—>RUNNING It is started with the Resume command. During the resume process, a server instance goes through the following state transitions: STANDBY—>RESUMING—>RUNNING While in the SUSPENDING state, the server handles a predefined portion of the work that is currently in process—referred to as "in-flight" work.  A server instance enters the shutdown state as a result of a graceful shutdown or forced shutdown process. A server instance enters the FAILED state when one or more critical services become dysfunctional.  If a server instance cannot be contacted, it is in the UNKNOWN state.
• #12: A machine is the logical representation of the computer that hosts one or more WebLogic Server instances. Each Managed Server must be assigned to a machine. To create and configure a machine:
• #19: A WebLogic Server cluster consists of multiple WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster’s capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.
• #20: Horizontal scaling means that you scale by adding more machines into your pool of resources Vertical scaling means that you scale by adding more power (CPU, RAM) to your existing machine. With horizontal-scaling it is often easier to scale dynamically by adding more machines into the existing pool Vertical-scaling is often limited to the capacity of a single machine, scaling beyond that capacity often involves downtime and comes with an upper limit.
• #21: Scalability: The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service—the application continues to run without impact to clients and end users.Reliable:Should be reliable to any failuresHigh – Available: In a WebLogic Server cluster, application processing can continue when a server instance fails. You “cluster” application components by deploying them on multiple server instances in the cluster—so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.
• #23: Application Failover failover means that when an application component (typically referred to as an “object” in the following sections) doing a particular “job”—some set of processing tasks—becomes unavailable for any reason, a copy of the failed object finishes the job. For the new object to be able to take over for the failed object:  There must be a copy of the failed object available to take over the job.  There must be information, available to other objects and the program that manages failover, defining the location and operational status of all objects—so that it can be determined that the first object failed before finishing its job.  There must be information, available to other objects and the program that manages failover, about the progress of jobs in process—so that an object taking over an interrupted job knows how much of the job was completed before the first object failed, for example, what data has been changed, and what steps in the process were completed. WebLogic Server uses standards-based communication techniques and facilities— including IP sockets and the Java Naming and Directory Interface (JNDI)—to share and maintain information about the availability of objects in a cluster. These techniques allow WebLogic Server to determine that an object stopped before finishing its job, and where there is a copy of the object to complete the job that was interrupted.