Oracle Weblogic Server Review

Oracle Weblogic Server :

• Is a Java EE Application Server.
• Hosts Java EE Applications.
• Provides Clustering for load balancing and High Availability.
• Offers an extensible security realms for authentication,authorization and so on....
• Is a platform on which "Java Components" of Oracle Fusion middleware run.

          Oracle WebLogic Server is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server. The WebLogic Server infrastructure supports the deployment of many types of distributed applications and is an ideal foundation for building applications based on Service Oriented Architectures (SOA). SOA is a design methodology aimed at maximizing the reuse of application services. 

          The WebLogic Server complete implementation of The Sun Microsystems Java EE 5.0 specification provides a standard set of APIs for creating distributed Java applications that can access a wide variety of services, such as databases, messaging services, and connections to external enterprise systems. End-user clients access these applications using Web browser clients or Java clients. It also supports the Spring Framework, a 2 programming model for Java applications which provides an alternative to aspects of the Java EE model. 

          In addition to the Java EE implementation, WebLogic Server enables enterprises to deploy mission-critical applications in a robust, secure, highly available, and scalable environment. These features allow enterprises to configure clusters of WebLogic Server instances to distribute load, and provide extra capacity in case of hardware or other failures. New diagnostic tools allow system administrators to monitor and tune the performance of deployed applications and the WebLogic Server environment itself. You can also configure WebLogic Server to monitor and tune application throughput automatically without human intervention. Extensive security features protect access to services, keep enterprise data secure, and prevent malicious attacks.

Basic Terminologies used in weblogic :

Before we delve into the administration of WebLogic Server, I want to make sure you clearly understand the key terminology you’re going to encounter throughout the book. Some of the WebLogic Server terms and definitions are obvious, but others aren’t, such as the concept of a machine, for example.

Weblogic Server Instance :

             A Weblogic Server instance is a Java Virtual Machine (JVM) process that runs the Java code. The instance is the actively working component, receiving client requests and sending them on to the appropriate components, and sending the processed requests back to the originating clients. The server instance manages the resources necessary for applications, such as the JTA and JDBC services, to function. In each domain, one instance serves as the Administration Server, which is your primary means of managing the domain. The rest of the WebLogic Server instances are called Managed Servers. If you have a domain with just one WebLogic Server instance, as is the case in a development environment, the single server instance functions as both the Administration Server and the Managed Server. Note that the terms WebLogic Server and WebLogic instance are often used interchangeably. 

Weblogic Server Domain :

                 A domain is a set of WebLogic Server instances that you manage with the Administration Server, which itself is nothing but another WebLogic Server instance, albeit a special one. Any configuration changes you make to a domain will apply to all members of that domain. Domains offer you ease of administration—for example, you can apply configuration changes on a domain-wide basis that apply to all the management servers that belong to that domain. Every domain has exactly one Administration Server, which is used to configure and manage that domain. In addition to the WebLogic Server instances, a domain also includes the application components that you deploy, as well as all the services required by the server instances of that domain. The Administration Server is usually referred to as the Admin Server for short. The concept of a domain offers you the administrative ease you need to manage your WebLogic environment. A domain encompasses the Admin Server, Managed Servers (including those configured into WebLogic clusters), machines (servers), and all the services necessary to run your applications. The fact that a domain includes all the configuration data for the servers, deployments, and physical network makes it very easy to configure and manage complex, geographically dispersed WebLogic Server deployments. A domain lets you easily deploy applications across multiple WebLogic Server instances located on heterogeneous servers and multiple networks, with varying physical and network descriptions. Administering a domain makes it easy for you to configure high availability with the help of multiple WebLogic Server instances and administer various services spread across heterogeneous host servers. The first step in using Oracle WebLogic Server to deploy applications is to create a domain. A domain can consist of just a single Admin Server, with no Managed Servers at all, as is common in a development environment. A production cluster ranges over several physical machines to provide high availability and failover protection, but you can also configure a cluster on a single server for testing and development purposes. WebLogic Server stores the configuration information for a domain in the config.xml file, which is stored on the machine where the Admin Server runs and serves as the domain’s configuration file. The domain also contains security settings, log files, and startup scripts for the Admin and Managed Servers that belong to that domain. The WebLogic Configuration Wizard and the WebLogic Domain Wizard offer you extremely easy ways to create domains, as well as the servers and clusters that belong to that domain.

