Weblogic Server Tutorial – Fill Out and Use This PDF

2   Oracle WebLogic Server 12c Administration Handbook

The introduction to this book provided a quick outline of the Java Enterprise Edition (Java EE) and the nature of web applications for which you use Oracle WebLogic Server 12c. Since the primary goal of this book is for you to understand how to administer Oracle WebLogic

Server 12c, let’s begin by discussing key administration topics such as installing and upgrading Oracle WebLogic Server and becoming familiar with the administration tools you use day in and day out to manage the server. There are three major administrative tools that are going to be your day-to-day companions when managing Oracle WebLogic Server 12c: the Administration Console, the Node Manager utility, and the WebLogic Scripting Tool (WLST), which is based on the open source Jython language. This chapter briefly introduces these tools, and you’ll learn how to use all three of these tools, as well as other WebLogic Server (this term is used as a synonym for Oracle WebLogic Server 12c throughout the rest of this book) management commands, in later chapters. In this and the next chapter, I make extensive use of the sample Oracle WebLogic Server 12c applications that you can install to learn various administrative and deployment-related concepts. This chapter introduces the Oracle WebLogic Server 12c sample domains that host the sample applications. This and other chapters use the sample domains to explain various Oracle WebLogic Server 12c management concepts. Before we start reviewing the installation, upgrading, and management of Oracle WebLogic Server 12c, however, let’s review the Oracle WebLogic Server 12c product set as well as key terminology and important architectural concepts that illustrate how Oracle WebLogic Server 12c functions.

Oracle WebLogic Server: An Overview

Before you learn how to install, upgrade, and manage Oracle WebLogic Server, let’s quickly review the set of Oracle WebLogic Server 12c products. Following that is a brief summary of key terminology that will help you understand the components of an Oracle WebLogic Server 12c domain, a collection of Oracle WebLogic Server instances and related resources and services that are managed together as a single unit.

Oracle WebLogic Server 12c Product Set

Oracle WebLogic Server 12c is a component of Oracle Fusion Middleware 12c, which consists of several Oracle products that span business intelligence, collaboration tools, content management, and integration services. The underlying application server supporting these middleware applications is Oracle WebLogic Server 12c. Products such as Oracle SOA Suite and Oracle Fusion applications rely on Oracle WebLogic Server 12c to run their code.

Oracle offers three distinct products as part of the Oracle WebLogic Server 12c application family:

■■ Oracle WebLogic Server Standard Edition (SE)

■■ Oracle WebLogic Server Enterprise Edition (EE)

■■ Oracle WebLogic Suite

Oracle WebLogic Server Standard Edition

The Oracle WebLogic Server Standard Edition (SE) is a full-featured application server, targeted for developers to aid in getting enterprise applications up and running quickly. Oracle WebLogic Server SE implements all the Java EE standards and offers management capabilities through the Administration Console.

Chapter 1:  Installing Oracle WebLogic Server 12c and Using the Management Tools  3

Oracle WebLogic Server Enterprise Edition

Oracle WebLogic Server EE is the core application server designed for mission-critical applications that require high availability and advanced diagnostic capabilities. The EE version contains all the features of the SE version, of course, but in addition supports clustering of servers for high availability and the ability to manage multiple domains, plus various diagnostic tools.

Oracle WebLogic Suite

Oracle WebLogic Suite integrates the core WebLogic Server application server within the Oracle WebLogic Suite Java Infrastructure. The Oracle WebLogic Suite offers support for dynamic scale- out applications with features such as in-memory data grid technology and comprehensive management capabilities. It consists of the following components:

■■ Oracle WebLogic Server EE

■■ Oracle Coherence (provides in-memory caching) ■■ Oracle Top Link (provides persistence functionality)

This book deals exclusively with the Oracle WebLogic Server EE 12c product. (I refer to it simply as WebLogic Server in the rest of the book.) You manage WebLogic Server essentially the same way regardless of the operating system it is running on. This book uses examples run on a Windows installation of WebLogic Server; however, where necessary or relevant, certain tasks or commands are also shown for UNIX/Linux-based systems.

Note