Note: 

         Each Managed Server contains a local copy of its domain configuration. Upon startup, it synchronizes its configuration with the Admin Server. Similarly, when you make domain configuration changes on the Admin Server, those changes are propagated to the Managed Server’s configuration.

Administration Server:

          A server is an instance of WebLogic Server that runs in its own JVM, and the Admin Server is a special instance of WebLogic Server designed for managing the domain rather than running applications. There is a one-to-one relationship between domains and the Admin Server—an Admin Server belonging to Domain A can’t manage Domain B.  You can deploy applications on the Admin Server, but unless you’re operating in a purely developmental environment, use the Admin Server strictly for performing management tasks, not for deploying any applications. Although you can deploy applications on the Admin Server in a development environment, it’s a best practice not to do so in a production environment. For one thing, you don’t want application work to compete with administrative work in a production environment. You also want to firewall the Admin Server separately so external clients can’t access it. The Admin Server is critical to the functioning of a WebLogic Server domain, since it manages the domain configuration, including the servers that are part of the domain, as well as all the applications and services you deploy to the various servers. Apart from this management of the domain configuration information, the Admin Server has all of the functionality of a Managed Server; in fact, an Admin Server runs the same code and is managed internally the same way as a Managed Server. The Admin Server hosts the Administration Console, which is a web application front end used for configuring, monitoring, and managing a domain. You can access the Administration Console with any supported browser that can access the Admin Server. All WebLogic system administration tools and APIs interact with the Admin Server. If you install the optional Node Manager service, the Admin Server communicates with the Node Manager service on each machine to talk to the Managed Servers running on that machine. 

Managed Server:

          Managed servers are the workhorses of WebLogic Server. Any additional servers you create after the creation of the default Admin Server are Managed Servers. The Managed Server contacts the Admin Server, only when you start it up, to get the configuration and deployment settings. For this reason, you should always start up the Admin Server before you start a Managed Server. Once a Managed Server starts running, it operates completely independent of the Admin Server. Although you can deploy an application to the Admin Server itself, the recommended approach is to deploy applications to the Managed Servers. In a production environment, it’s common to run multiple Managed Servers as part of a cluster. A Managed Server hosts your Java EE applications, as well as all related resources and services such as Java Database Connectivity (JDBC) connection pools and data sources, Java Transaction API (JTA) transaction services, and Java Messaging Service (JMS) connection factories that are necessary to support application deployments. As mentioned earlier, upon its startup, a Managed Server will contact the Admin Server to retrieve any configuration changes since the Managed Server was last shut down. However, a Managed Server can continue to run, and it’s even possible to start it up, in the absence of an Admin Server. 

Weblogic Server Cluster:

         A WebLogic Server cluster is a group of WebLogic Server instances consisting of multiple Managed Servers that run simultaneously. The multiple Managed Servers work together to provide replication services for one another, and the Admin Server is not generally a part of any cluster. Most production deployments use clusters to increase reliability and scalability through load distribution and high availability. To achieve the high availability capability, you deploy resources and services in a homogeneous fashion on each of the Managed Servers that are part of a cluster. Clusters host applications that respond to HTTP requests that are routed to the cluster through a hardware load balancer. You can also set up load balancing on a WebLogic Server instance or a third-party Web Server with the help of plug-ins supplied by WebLogic Server. The load balancer handles the HTTP requests after the requests pass through a firewall. Cluster members pass replicated copies of objects such as HTTP sessions among themselves to provide the failover capability for the cluster.A WebLogic Server domain can consist of multiple Managed Servers that aren’t part of a cluster, or that are part of a cluster or it can consist of multiple clusters—just remember that even if you have multiple Managed Servers in a domain, you can avail yourself of WebLogic Server’s high availability and load-balancing features only by deploying a cluster of servers. High availability lets you continue serving clients even when you experience a failure such as a machine or WebLogic Server failure. WebLogic Server offers you many powerful features such as replication, failover, and the ability to migrate services so you have high availability for your system. Clusters provide load-balancing capabilities by letting you spread requests across the cluster members. Clusters also offer scalability by letting you easily add on additional servers to the cluster to accommodate increased demand for WebLogic Server services. The important thing to understand here is that the cluster automatically provides these capabilities without the user experiencing any disruption. Each domain may consist of multiple Java EE resources such as JDBC connection pools and JMS servers, which the domain makes available to all the applications it hosts. Note that domain resources, such as a JDBC connection pool, are not shared across domains—each WebLogic domain must create its own set of resources. This applies when dealing with clusters as well, which are treated as a domain resource. A cluster’s Managed Servers thus can’t overlap domains and belong to more than one domain at the same time. Therefore, whenever you perform a failover within a cluster, you can fail over from one Managed Server to another Managed Server within the same domain but not to a Managed Server that belongs to a different domain. How does one design a domain? Other than the simple requirement that you must install the same version of WebLogic Server for all the Managed Server instances in a cluster, it’s easy to design a cluster. Although a WebLogic Server cluster can run entirely on a single machine, to take advantage of the high availability features, Managed Servers are typically installed on two or more physical machines. To increase a cluster’s capacity, you can either add more Managed Server instances to the existing cluster architecture, or you can add more physical machines to the cluster, with the additional machines hosting new Managed Server instances, of course. Managed Servers can serve as backups for services such as JTA and JMS that another Managed Server in the same cluster hosts. There’s really no hard and fast rule for organizing your domains; one way to organize domains is to create separate domains to handle different types of work. For example, you can have one domain dedicated to online shopping and another to support your internal e-business operations. In general, you design domains based on your service needs, security requirements, and management considerations You can also create separate domains for physically separate business locations.

Machine:

        A machine in the Weblogic Server context is the logical representation of the computer that hosts one or more Weblogic Server instances (servers). The Admin Server uses the machine definitions that you create to start remote servers through the Node Managers that run on those servers. A machine could be a physical or virtual server that hosts an Admin or Managed Server that belongs to a domain. You’ll see later in the book that you must define a machine first if you want the Admin Server to use the Node Manager service to monitor, start, and stop the Managed Servers running on a server. In a sense, a machine in a WebLogic Server environment is more or less equivalent to an instance of a Node Manager and this is essentially the concept that a machine represents. WebLogic clusters make use of the machines you define in order to decide the optimal way to replicate session data on a different server that is part of a cluster.

Network Channels:

     

        Network channels are an optional feature that allows you to separate different classes of network traffic. You can make use of separate network channels to separate server and client traffic and direct it to different listening ports or addresses. If you need to allow both secure and nonsecure traffic on the same server, you can create multiple channels to support the diverse traffic with different security protocols. You can also use network channels to manage quality of service by using weighted, value-based priorities for different channels. This enables you to assign high weighted values to faster channels that use faster network interface cards and dedicate them to the types of traffic that require faster throughput, for example. Network channels control all communication-related aspects such as listen addresses, protocols, and port numbers throughout the domain.

Node Manager:

         The Node Manager is an optional process that runs on a machine and manages the availability of all servers that run on that machine. Node Managers help you remotely start, stop, suspend, and restart Managed Servers. The Node Manager works with the Admin Server using a secure channel and lets you manage the availability, as well as monitor the health, of all Managed Servers in a single domain. The Managed Servers that the Node Manager controls can be independent servers or they can be members of a cluster. The Node Manager monitors remote Managed Servers and is capable of automatically restarting them when they fail. It also kills Managed Servers that exhibit unstable behavior. It is recommended that you install a Node Manager service on each machine that hosts a Managed Server. Managing the servers with Node Managers is actually a key requirement for configuring automatic server migration in a cluster following a server failure.

Virtual Hosts:

         Virtual hosts rely on the Domain Name System (DNS) to map hostnames to the IP address of a single server or a cluster of servers. By doing so, multiple domain names can be hosted on your server wherein different web applications can be assigned to different virtual hosts, effectively sharing all resources and being differentiated only by their hostnames.

Work Managers:

       Work Managers help you manage the WebLogic Server instance workload, specifically by letting you prioritize work execution, which you do by defining request classes and constraints. You can configure Work Managers at the domain level (using global Work Managers) or at the application or module level. 

Services:

       

         Following are some of the main services used in a WebLogic environment:

                     ■ JDBC (Java Database Connectivity) enables Java programs to handle database connections established through connection pools.

                     ■ JMS (Java Messaging Service) is a standard API that enables applications to communicate through enterprise messaging systems. 

                     ■ JTA (Java Transaction API) specifies standard Java interfaces between transaction managers and the parties in a distributed transaction system.

More to follow..............


Regards,
Mineeketan.