WebLogic Server uses a configured pool of JDBC connections to interact with databases. You can use any RDBMS that supports a JDBC 2.0–compliant driver. This includes Oracle, IBM DB2, Microsoft SQL Server, MySQL, and other databases. The WebLogic Server installation includes an embedded database called Apache Derby. (Previously, Oracle shipped a different database by the name of PointBase.)

Terminology

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 (to be explained in the following section), one instance serves as the Administration Server, which is your primary means of managing the domain. The rest of the WebLogic Server instances in a domain 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.

4   Oracle WebLogic Server 12c Administration Handbook

WebLogic Server Domain

A domain is a set of WebLogic Server instances (managed servers) 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.

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 the physical network makes it easy to configure and manage complex, geographically dispersed WebLogic Server deployments. A domain lets you simultaneously deploy applications across multiple WebLogic Server instances located on heterogeneous servers and various networks, with different physical and network descriptions. Administering a domain makes it possible 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. As mentioned earlier, a domain can just consist of 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 Administration (or 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

Chapter 1:  Installing Oracle WebLogic Server 12c and Using the Management Tools  5

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 because 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 upon startup, to get its configuration and deployment settings. For this reason, you should always start the Admin Server before you start a Managed Server. Once a Managed Server starts running, it operates completely independently from the Admin Server.

Although you can deploy a Java EE 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. On startup, a Managed Server contacts the Admin Server to retrieve any configuration changes since the Managed Server was last shut down. A Managed Server can continue to run, however, and it’s even possible to start it in the absence of an Admin Server. Chapter 2 shows how you can start a Managed Server without a running Admin Server, in the special Managed Server Independence (MSI) mode. The MSI mode is enabled by default, and it allows the Managed Server to start using its locally cached configuration without having to contact the Admin Server for this information.

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 isn’t 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.

6   Oracle WebLogic Server 12c Administration Handbook

Note

The simplest domain will consist of just one server—the Admin Server. In a development environment, you can sometimes get by with such a simple setup and host all applications directly on the Admin Server without using a Managed Server or a cluster comprising several Managed Servers.

A WebLogic Server domain can consist of multiple Managed Servers that either are or are not 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, including 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 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, so your users won’t have to experience service disruptions. Each WebLogic 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, like a JDBC connection pool, aren’t shared across domains—each WebLogic domain must create its own set of resources. This requirement applies when dealing with clusters as well, which are treated as domain resources. 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? Once you satisfy 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, a cluster’s member 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.

It’s sometimes easy to get confused as to how a cluster relates to a domain. Just remember that a domain is simply a set of WebLogic Server instances, some of which may be clustered and some not, and that a domain can contain multiple clusters.

Coherence Cluster

A domain may also include Coherence Clusters, which are groups of cluster nodes that share a group address to facilitate communication among the nodes. In addition, a WebLogic Server domain may also include a Managed Coherence Cluster, which is any WebLogic Managed Server assigned to a Coherence Cluster.

Chapter 1:  Installing Oracle WebLogic Server 12c and Using the Management Tools  7

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 Manager is actually a key requirement for configuring automatic server migration in a cluster following a server failure, as explained in Chapter 7. In Chapter 2, I explain how you can use Node Manager and the WebLogic Scripting Tool (WLST) together to perform various administrative tasks.

Virtual Host

A virtual host relies 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 Manager

A Work Manager helps 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 a Work Manager at the domain level (using a global Work Manager) or at the application or module level.

8   Oracle WebLogic Server 12c Administration Handbook

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.

Tip

You can create Jolt Connection Pools to enable your applications to connect to Oracle Tuxedo domains. Jolt clients will then manage requests from your applications to the Oracle Tuxedo Services.

Deployment

When you want to make a Java EE application or a stand-alone application module available to users, you must first install those applications and modules in a WebLogic domain. Once you install the applications and modules, you must start those so the applications can begin processing user requests. Deployment is the process of installing the applications or modules and starting them so they are available to clients. Developers package applications for delivery to administrators, who then deploy the applications to WebLogic Server instances or clusters. Chapter 8 shows the various ways in which you can deploy applications to development and production environments by using the Administration Console, WLST, and the weblogic.Deployer utility.

Note

Oracle WebLogic Server 12c fully supports Oracle Real Application Clusters (RAC). Chapter 4 shows you how to configure data sources to connect to Oracle RAC database services.

Security Realm

You use security realms to protect WebLogic Server resources. A security realm is simply a logical container for your users, groups, roles, security policies, and security providers. It’s the security realm that authenticates users and determines which resources they can access. WebLogic Server uses a default security realm named myrealm. In the default security realm, the Admin Server stores the domain security data in an LDAP server, but you can also choose an RDBMS store for this instead. The Managed Servers replicate this LDAP server, and when the Admin Server fails, it can use their copy of the LDAP server for providing security services to the deployed applications.

When you create a domain, the username/password credentials you provide are used by the Configuration Wizard to seed the security realm myrealm. The username you provide will be the initial administrative user in myrealm. When you start WebLogic Server, it uses the default security realm to authenticate usernames. You can configure the server to use other security realms, but you must always specify one of them as the default security realm.

If these simple definitions of the key WebLogic Server terminology don’t satisfy your curiosity, not to worry—subsequent chapters discuss all these entities in great detail!

Chapter 1:  Installing Oracle WebLogic Server 12c and Using the Management Tools  9

Important WebLogic Server Concepts

In order to fully comprehend how WebLogic Server works and to get the best performance out of it, it’s important to understand several concepts. The most significant concepts are discussed in the following section.

Execute Threads and Queues

Understanding the internal architecture of Oracle WebLogic Server is important, particularly in terms of knowing how the server performs its work of satisfying user requests. When a client sends a request to WebLogic Server, the actual work to satisfy that request is performed by a Java thread called an execute thread. A user can submit work to WebLogic Server using an HTTP- based request to the servlet engine or a request for Remote Method Invocation (RMI) access to objects such as Enterprise JavaBeans (EJBs). When a server process starts, it binds itself to a port and assigns a listen thread to the port to listen for incoming requests. Once the request makes a connection, the server passes control of that connection to the socket muxer. The socket muxer reads requests off the socket and places the work requests into the self-tuning execute queue as they arrive. An idle execute thread will pick up a request from the execute queue and may, in turn, hand off the job of responding to those requests to special threads. The execute thread executes the requests and returns the responses.

Oracle WebLogic Server uses socket muxers, which are software modules, to read incoming requests on the server. Muxers read messages from the network, bundle them into a package of work, and queue them to the Work Manager, which then finds a thread on which to execute the work and makes sure the response gets back to the same socket from which the request came.

There are two types of muxers—a Java muxer and a native muxer. A Java muxer uses pure Java to read data from the sockets, whereas the native muxers use platform-specific native binaries. By default, Oracle WebLogic Server uses the native muxer. This means that the Enable Native IOP parameter for the server is set to the value SELECTED. Note that with a native muxer, the server creates a fixed number of threads to read incoming requests, whereas with a Java muxer you can configure the number of threads in the Administration Console by modifying the Percent Socket Readers parameter. The native muxer allocates a certain percentage of the server threads to act as socket reader threads, which perform the pooling function, while the rest of the server threads are busy processing client requests. In general, you need to be careful about changing the number of socket reader threads. In many cases, the best optimization is to set it to 1.

You can tell if you’re using a native muxer or a Java muxer by looking at the messages that

involve the execute thread. If you’re using the native muxer, the server error messages will refer to it as weblogic.socket.EPollSocketMuxer, whereas if you’re using the Java muxer, you’ll see weblogic.socket.SocketMuxer instead. Note that the EPollSockerMuxer is associated only with a JRockit JVM operating on a Linux server. You’ll see the word poll in the case of a native muxer because it uses a polling mechanism to query a socket for data. Native muxers are seen as providing superior performance, especially when scaling up to large user bases, because they implement a nonblocking thread model. When administering WebLogic Server instances, you’ll frequently encounter the so-called stuck thread situation, which occurs when a thread isn’t returned to the thread pool within the timeframe you set for it (the default is 10 minutes). Resolution of stuck threads is a key component of WebLogic Server troubleshooting, and you’ll notice that Oracle Support often asks for several server thread dumps when you open a service request. Chapter 6 shows you how to take a thread dump and analyze many performance issues on your own by identifying the resource contention leading to the stuck thread situation.