D80153GC30 sg2

Oracle Internal & Oracle Academy Use Only
Oracle WebLogic Server 12c:

Administration II
Student Guide – Volume II

D80153GC30 | D108226
Learn more from Oracle University at education.oracle.com

Authors Copyright © 2020, Oracle and/or its affiliates. All rights reserved.
Al Saganich Disclaimer
Tom Eliason This document contains proprietary information and is protected by copyright and
Serge Moiseev other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered
Mark Lindros in any way. Except where your use constitutes "fair use" under copyright law, you
may not use, share, download, upload, copy, print, display, perform, reproduce,
TJ Palazzolo publish, license, post, transmit, or distribute this document in whole or in part without
the express authorization of Oracle.
Technical Contributors The information contained in this document is subject to change without notice. If you
and Reviewers find any problems in the document, please report them in writing to: Oracle University,
500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
Joe Greenwald warranted to be error-free.
Bill Bell
Restricted Rights Notice
Elio Bonazzi
Tom McGinn If this documentation is delivered to the United States Government or anyone using
the documentation on behalf of the United States Government, the following notice is

Eduardo Moranchel Rosales applicable:
Will Lyons
U.S. GOVERNMENT RIGHTS
David Cabelus The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Greg Stachnick license agreement and/or the applicable U.S. Government contract.
Donna Micozzi
Trademark Notice
Jon Patt
Matthew Slingsby Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Bill Albert
Rich Whalen
Kevin Tate
Serge Moiseev
Takyiu Liu
Angelika Krupp
Viktor Tchemodanov
Diganta
Choudhury
Jose Alvarez
Alexander Ryndin
Publishers
Pavithran Adka
Srividya Rameshkumar
Veena Narasimhan
3003062020
Contents
1 Course Introduction
Course Objectives 1-2
Target Audience 1-4
Course Prerequisites 1-5
Introductions and Setting Expectations 1-6
Course Schedule 1-7

Course Practices 1-10
Classroom Guidelines 1-11
For More Information 1-12
Related Training 1-13
2 WebLogic Server Review

Objectives 2-2
Agenda 2-3
Oracle WebLogic Server: Overview 2-4
WebLogic Server Domain 2-6
Administration Server 2-7
Managed Servers 2-8
Machines and Clusters 2-9
WebLogic Server Application Services 2-10
WebLogic Server Application: Example 2-11
Agenda 2-12
Start Scripts 2-13
Node Manager 2-14
WebLogic Tools: Administration Console 2-15
WebLogic Tools: WebLogic Scripting Tool (WLST) 2-16
Deployment 2-17
Summary 2-18
3 Upgrading WebLogic Server

Objectives 3-2
Agenda 3-3
Definition of Upgrade 3-4
Patch 3-5
Minor Upgrade 3-6
iii
Major Upgrade 3-7
Quiz 3-8
Agenda 3-9
What Is a Rolling Upgrade? 3-10
Multiple Installation and Domain Locations 3-11
Leverage WebLogic Clusters to Avoid Down Time 3-12
Quiz 3-13
Agenda 3-14
Rolling Upgrade Process: Overview 3-15
Backup 3-16
Shutdown 3-17

Upgrade 3-18
Restart 3-19
Quiz 3-20
Summary 3-21
Practice 3-1 Overview: Setting Up the Course Practice Environment 3-22
Practice 3-2 Overview: Performing a Rolling Upgrade 3-23
4 Creating and Using Domain Templates

Objectives 4-2
Agenda 4-3
Domain Template Review 4-4
Agenda 4-5
Template Contents 4-6
Template Exclusions 4-7
Script Replacement Variables 4-8
Agenda 4-9
Extension Template: Concepts 4-10
Agenda 4-11
Fusion Middleware (FMW) Templates 4-12
Quiz 4-13
Agenda 4-15
Why Use Custom Templates 4-16
Template Builder 4-17
Creating a Domain Template 4-18
Selecting the Template Domain Source 4-19
Configuring Applications in a Template 4-20
Examining Template Topology 4-21
Adding Files to the Template 4-22
Preparing Scripts and Files with Variables 4-23
Review Configuration and Create Template 4-24
iv
SQL Scripts and LDAP Data 4-25
Creating Windows Start Menu Entries 4-26
Creating an Extension Template 4-27
Using a Custom Template with the Configuration Wizard 4-29
Post Domain Creation Tasks 4-35
Using a Custom Extension Template with the Configuration Wizard 4-36
Summary 4-38
Practice 4-1 Overview: Creating and Using a Custom Domain Template 4-39
5 WebLogic Server Startup and Crash Recovery

Objectives 5-2

Agenda 5-3
Node Manager Architecture 5-4
Node Manager Default Behavior 5-5
Configure Java-Based Node Manager 5-6
Agenda 5-7
Starting the Node Manager at System Startup 5-8
Configuring the Node Manager as a Windows Service 5-9
Configuring the Node Manager on UNIX Systems 5-10
Configuring the Node Manager as an inetd Service 5-11
Registering and Managing inetd Services 5-14
Configuring the Node Manager as an xinetd Service 5-15
Agenda 5-17
How the Node Manager Restarts an Administration Server 5-18
How the Node Manager Restarts a Managed Server 5-19
RestartInterval and RestartMax 5-20
Crash Recovery 5-21
CrashRecoveryEnabled 5-22
Quiz 5-23
Summary 5-24
Practice 5-1 Overview: Configuring Automatic Start and Restart of a System 5-25
Solaris Specific Configuration 5-26
Solaris 5-27
Example SMF Manifest File 5-28
Set Up and Start Node Manager with SMF 5-31
6 WebLogic Scripting Tool (WLST)

Objectives 6-2
Agenda 6-3
WebLogic Scripting Tool (WLST) 6-4
Agenda 6-5
v
Jython 6-6
Using Jython 6-7
Variable Declaration 6-8
Conditional Expressions 6-9
Loop Expressions 6-10
I/O Commands 6-11
Exception Handling 6-12
Quiz 6-13
Agenda 6-14
WLST Modes 6-15
WLST Example 6-16

Running WLST Scripts 6-17
WLST Development Tools 6-18
configToScript() 6-19
Script Recording Using the Administration Console 6-20
Oracle Enterprise Pack for Eclipse 6-22
WLST Command Tips 6-23
General WLST Commands 6-24
Offline WLST Commands 6-25
Online WLST Commands 6-26
Quiz 6-27
Agenda 6-28
WebLogic JMX Overview 6-29
Configuration MBeans 6-30
Runtime MBeans 6-31
WebLogic Server MBean Examples 6-32
MBean Properties in the Administration Console 6-33
Browsing MBean Documentation 6-34
Referencing MBeans in WLST 6-36
Quiz 6-37
Agenda 6-38
Creating a Template and a Domain 6-39
Connecting to a Server 6-40
Password Management 6-41
WLST Variables 6-42
Password Management 6-43
Configuring a Server 6-44
Monitoring a Server 6-45
Adding a Server to a Cluster 6-46
Creating a Data Source 6-47
Monitoring a Data Source 6-49
vi
Creating an LDAP Authentication Provider 6-50
Modifying a Domain Offline 6-51
Deploying an Application 6-52
Creating a Dynamic Cluster 6-53
Scaling Up a Dynamic Cluster 6-55
Dynamic Cluster Scaling 6-56
Scaling Down a Dynamic Cluster 6-57
Script Interceptors 6-58
Quiz 6-60
Agenda 6-61
Some FMW Commands 6-62

Summary 6-63
Practice 6-1 Overview: Creating and Modifying a Domain with WLST 6-64
Practice 6-2 Overview: Monitoring a Domain with WLST 6-65
7 RESTFul Management Services

Objectives 7-2
Agenda 7-3
What Is REST? 7-4
WebLogic Server and REST 7-5
What Can Be Monitored Using WebLogic REST? 7-6
Clients and WebLogic REST 7-7
Enabling REST Management 7-8
Supported Representations 7-9
REST Resource Access Roles 7-10
Agenda 7-11
WebLogic RESTFul Interfaces 7-12
REST Operations Flow 7-13
Example: Returning Server Information Using cURL 7-14
Typical REST Operations 7-15
Common WebLogic REST Results 7-16
WebLogic REST Error Handling 7-18
Understanding WebLogic REST Requests 7-19
WebLogic REST MBean Hierarchy 7-20
WebLogic Legacy REST Resources 7-21
WebLogic REST Response Bodies 7-22
Example: Listing Server Information by Name 7-23
Invoking Operations 7-24
Create Forms 7-25
Creating Resources 7-27
Agenda 7-28
vii
Common Workflows Modify a Configuration Using an Edit 7-29
Common Workflows Deploy/View/Undeploy an Application 7-30
Common Workflows Start/View/Stop Servers 7-31
Common Workflows Monitor Servers 7-32
Summary 7-33
Quiz 7-34
Practice 7-1 Overview: Creating and Managing Servers Using REST 7-35
8 Secure Sockets Layer (SSL)

Objectives 8-2
Agenda 8-3

What Is SSL? 8-4
SSL Terminology 8-5
Symmetric Encryption and Decryption 8-6
Asymmetric Encryption and Decryption 8-7
Digital Certificates 8-8
Digital Certificate: Example 8-9
Certificate Authorities 8-10
SSL Communication 8-11
One-Way SSL Handshake 8-12
Two-Way SSL Handshake 8-13
Quiz 8-14
Agenda 8-16
WebLogic and SSL 8-17
Demo Certificates 8-18
WebLogic SSL Requirements 8-19
WebLogic SSL Connections 8-20
Agenda 8-21
What Is a Keystore? 8-22
keytool Utility 8-23
Working with a Keystore 8-24
Configuring WebLogic Keystores 8-26
Quiz 8-27
Agenda 8-28
Configuring SSL for WebLogic 8-29
SSL and WebLogic Proxy Plug-Ins 8-30
SSL and Oracle HTTP Server 8-31
SSL and Hardware Load Balancers 8-32
Quiz 8-33
Summary 8-34
Practice 8-1 Overview: Setting Up SSL 8-35
viii
9 Application Work Managers
Objectives 9-2
Agenda 9-3
WebLogic Server Threads 9-4
Monitoring a Server Thread Pool 9-5
Monitoring Server Threads 9-6
Stuck Thread Handling 9-7
Configuring Stuck Thread Handling 9-8
Application Stuck Thread Handling 9-9
Quiz 9-10
Agenda 9-11

Work Managers 9-12
Work Manager Scope 9-13
Work Manager Architecture 9-14
Quiz 9-15
Agenda 9-16
Request Classes 9-17
Creating a Work Manager 9-18
Creating a Request Class 9-19
Constraints 9-20
Creating a Constraint 9-21
Work Manager WLST Example 9-22
Work Managers and Stuck Threads 9-23
Assigning Work Managers to Applications 9-24
Quiz 9-25
Summary 9-26
Practice 9-1 Overview: Creating and Using Work Managers 9-27
10 Working with the Security Realm

Objectives 10-2
Agenda 10-3
Security Realm: Review 10-4
Default Security Configuration 10-5
Agenda 10-6
How WebLogic Resources Are Protected 10-7
Examples of WebLogic Resources to Protect 10-8
Users and Groups 10-9
Group Membership 10-10
Roles 10-11
Policies 10-12
Configuring New Users 10-13
ix
Configuring New Groups 10-14
Configuring Group Memberships 10-15
Configuring New Roles 10-16
What Is Role Mapping? 10-17
Configuring Role Mapping 10-18
Configuring Roles Using WLST 10-19
Configuring New Policies 10-20
Configuring Policies Using WLST 10-21
Security Configuration Sources 10-22
Configuring Sources Using WLST and weblogic.Deployer 10-23
Deployment Descriptor Security Example: weblogic.xml 10-24

Deployment Descriptor Security Example: web.xml 10-25
Embedded LDAP Server 10-26
Configuring the Embedded LDAP Server 10-27
Quiz 10-29
Practice 10-1 Overview: Creating Users, Groups, Roles, and Policies 10-30
Agenda 10-31
Auditing 10-32
Sample Auditing Output 10-33
Security Audit Events 10-34
WebLogic Auditing Architecture 10-35
Custom Versus Default Auditing Provider 10-36
Creating the Default Auditing Provider 10-37
Configuring the Default Auditing Provider 10-38
Configuration Auditing 10-40
Quiz 10-42
Summary 10-43
Practice 10-2 Overview: Configuring WebLogic Auditing 10-44
11 Disaster Recovery and Migration

Objectives 11-2
Agenda 11-3
Disaster Recovery Concepts 11-4
Site Symmetry 11-6
Recommended Architecture 11-7
General Best Practices 11-8
Hosts File: Example 11-9
Quiz 11-10
Agenda 11-11
Administration Server Review 11-12
Impact of Administration Server Failure 11-13
x
Backing Up a Domain Configuration 11-14
Recovery of the Administration Server Configuration 11-15
Restarting an Administration Server on a New Computer 11-16
Quiz 11-17
Agenda 11-18
Java Transaction API (JTA) Review 11-19
What Is Service Migration? 11-20
Service Migration Prerequisites 11-21
Service Migration Architecture: Database Leasing 11-22
Service Migration Architecture: Consensus Leasing 11-23
What Is a Migratable Target? 11-24

Service Migration Policy Options 11-25
Configuration Roadmap 11-26
JTA Service Migration: Before Failure 11-27
JTA Service Migration: After Failure 11-28
Configuring JTA Service Migration 11-29
Set Up Automatic JTA Service-Level Migration 11-30
Quiz 11-31
Practice 11-1 Overview: Configuring JTA Service-Level Migration 11-34
Agenda 11-35
Pinned Services 11-36
Pinned Services High Availability (HA) Challenges 11-37
High Availability Options for Pinned Services Clusters 11-38
Whole-Server Migration 11-39
Automatic Server Migration Architecture: No Failure 11-40
Automatic Server Migration Architecture: Machine Failure 11-41
Configuration: Overview 11-42
Quiz 11-43
Summary 11-44
12 Managing Data Sources

Objectives 12-2
Agenda 12-3
Review: JDBC 12-4
Data Source: Review 12-5
XA Data Source Review 12-6
Agenda 12-7
Why Manage a Data Source? 12-8
Suspend a Data Source 12-9
Resume a Data Source 12-10
Data Source Interceptors 12-11
xi
Data Source Interceptor 12-12
Practice 12-1 Overview: Controlling a Data Source 12-13
Agenda 12-14
Oracle Real Application Clusters (RAC): Overview 12-15
Oracle GridLink for RAC 12-16
Agenda 12-17
Multi Data Sources 12-18
Multi Data Source Architecture 12-19
Comparison of GridLink and Multi Data Sources 12-20
Failover Option 12-21
Load Balancing Option 12-22

Quiz 12-23
Agenda 12-24
Connection Testing 12-25
Agenda 12-26
Proxy Data Sources 12-27
Creating a Proxy Data Source 12-28
Monitoring Proxy Data Source JDBC Resources 12-30
Agenda 12-31
Creating a Multi Data Source 12-32
Configuring a Multi Data Source 12-34
Multi Data Source WLST Example 12-35
Managing Multi Data Source Members 12-36
Quiz 12-37
Summary 12-39
Practice 12-2 Overview (Optional): Creating and Using a Multi Data Source 12-40
Practice 12-3 Overview (Optional): Creating and Using Proxy Data Sources 12-41
13 Diagnostic Framework
Objectives 13-2
Agenda 13-3
WebLogic Diagnostics Framework (WLDF) 13-4
WLDF Architecture 13-5
Diagnostic Archives 13-6
Configuring Server Diagnostic Archives 13-7
Diagnostic Modules 13-8
Dynamic Diagnostic Modules 13-10
Resource Descriptors 13-11
Creating a Diagnostic Module 13-12
WLST: Example 13-13
WLST Commands for WLDF 13-14
xii
Quiz 13-15
Agenda 13-16
What Is a Diagnostic Image? 13-17
Capturing a Server Diagnostic Image 13-18
WLST: Example 13-19
Quiz 13-20
Agenda 13-21
What Is a Harvester? 13-22
Metric Collectors 13-23
Configuring a Metric Collector 13-24
WLST: Example 13-25

Quiz 13-26
Agenda 13-27
Policies and Actions 13-28
Policy Types 13-30
Configuring Policies 13-31
Configuring Actions 13-33
Elastic Actions and Scaling 13-36
Scale Up Action 13-37
Scale Down Action 13-38
Quiz 13-39
Summary 13-40
Practice 13-1 Overview: Using a Built-in Diagnostic Module 13-41
14 WebLogic and Coherence Integration

Objectives 14-2
Agenda 14-3
Oracle Coherence: Overview 14-4
Agenda 14-6
Types of Session Persistence 14-7
Coherence*Web 14-8
Coherence*Web and WebLogic Clusters 14-9
Coherence*Web Session Failover 14-10
Configuring Coherence*Web in WebLogic 14-11
Quiz 14-12
Practice 14-1 Overview: Configuring Coherence*Web 14-13
Agenda 14-14
Coherence and WebLogic Server 14-15
WebLogic Managed Coherence Servers Operations 14-16
What Is a Grid Archive (GAR)? 14-17
Coherence Application Deployment on WebLogic 14-18
xiii
Coherence Container: Benefits 14-19
Coherence Cluster 14-20
Managed Coherence Server 14-21
Quiz 14-22
Summary 14-23
Practice 14-2 Overview: Configuring Managed Coherence Servers 14-24
15 Application Staging and Deployment Plans

Objectives 15-2
Agenda 15-3
Review: Java EE Applications 15-4

Review: Deployment 15-5
Agenda 15-6
Server Staging Modes 15-7
Staged Mode Example 15-8
No Stage Mode Example 15-9
External Stage Mode Example 15-10
Configuring the Staging Mode 15-11
Quiz 15-12
Agenda 15-13
Development to Test to Production 15-14
Examples of Deployment Descriptor Values That Can Change 15-15
Agenda 15-16
Java EE Deployment Descriptors 15-17
Annotations 15-18
appmerge and appc 15-19
Managing Precedence 15-20
Quiz 15-21
Agenda 15-22
What Is a Deployment Plan? 15-23
Using Deployment Plans for Different Environments 15-24
Deployment Plan Example 15-26
Staging Deployment Plans 15-29
Quiz 15-30
Agenda 15-31
Creating a Deployment Plan 15-32
Creating a New Deployment Plan 15-33
Using the Administration Console to Generate a Deployment Plan 15-34
Modifying and Saving Data to Create a New Plan 15-35
New Deployment Plan Shows Changed Values 15-36
Using an Existing Deployment Plan to Configure an Application 15-37
xiv
Using an Existing Deployment Plan 15-38
WLST createPlan 15-39
weblogic.PlanGenerator 15-40
Using Plan Generator 15-41
Oracle Enterprise Pack for Eclipse 15-42
Managing Deployment Plans 15-46
Summary 15-47
Practice 15-1 Overview: Creating and Using a Deployment Plan 15-48
16 WebLogic, Docker, and Kubernetes

Objectives 16-2

Agenda 16-3
Traditional System Architecture 16-4
History and Multi-Dimensional Evolution of Computing 16-5
Container Use Case: Ready to Run Application Stack 16-6
Container Use Cases: Microservices and One-Time Jobs 16-7
Container Use Cases: Automation and Consolidation 16-8
Virtual Machines Versus Containers 16 -9
Agenda 16-10
Docker Architecture and Terminology 16-11
Docker Images 16-12
Docker Hub 16-13
Why Docker Is Popular? 16-14
Agenda 16-15
Kubernetes: What Is It? 16-16
Why Kubernetes? 16-17
Basic Principles 16-18
Applications in Kubernetes 16-19
Deployments and Pods 16-20
Accessing Applications in Kubernetes 16-21
Other Kubernetes Terminology 16-22
K8s Dashboard and Kubectl Output Examples 16-23
Agenda 16-24
Docker WebLogic Domain Image and Configuration Overrides 16-25
Domain Introspection and Config Override Generation 16-26
Supported User Configuration Overrides 16-27
Unsupported User Configuration Overrides 16-28
Configuration Overrides 16-29
WebLogic Operator Lifecycle Management 16-30
WebLogic Lifecycle Management 16-31
Oracle Fusion Middleware Images 16-32
xv
Agenda 16-33
Oracle Linux Container Services 16-34
Host Resource Requirements 16-35
Time Synchronization and Request Forwarding for Kubernetes 16-36
Kubernetes Port Use 16 -37
Docker Container Registry 16-38
Oracle Registry Mirror Servers 16-39
Using Private Docker Registry 16-40
Local Container Registry 16-41
Consider Using minikube Tool 16-42
Summary 16-43

A Production Redeployment
Objectives A-2
Agenda A-3
HTTP Sessions and Redeployment A-4
Agenda A-5
Redeployment Strategies A-6
Agenda A-7
Application Availability A-8
What Is Production Redeployment? A-9
Advantages of Production Redeployment A-11
Production Redeployment Process A-12
Application Retirement A-13
Review: Administration Channel A-14
Administration Mode A-15
Distributing a Versioned Application A-16
Deploying in Administration Mode A-17
Rolling Back to the Previous Version A-18
Quiz A-19
Agenda A-21
Redeployment Process: Overview A-22
Configuring Application Deployment Versioning A-23
Deploying a New Version of an Application A-25
Distributing and Starting a Versioned Application in Administration Mode A-29
Transitioning a Versioned Application from Administration Mode to Active A-32
Rolling Back a Versioned Application to a Previous Version A-34
Quiz A-35
Agenda A-36
Requirements and Restrictions A-37
xvi
Summary A-38
[Optional] Practice Appendix A-1 Overview: Using Production Redeployment A-39
B WebLogic Optimizations for Exalogic

What Is Exalogic? B-2
What Is InfiniBand? B-4
Exalogic Networks B-5
Exalogic Machine Topology B-6
InfiniBand Networking Concepts B-7
Default Compute Node Network B-8
Recommended FMW Topology on Exalogic B-9

Exalogic Shared Storage Concepts B-10
Recommended FMW Storage on Exalogic B-11
WebLogic Server Optimizations: Overview B-12
Creating a Cluster Replication Channel B-13
Using SDP for Replication B-14
Using Multiple Ports for Replication B-15
Other Replication Optimizations B-16
Oracle Exabus B-17
Other WebLogic Optimizations B-18
Enabling Other Optimizations B-19
What Is Exadata? B-20
Exadata InfiniBand Connectivity B-21
Enabling SDP for Exadata Connectivity B-22
C Oracle Cloud
Agenda C-2
What Is Cloud? C-3
What Is Cloud Computing? C-4
History – Cloud Evolution C-5
Components of Cloud Computing C-6
Characteristics of Cloud C-7
Cloud Deployment Models C-8
Cloud Service Models C-9
Industry Shifting from On-Premises to the Cloud C-13
Oracle IaaS Overview C-15
Oracle PaaS Overview C-16
Oracle SaaS Overview C-17
Summary C-18
xvii
D Oracle Java Cloud Service Overview
Objectives D-2
Introducing Java Cloud Service Your platform for running business applications in
the cloud D-3
Java Cloud Service: Three Options D-4
Java Cloud Service Main Use Cases D-5
Java Cloud Service Feature: Provisioning D-6
Java Cloud Service Feature: Patching D-7
Java Cloud Service Feature: Backup / Restore D-8
Java Cloud Service Feature: Scaling D-9
Oracle Coherence Option: Data Caching & Scaling D-10

Oracle Coherence Option: Your Cloud Data Grid Scalable, fault-tolerant cloud
infrastructure D-11
How You Interact with Java Cloud Service D-12
Speaking of Dev Environments… Developer Cloud Service D-13
Java Cloud Service On-Premises! D-14
Summary D-15
xviii
11
Disaster Recovery and Migration

Copyright © 2020, Oracle and/or its affiliates. All rights reserved.
Objectives
After completing this lesson, you should be able to:

• Describe disaster recovery scenarios for WebLogic Server
• Create a backup administration server
• Configure service-level transaction migration
• Describe whole server migration for WebLogic Server

Oracle WebLogic Server 12c: Administration II 11 - 2

Agenda
• Disaster Recovery (DR)

– DR Concepts
– Recommended DR Architecture
– DR Best Practices
• Backup the Administration Server
• Service-Level Migration
• Whole Server Migration Overview


Disaster Recovery Concepts
• Disaster recovery:
– Ensures application availability after the loss of an entire data center
– Addresses catastrophic failures, such as natural disasters
– May or may not guarantee zero down time during the recovery process
• A common disaster recovery implementation involves deploying multiple data center
sites in an active/passive fashion:
– The production (active) site handles all application traffic.
– The standby (passive) site is used only in the event of a disaster.

Enterprise deployments need protection from unforeseen disasters and natural calamities. One protection
solution involves setting up a standby site at a geographically different location from the production site. The
standby site may have equal or fewer services and resources compared to the production site. Application
data, metadata, configuration data, and security data are replicated to the standby site on a periodic basis.
The standby site is normally in passive mode; it is started when the production site is not available. This
deployment model is sometimes referred to as an active/passive model. This model is normally adopted
when the two sites are connected over a WAN and network latency does not allow clustering across the two
sites.

Disaster Recovery Concepts
Global Load
Balancer
Production
Load Balancer
Standby Load
Balancer
Synchronize

Production Site Standby Site
Clients access the production site during normal operation. During disaster recovery, clients access the
standby site. Ideally, this change should be seamless from the client’s perspective, although practically
there may be a very brief interruption in service, depending on the implementation details.
For disaster recovery to be effective, the production and standby sites must be synchronized to some
degree. At a very minimum, a version of the same application must be deployed to both sites.

Site Symmetry
Oracle recommends symmetric configurations, because they:

• Require less setup and testing
• Ensure adequate performance
Standby Type Description
Symmetric Both the topology and hardware are identical to the production site.
Partially Symmetric The topology is the same as the production site, but the hardware is different
(configurations with a different number of machines, for example).

Asymmetric The topology is different from the production site (number of tiers, servers,
databases, and so on).
A disaster recovery configuration that is completely identical across tiers on the production site and standby
site is called a symmetric site. A site can be completely symmetric or partially symmetric. In a completely
symmetric site, the production site and standby site are identical in all respects. That is, they have identical
hardware, operating systems, load balancers, middleware instances, applications, and databases. The
same port numbers are used for both sites as well.
In a partially symmetric site, the production site and standby site are identical in topology, but not in
hardware. That is, they have the same number of middleware instances, applications, and databases on
each site, but the hardware or operating system is not identical. For example, you can have ten machines
on the production site and eight machines on the standby site. It is recommended but not required to have
identical hardware and operating systems on the production and standby sites when planning a disaster
recovery site.
In an asymmetric topology, the standby site has fewer resources than the production site. Typically, the
standby site in an asymmetric topology has fewer hosts, load balancers, Fusion Middleware instances, and
applications than the production site. It is important to ensure that an asymmetric standby site has sufficient
resources to provide adequate performance when it assumes the production role. Otherwise, it may become
oversaturated and unavailable.

Recommended Architecture
Production Standby
Corporate WAN
(Ethernet)
Fusion
Middleware
Tier
Network
Storage Replication

Oracle Data Guard
Network
Database
Tier
Oracle’s recommended disaster recovery strategy facilitates data protection in two main ways. You should
replicate the storage of one system to the other to protect the middleware product binaries, configurations,
metadata files, and application data that reside on the file system. Oracle Data Guard protects the Oracle
database, which may or may not be running on Exadata machines. This database contains Oracle Fusion
Middleware Repository data, as well as customer data.
Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or
more standby databases to enable production Oracle databases to survive disasters and data corruptions. It
maintains these standby databases as copies of the production database. Then, if the production database
becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby
database to the production role, minimizing the down time associated with the outage. Data Guard can be
used with traditional backup, restoration, and cluster techniques to provide a high level of data protection
and data availability.
Oracle Active Data Guard, an option built on the infrastructure of Data Guard, allows a physical standby
database to be open read-only while changes are applied to it from the primary database. Currently, Oracle
Fusion Middleware does not support configuring Oracle Active Data Guard for its database repositories.

General Best Practices
• Place all data on shared storage; only use compute node local storage for the OS.
• Bind to and use common host names instead of IP addresses.
• Use separate DNS servers and/or hosts files on each site.
• Replicate any external resources on which WebLogic processes depend (LDAP,
database, and so on).

In a disaster recovery topology, the host names used for wiring intra component and inter component
communication need to be same. Typically, the site where the Oracle Fusion Middleware installation is done
first dictates the host name used. The standby site instantiated subsequently should be configured to
resolve these host names to the local standby site IP addresses. Therefore, it is important to plan the host
names for the production site and standby site. It is also very important that the configuration at all levels
use only host names. When configuring each component, use host name–based configuration instead of IP-
based configuration, unless the component requires you to use IP-based configuration. For example, if you
are configuring the listen address of an Oracle Fusion Middleware component to a specific IP address such
as 192.168.10.33, use the host name wlsvhn1.mycompany.com, which resolves to 192.168.10.33.

Hosts File: Example
Production Site:
10.100.1.50 hradmin-prod.mycompany.com hradmin.mycompany.com

192.168.1.51 hrwls1-prod.mycompany.com hrwls1.mycompany.com
192.168.1.52 hrproxy1-prod.mycompany.com hrproxy1.mycompany.com
10.200.2.50 bakrepl.mycompany.com
Common host names
across both sites
Site-specific addresses
and host names
Standby Site:
10.200.1.150 hradmin-bak.mycompany.com hradmin.mycompany.com

192.168.1.151 hrwls1-bak.mycompany.com hrwls1.mycompany.com
192.168.1.152 hrproxy1-bak.mycompany.com hrproxy1.mycompany.com
10.100.2.50 prodrepl.mycompany.com
The other site's
storage appliance
In a disaster recovery topology, the production site host names must be resolvable to the IP addresses of
the corresponding peer systems at the standby site. This can be set up by creating a host name alias in the
/etc/host file (the second entry shown in the slide). Create host name aliases for all the hosts on the
production and standby sites. This example includes a WebLogic administration server, a WebLogic
managed server, and a proxy server. Also, add entries for the replication channel on each storage
appliance. The examples in this lesson assume that a symmetric disaster recovery site is being set up,
where the production site and standby site have the same number of hosts and servers. Each host at the
production site has a peer host at the standby site and the peer hosts are configured the same. For
example, hosts at one site use the same port numbers as their counterparts at the other site.

Quiz Q
A DR solution in which the production and standby sites have different topologies
is _________.
a. Symmetric
b. Asymmetric
c. Congruent
d. Incongruent

Answer: b

Agenda

• Back Up the Administration Server
– Administration Server Review
– Impact of Administration Server Failure
– Recovery of the Administration Server Configuration
– Restarting an Administration Server on a New Computer


Administration Server Review
• A domain must have exactly one instance of WebLogic Server acting as the
administration server. An administration server is part of exactly one domain.
• The administration server is:
– The central point through which you configure and manage all domain resources
– Solely in charge of the domain’s configuration. It distributes configuration changes to
other servers in the domain
– An instance of WebLogic Server and, therefore, a fully functional Java Enterprise
Edition application server

Domain A
Admin Server
All domains contain a special server called the administration server. You use the administration server to
configure and manage all the domain resources. Any other WebLogic Servers in the domain are called
managed servers.
In most domains, the applications are deployed to the managed servers. The administration server is used
only for domain configuration and management.
Because an administration server is an instance of WebLogic Server, it can perform any task of a Java
Enterprise Edition application server. Applications can be deployed and run on the administration server.
For simplicity, often a development-time domain will contain only the administration server. Developers
deploy and test their applications on the administration server.

Impact of Administration Server Failure
• Failure of the administration server:

– Prevents configuration changes in the domain
– Prevents application deployments
– Prevents starting newly configured managed servers
– Does not affect running managed servers
• Managed servers receive configuration and security updates from Admin server in real
time and synchronize at boot time.
• When the administration server becomes available, the managed servers get the latest
configuration data from the administration server.
•

Managed servers can be started in Managed Server Independence (MSI) mode.
When you first start a managed server, it must be able to connect to the administration server to retrieve a
copy of the configuration. Subsequently, you can start a managed server even if the administration server is
not running.
If a managed server cannot connect to the administration server during its start up, then it uses the locally
cached configuration information. A managed server that starts without synchronizing its configuration with
the administration server is running in Managed Server Independence (MSI) mode. By default, MSI mode is
enabled. However a managed server cannot start in MSI mode for the first time because the local
configuration is not available.
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 computer, other server instances on the same computer may be
similarly affected.
If an administration server becomes unavailable while the managed servers in the domain are running, then
those managed servers continue to run. Periodically, the managed servers attempt to reconnect to the
administration server. When the connection is successful, the configuration state is synchronized with that of
the administration server.
For clustered managed server instances, the load balancing and failover capabilities supported by the
domain configuration continue to remain available.

Backing Up a Domain Configuration
• Enable autobackup of configuration.

• Check the new JAR files and directories.

Disabled
by default
Under Domain > Configuration > General > Advanced, you can enable the automatic backup of the
configuration at the domain level. Each startup of the administration server creates two files in the domain
directory: config-booted.jar and config-original.jar. In addition, each saved change of the
configuration file makes a backup named configArchive/config-n.jar, where n is a sequential
number. The Archive Configuration Count attribute limits the number of retained configuration JARs, so that
in the example shown, there are never more than two kept: the most recent backup and the one immediately
before that. Older backups are automatically deleted. If you made a series of mistakes, this provides a very
easy way to return to a previous recent configuration. However, be aware that a typical configuration change
requires clicking the Activate Changes button a few times, and each one then cycles the stored JARs.
You may want to set a higher number such as 10 or 20 for the Archive Configuration Count depending on:
• The available disk space
• The need for backup and restoration
• The time taken for backup and restore activity
Note: Although you use the configuration backup feature, it is always a good practice to manually make a
backup of a known working configuration at an important milestone.

Recovery of the Administration Server Configuration
Managed Server Independence (MSI) reduces the urgency to fix the outage.
Enabled
by default

The administration server is required only for making changes to the active configuration; it is not required
for the normal operation of the managed servers as long as the managed servers are in Managed Server
Independence Enabled mode, which is the default. This allows you time to recover the administration server
without any service outages. As shown in the screenshot, the heartbeat detected between the
administration server and the managed servers is, by default, a one-minute period. After four minutes of not
hearing from the administration server, the managed servers become independent. After the administration
server is fixed, the heartbeats start up again and the managed servers deactivate their independence, but
MSI is still enabled for a future event. These times can all be changed to suit your particular environment.

Restarting an Administration Server on a New Computer
WebLogic allows the creation of a backup of the administration server as follows:

1. Install Oracle WebLogic Server on a backup computer.
2. Copy the application files to a backup computer.
3. Copy the configuration files to a backup computer.
4. Restart the administration server on a new computer.
OLD NEW
AdminServer1 AdminServer1
admin.example.com admin.example.com Name reassigned via DNS
(192.168.0.1) 192.168.0.2 or virtual ip.

Managed Managed Managed
ServerA ServerB ServerC
192.168.0.11 192.168.0.12 192.168.0.13
If a hardware crash prevents you from restarting the administration server on the same computer, you can
recover the management of the running managed servers as follows:
1. Install the Oracle WebLogic Server software on the new computer designated as the replacement
administration server.
2. Make your application files available to the new administration server by copying them from backups
or by using a shared disk. Your files must be available in the same relative location on the new file
system as on the file system of the original administration server.
3. Make your configuration and security files available to the new administration computer by copying
them from backups or by using a shared disk. These files are located under the directory of the
domain being managed by the administration server.
4. Restart the administration server on the new computer.
When the administration server starts, it communicates with the already-running managed servers via a
Node Manager and informs the servers that the administration server is now running on a different IP
address.
Note: You cannot have two administration servers at the same time, both claiming ownership of the same
managed servers. This is not a warm standby; this must be a cold standby. The original administration
server must be stopped or dead for the backup administration server to contact the managed servers.

Quiz Q
What happens if you have a backup administration server?
a. You are allowed to have only one administration server. If it fails, the managed servers
run in MSI mode until your administration server comes back.
b. It runs simultaneously with the primary administration server in a load-sharing mode.
c. It can run in a warm standby keeping itself in sync with the main administration server.
d. It can be configured on a virtual host, sharing the same virtual IP, which must be moved
manually on failure.

Answer: d
You can have only one administration server at a time; To achieve high availability, you configure the
Administration Server on a virtual host so that if the machine that the Administration Server runs on fails,
you can fail it over to another host in the domain. The Administration Server is configured to use a virtual IP
to overlap the backup hosts. You configure the Administration Server to listen on this virtual IP. The benefit
of using a virtual host and virtual IP is that you do not need to add a third machine; if failover occurs, the
virtual host can be mapped to a surviving host in the domain by "moving" the virtual IP.

Agenda

– JTA Review
– Configure JTA Service-Level Migration
– Set Up Automatic JTA Service-Level Migration


Java Transaction API (JTA) Review
• WebLogic Server uses JTA to implement and manage transactions.

• WebLogic Server’s JTA implementation:
– Creates a unique transaction identifier (XID)
– Supports an optional transaction name
– Tracks resources, including databases, involved in transactions
– Orchestrates 2PC using XA
– Executes rollbacks
– Executes automatic recovery procedures in the event of failure
– Manages timeouts

WebLogic Server’s implementation of JTA provides the following support for transactions. It:
• Creates a unique transaction identifier when a client application initiates a transaction.
• Supports an optional transaction name describing the business process that the transaction
represents. The transaction name makes statistics and error messages more meaningful.
• Works with the WebLogic Server infrastructure to track objects that are involved in a transaction and,
therefore, must be coordinated when the transaction is ready to commit.
• Notifies the resource managers (typically, databases) when they are accessed on behalf of a
transaction. Resource managers lock the accessed records until the end of the transaction.
• Orchestrates the two-phase commit when the transaction completes, which ensures that all the
participants in the transaction commit their updates simultaneously. WebLogic Server coordinates
the commit with any databases that are being updated by using the Open Group’s XA protocol. Most
relational databases support this standard.

What Is Service Migration?
WebLogic’s service migration infrastructure:

• Allows a pinned resource on a failed server to be restarted on another running server
• Supports both manual and automatic migration
Server 3
Server 1 Server 2
JMS Server 2
JMS Server 1 JMS Server 2
JTA Service 2
JTA Service 1 JTA Service 2 Custom
Service
Custom Service Custom Service
JMS Server 3

JTA Service 3
Service-level migration in WebLogic Server is the process of moving the pinned services from one server
instance to a different server instance that is available within the cluster. The migration framework provides
tools and infrastructure for configuring and migrating targets, and, in the case of automatic service migration,
it leverages WebLogic Server’s health monitoring subsystem to monitor the health of services hosted by a
migratable target.
High availability is achieved by migrating a migratable target from one clustered server to another when a
problem occurs on the original server. You can also manually migrate a migratable target for scheduled
maintenance or you can configure the migratable target for automatic migration.
JTA services are singleton services, and, therefore, are not active on all server instances in a cluster. To
ensure that singleton JTA services do not introduce a single point of failure for dependent applications in the
cluster, WebLogic Server can be configured to automatically or manually migrate them to any server
instance in the migratable target list.
The transaction service automatically attempts to recover transactions on system startup by parsing all
transaction log records for incomplete transactions and completing them.
Within an application, you can also define a custom singleton service that can be used to perform tasks that
you want to be executed on only one member of a cluster at any give time.

Service Migration Prerequisites
• Manual service migration configuration applies to Configured cluster servers while

automatic service migration may be used with both Configured and Dynamic cluster
members.
• A node manager must be running if you want to:
– Use automatic service migration with consensus leasing
– Run custom scripts before or after service migration
• Persistent stores and TLOGs must be backed by a highly available network file system
or database:
– TLOG records are stored in the default persistent store.

When using consensus leasing, the member servers maintain leasing information in-memory, which
removes the requirement of using a database. But this type of leasing also requires that you use Node
Manager to control servers within the cluster. It also requires that all servers that are either migratable or
that could host a migratable target must have a Node Manager associated with them. The Node Manager is
required to get health monitoring information about the member servers involved.
Node Manager must be running on every machine hosting managed servers within the cluster only if
pre/post-migration scripts are defined. If pre/post-migrations are not defined and the cluster uses the
database leasing option, then Node Manager is not required.
To migrate the JTA Transaction Recovery Service from a failed server in a cluster to another server in the
same cluster, the backup server must have access to the transaction log (TLOG) records from the failed
server. Transaction log records are stored in the default persistent store for the server or in a shared
database.

Service Migration Architecture: Database Leasing
Cluster
Master Server Renew Server

Services Check Services
Migrate
Server

Server
Migrated
Services Renew Services
Leasing is the process WebLogic Server uses to manage services that are required to run on only one
member of a cluster at a time. Leasing ensures exclusive ownership of a
cluster-wide entity. Within a cluster, there is a single owner of a lease. Additionally, leases can failover in
case of server failure. This helps to avoid having a single point of failure.
Setting a cluster’s Migration Basis to database leasing requires that the Data Source For Automatic
Migration option be set with a valid JDBC data source. It also implies that there is a table created in the
database that the managed servers will use for leasing.
To accommodate service migration requests, each server also performs basic health monitoring on
migratable services that are deployed to it. A server also has a direct communication channel to the leasing
system, and can request that the lease be released (thus triggering a migration) when bad health is
detected.

Service Migration Architecture: Consensus Leasing
Cluster
Check Health
Node Manager Node Manager
Master Server Server

Services Services
Renew
Migrate
Server Server
Migrated Services

Services
Node Manager
Node Manager Check Health
Setting a cluster’s Migration Basis to consensus leasing means that the member servers maintain leasing
information in-memory, which removes the requirement of using a database. However, this version of
leasing requires that you use Node Manager to control servers within the cluster. In other words, all servers
that are migratable, or which could host a migratable target, must have a Node Manager associated with
them. The Node Manager is required to get health monitoring information about the member servers
involved.

What Is a Migratable Target?
A migratable target:
• Defines a group of servers within a cluster, along with a migration policy
• Identifies a primary or “preferred” server
• Can identify a list of candidate servers to use for migration
• Allows you to group pinned resources that should be migrated together
Configured clusters
only!
Migratable
Preferred Server Target

JMS Server Target
Candidate Server Policy
Store
Candidate Server
A migratable target is a special target that can migrate from one server in a cluster to another. As such, a
migratable target provides a way to group migratable services that should move together. When the
migratable target is migrated, all services hosted by that target are migrated.
To configure a JMS service for migration, it must be deployed to a migratable target. A migratable target
specifies a set of servers that can host a target. Specifically it defines a preferred server for the services and
an ordered list of candidate backup servers should the preferred server fail. Only one of these servers can
host the migratable target at any one time.
After a service is configured to use a migratable target, the service is independent from the server member
that is currently hosting it. For example, if a JMS server with a deployed JMS queue is configured to use a
migratable target, the queue is decoupled from the server that hosts it. In other words, the queue is always
available when the migratable target is hosted by any server in the cluster.
You must target your JMS service to the same migratable target that your custom persistent store is also
targeted to. If no custom store is specified for a JMS service that uses a migratable target, a validation
message will be generated by the Administration Server, followed by failed JMS server deployment.
Moreover, a server configured in such a way will not boot.

Service Migration Policy Options
Policy Type Description

Manual Only (default) Automatic service migration is disabled for this target.
Failure Recovery Pinned services deployed to this target will:
• Initially start only on the preferred server
• Migrate only if the cluster master determines that the preferred server has
failed
Exactly-Once Pinned services deployed to this target will:

• Initially start on a candidate server if the preferred one is unavailable
• Migrate if the host server fails or is gracefully shut down

When a migratable target uses the manual policy (the system default), an administrator can manually
migrate pinned migratable services from one server instance to another in the cluster, either in response to
a server failure or as part of regularly scheduled maintenance.
The failure recovery policy indicates that the service will start only if its preferred server is started. If an
administrator manually shuts down the preferred server, either gracefully or forcibly, then services will not
migrate. However, if the preferred server fails due to an internal error, services will be automatically
migrated to another candidate server. If such a candidate server is unavailable (due to a manual shutdown
or an internal failure), the migration framework will first attempt to reactivate the service on its preferred
server. If the preferred server is not available at that time, the service will be migrated to another candidate
server.
The exactly-once policy indicates that if at least one server in the candidate list is running, then the service
will be active somewhere in the cluster, even if servers are shut down (either gracefully or forcibly). It is
important to note that this value can lead to target grouping. For example, if you have five exactly-once
migratable targets and only boot one server in the cluster, all five targets will be activated on that server.
The failure recovery option is recommended for most types of clustered JMS applications.

Configuration Roadmap
1. Configure the cluster leasing service.

2. Configure automatic JTA service migration.
3. Optionally, select candidate servers for migration.
4. Optionally, create custom pre/post migration scripts.
5. Configure the default store on all candidate servers to use a shared file system.


JTA Service Migration: Before Failure
Shared Cluster
storage or DB
Server 1
JTA Service 1
TLOG1
JTA participants
(resource managers)
Server 2
JTA Service 2
TLOG2

Server 3
JTA Service 3
TLOG3
The JTA Transaction Recovery Service is designed to gracefully handle transaction recovery after a crash.
You can manually migrate the Transaction Recovery Service from an unhealthy server instance to a healthy
server instance, with the help of the server health monitoring services. In this manner, the backup server
can complete transaction work for the failed server.
By default, the transaction manager uses the default persistent store to store transaction log files. To enable
migration of the Transaction Recovery Service, you must either configure JTA to use a highly available
database, or configure the default persistent store so that it maintains its data files on a persistent storage
solution that is available to other servers in the cluster.
JMS services can be migrated independently of the JTA Transaction Recovery Service. However, because
the JTA Transaction Recovery Service provides the transaction control of the other subsystem services, it is
usually migrated along with them. This ensures that the transaction integrity is maintained before and after
the migration of the subsystem services.

JTA Service Migration: After Failure
Shared Cluster
storage or DB
Server 1
TLOG1 JTA participants

Server 2 (resource managers)
JTA Recovery
JTA Service 2
TLOG2

Server 3
JTA Service 3
TLOG3
When JTA has automatic migration enabled, a server will shut itself down if the JTA subsystem reports itself
as unhealthy (FAILED). For example, if any I/O error occurs when accessing the TLOG, then JTA health
state will change to FAILED.
A server can perform transaction recovery for multiple failed servers. While recovering transactions for other
servers, the backup server continues to process its own transactions.
For transactions for which a commit decision has been made, but the second phase of the two-phase
commit process has not completed, the Transaction Recovery Service completes the commit process. For
transactions that the transaction manager has prepared with a resource manager (transactions in phase one
of the two-phase commit process), the Transaction Recovery Service must try to recover the transaction for
each resource manager and eventually resolve (by either committing, rolling back, or forgetting) all
transaction IDs identified during the recovery process.
If the backup server finishes recovering the TLOG transactions before the primary server is restarted, it will
initiate an implicit migration of the Transaction Recovery Service back to the primary server. If the backup
server is still recovering the TLOG transactions when the primary server is restarted, the backup server will
initiate an implicit migration of the Transaction Recovery Service to the primary server.

Configuring JTA Service Migration
The optional script

mount_disk.py mounts the
shared disk on the surviving server.
The optional script

umount_old.py dismounts the
SAN disk from the failed server.
WebLogic Server provides the ability to migrate the Transaction Recovery Service at both the server level
and the service level, either manually or automatically. Automatic service migration of the Transaction
Recovery Service migration leverages the Health Monitoring subsystem to monitor the health of the service
hosted by a migratable target. When the primary server fails, the migratable service framework automatically
migrates the Transaction Recovery Service to a backup server. When using the Automatic Service Migration
Feature, you must configure the "Migration Basis" for the cluster, enable automatic migration, and optionally
specify whether you will be using any pre- or post-migration scripts. In the example, a pre-migration script,
mount_disk.py, ensures that a shared disk is mounted on the surviving server. Such script must be
stored in the DOMAIN_HOME/bin/service_migration directory. Conversely, a post-migration script,
stored in the same directory, called umount_old.py, ensures that a SAN disk is dismounted from the
failed server after the migration has occurred.

Set Up Automatic JTA Service-Level Migration
Configuration > Migration tab
Optionally, restrict the servers to

which this service can migrate

A server’s transaction manager is not assigned to a migratable target like other pinned services. Instead,
manual and automatic JTA is simply configured for each individual server in the cluster. This is because the
transaction manager has no direct dependencies on other pinned resources when contrasted with services
such as JMS.
Select each server in the cluster. In the JTA Migration Configuration section of the server's Configuration >
Migration tab, configure automatic migration of the JTA Transaction Recovery Service by selecting the
Automatic JTA Migration Enabled check box.
You may also want to restrict the potential servers to which you can migrate the Transaction Recovery
Service. For example, there may be cases when all servers do not have access to the current server’s
transaction log files. If no candidate servers are chosen, any server within the cluster can be chosen as a
candidate server. From the Candidate Servers Available box, select the managed servers that can access
the JTA log files. They become valid Candidate Servers when you move them into the Chosen box.
You must include the original server in the list of chosen servers so that you can manually migrate the
Transaction Recovery Service back to the original server, if need be. The administration console enforces
this rule.

Quiz Q
What is the default policy for a migratable target?
a. Manual
b. Exactly-Once
c. Preferred Server
d. Failure Recovery

Answer: a

Quiz Q
For which two service migration scenarios do you require Node Manager?
a. Custom migration scripts
b. Failure recovery policy
c. Consensus leasing
d. Database leasing

Answer: a, c

Quiz Q
A Singleton Service can run at the same time on two managed servers:
a. Only if it is configured to be manually migratable
b. Only if the JTA is configured to use a highly available database (that is, RAC)
c. Singleton Services can never run on more than one node at the same time
d. Only if it is configured to be automatically migratable

Answer: c

Practice 11-1 Overview: Configuring JTA Service-Level Migration
This practice covers the following topics:

• Configuring consensus leasing for a cluster
• Enabling automatic JTA migration for each node in the cluster
• Configuring candidate machines and servers for automatic migration
• Setting up a shared persistent store, accessible from all servers in the cluster
• Simulating a server crash and verifying the successful migration of the JTA service


Agenda



Pinned Services
Some types of WebLogic resources are not replicated and instead are pinned to a specific
server, including:
• JMS servers, Store and Forward Agents, Singleton services
• Persistent stores
• Transaction logs (TLOGs)
Cluster
Server 1 Server 2 Server 3

JMS Server 1 JMS Server 2 JMS Server 3
TLOG 1 Store 1 TLOG 2 Store 2 TLOG 3 Store 3
In a WebLogic Server cluster, most subsystem services are hosted homogeneously on all server instances
in the cluster, enabling transparent failover from one server to another. In contrast, pinned services, such as
JMS-related services and the WebLogic transaction recovery service, are hosted on individual server
instances within a cluster. For these services, the WebLogic Server migration framework supports failure
recovery through service migration and whole server migration.

Pinned Services High Availability (HA) Challenges
• Node manager will automatically restart a failed server.

• Persistent stores and TLOGs ensure that messages and transactions are not lost if ever
a server fails.
• But in-progress messages may become orphaned and cannot be delivered if:
– A failed server cannot be restarted (hardware failure)
– A machine must be taken down for maintenance

JMS-related services are singleton services, and therefore are not active on all the server instances in a
cluster. Instead, they are pinned to a single server in the cluster to preserve data consistency. However, this
approach potentially introduces a single point of failure in your application.

High Availability Options for Pinned Services Clusters
Choose one of the following options to ensure HA for JMS and to avoid orphaned
messages:
Option Dynamic Cluster? Configured Cluster?

Whole Server Migration Yes Yes
Service Migration No Yes
Virtual Machine Migration Yes Yes
Now YES!

Supported as of 12.2.1
Configurable in the server
template!
Server and service migration are capabilities that are available only to configured clusters that do not use
cluster-targeted JMS servers. Service migration is currently not supported with dynamic clusters. Note that
Service Migration is supported for Dynamic Clusters as of WebLogic Server 12.2.1.
WebLogic Server provides the capability to migrate clustered server instances. A clustered server that is
configured to be migratable can be moved in its entirety from one machine to another, at the command of an
administrator, or automatically, in the event of failure. The migration process makes all of the services
running on the server instance available on a different machine, but not the state information for the
singleton services that were running at the time of failure

Whole-Server Migration
WebLogic’s whole-server migration infrastructure:

• Allows a server on a failed machine to be restarted on another machine
• Requires a running Node Manager on each machine participating in migration
• Requires servers to be members of a cluster
• Supports both manual and automatic failover
Machine A Machine B Machine C

Server 1 Server 2 Server 2
When a migratable server becomes unavailable for any reason (for example, if it hangs, loses network
connectivity, or its host machine fails), migration is automatic. Upon failure, a migratable server is
automatically restarted on the same machine if possible. If the migratable server cannot be restarted on the
machine where it failed, it is migrated to another machine. In addition, an administrator can manually initiate
migration of a server instance.
Node Manager is used by the Administration Server or a stand-alone Node Manager client to start and stop
migratable servers and is invoked by the cluster master to shut down and restart migratable servers, as
necessary.
Server migration has the following additional requirements:
• There is no built-in mechanism for transferring files that a server depends on between machines.
Using a disk that is accessible from all machines is the preferred way to ensure file availability. If you
cannot share disks between servers, you must ensure that the contents of domain_dir/bin are
copied to each machine.
• You cannot create network channels that have different listen addresses on a migratable server.
• Although migration works when servers are not time-synchronized; time-synchronized servers are
recommended in a clustered environment.

Automatic Server Migration Architecture: No Failure
Cluster
Node Node
Manager Manager
Server 1 Renew
Server 2
Renew Lease
Cluster Lease
Master Leasing
Service
Check
Lease Status Renew Server 3
Lease

Node Node
Manager Manager
The example cluster contains three managed servers, all of which are migratable. Each managed server
also runs on its own machine. A fourth machine is also available as a backup, if one of the migratable
servers fails. Node Manager is running on the backup machine and on each machine with a running
migratable server.
All managed servers in the cluster obtain a migratable server lease from the leasing service. They also
periodically renew their leases in the lease table, proving their health and liveness. Because Server 1 starts
up first, it also obtains a cluster master lease, whose responsibilities include monitoring the lease table.

Automatic Server Migration Architecture: Machine Failure
Cluster
Node Check Machine Status Node

Manager 2 Manager
Server 1 Server 2
Check
Lease Status
Cluster
Master 1 Leasing
Service
3 Renew Server 3

4 Lease
Start Server
Node Node
Server 2
Manager Manager
1. The machine that hosts Server 2 fails. On its next periodic review of the lease table, the cluster
master detects that Server 2’s lease has expired.
2. The cluster master tries to contact the Node Manager on the backup machine to restart Server 2, but
fails, because the entire machine is unreachable. Alternatively, if Server 2’s lease had expired
because it was hung, but its machine was still reachable, the cluster master would use the Node
Manager to restart Server 2 on the same machine.
3. The cluster master contacts the Node Manager on the backup machine, which is configured as an
available host for migratable servers in the cluster. The Node Manager then starts Server 2.
4. Server 2 starts up and contacts the Administration Server to obtain its configuration and finally
obtains a migratable server lease.

Configuration: Overview
1. Create machine definitions for your domain.

2. Configure Node Managers on your machines, including network interface settings.
3. Configure the cluster leasing service.
4. Enable automatic server migration on all or a subset of clustered servers.
5. Configure a list of candidate machines for server migration.
Most migration

settings require
server restart.
Node Manager must be running and configured to allow server migration. The Java version of Node
Manager can be used for server migration on Windows or UNIX. The SSH version of Node Manager can be
used for server migration on UNIX only. Refer to the Node Manager Administrator's Guide in the WLS
documentation for the available configuration and security options.

Quiz Q
The two leasing mechanisms supported by WebLogic Server to manage services that are
required to run on only one server in the cluster at a time are:
a. Database leasing
b. File-based leasing
c. Voting-based leasing
d. Two-phase leasing
e. Concurrency-based leasing
f. Consensus leasing

Answer: a, f

Summary
In this lesson, you should have learned how to:

• Describe disaster recovery scenarios for WebLogic Server
• Create a backup administration server
• Configure service-level transaction migration
• Describe whole server migration for WebLogic Server


12
Managing Data Sources

Objectives

• Suspend and resume a data source
• Configure a multi data source


Agenda
• Review:
– JDBC
– Data Source
• Managing Data Sources
• GridLink Data Source Review
• Multi Data Sources
• Review: Connection Testing
• Proxy Data Sources
• Creating a Multi Data Source


Review: JDBC
• The Java Database Connectivity (JDBC) API:

– Is a platform- and vendor-independent mechanism for accessing and using a
database
– Provides transparency from proprietary vendor issues
– Requires the use of a driver (a Java class)
• JDBC drivers are supplied with the WebLogic Server installation or by your database
vendor.
Get connection Get connection

Driver

SQL statements Database calls
Application Database
Code
The JDBC API is the way in Java code to work with SQL. It builds on Open Database Connectivity (ODBC),
so developers familiar with ODBC find it easy to use.
The value of JDBC lies in the fact that an application can access virtually any relational database and run on
any platform with a Java Virtual Machine (JVM). That is, with JDBC, it is not necessary to write one program
to access a Sybase database, another to access an Oracle database, another to access an IBM DB2
database, and so on. You can write a single program by using the JDBC API. Because the application is
written in Java, you need not write different applications to run on different platforms, such as Windows and
Linux.
JDBC accomplishes database connections by using a driver mechanism that translates JDBC calls to native
database calls. Although most available drivers are fully written in Java (Type 4 drivers), and are thus
platform independent, some drivers (Type 2) use native libraries and are targeted to specific platforms.

Data Source: Review
A data source is a Java object targeted to and managed by one or more instances of
WebLogic Server. A deployed data source has connections to a particular database in its
connection pool ready-to-go for applications running on those servers.
1. An application looks up the data source
in a server’s resource tree by using the 1
JNDI API.
2
2. It asks the data source for a connection. Data Source
3. It uses the connection (which uses a driver)
to access the database. Application
Code Connection
4. When finished, it closes the connection Pool

(which returns it to the pool). 3
Driver
WebLogic Server
A data source is a Java object managed by WebLogic Server and used by application code to obtain a
database connection. Retrieving a database connection from a data source is better than getting a
connection directly from the database for two reasons:
• Connections in a data source’s connection pool have already been created. Therefore, the
application does not have to wait for connection creation.
• All database-specific information moves out of the application code and into the WebLogic Server
configuration, making the code more portable and robust.
Data sources can be created by using one of the WebLogic Server administration tools. A data source is
configured with a connection pool that will contain connections to a particular database. It is also targeted to
one or more instances of WebLogic Server.
For an application to use one of the connections in a data source’s connection pool, first the application
looks up the data source in the server’s resource tree. The API used is the Java Naming and Directory
Interface (JNDI). After the data source is retrieved, the application asks it for a database connection. The
data source gives the application one of the connections not currently being used, from its pool of
connections. The application uses that connection to access the database. When the application is finished
with the connection, it closes it. But rather than close, the connection is returned to the connection pool for
some other application to use.

XA Data Source Review
• Data source objects retrieved by applications via JNDI can be of two types:
– Non-XA
– XA
• XA data sources:
– Will automatically participate in distributed or “global” transactions initiated by the
application
– Typically require the underlying JDBC driver to support XA
– Can use a non-XA driver in certain scenarios

One of the most fundamental features of WebLogic Server is transaction management. Transactions are a
means to guarantee that database changes are completed accurately. WebLogic Server protects the
integrity of your transactions by providing a complete infrastructure for ensuring that database updates are
done accurately, even across a variety of resource managers. If any one of the operations fails, the entire
set of operations is rolled back.
If you use global or XA transactions in your applications, you should use an XA JDBC driver to create
database connections in the JDBC data source. If an XA driver is unavailable for your database, or you
prefer not to use an XA driver, you should enable support for global transactions in the data source. You
should also enable support for global transactions if your applications meet any of the following criteria:
• They use the EJB container in WebLogic Server to manage transactions.
• They include multiple database updates within a single transaction.
• They access multiple resources, such as a database and the Java Messaging Service (JMS), during
a transaction.
• They use the same data source on multiple servers (clustered or nonclustered).

Agenda
• Review
– Why Manage Data Sources?
– Suspend a Data Source
– Resume a Data Source
– Configure Data Source Interceptors


Why Manage a Data Source?
You may require managing the connection pool of your data source for several reasons:
• Database maintenance
• Troubleshooting • Suspend
• Production issues • Resume
• Reset
• Shrink
• Stop
WebLogic Server
• Start

Data Source
Application
There are several operations that you can perform on a data source. The following commands enable you to
control your data source to keep your applications running smoothly:
• Suspend: Marks the data source as disabled, so applications cannot use connections from the pool
• Resume: Marks the data source as enabled, so applications can use connections from the pool
• Reset: Closes and re-creates all database connections in a connection pool
• Shrink: Shrinks the connection pool to the greater of minCapacity or the number of connections in
use
• Stop: Shuts down a data source and associated connections. This can be a graceful or forced
shutdown.
• Start: Re-initializes a data source that was previously shut down

Suspend a Data Source
1 2

6
To suspend a data source instance by using the administration console, perform the following steps:
1. Select Services > Data Sources.
2. Select a data source from the list of available data sources.
3. Click the data source’s Control tab.
4. Select the target where the data source instance resides that you want to suspend.
5. Click Suspend and choose to suspend gracefully or forcefully:
- Suspend > Suspend: Marks the data source instance as disabled and blocks new
connection requests. All connections are preserved and are viable again when the data
source is resumed.
- Suspend > Force Suspend: Marks the data source instance as disabled and destroys all
connections. All transactions are rolled back. The data source attempts to re-create the
connections in preparation for a subsequent resume operation.
6. Ensure that the data source is in the Suspended state.

Resume a Data Source
1 2

6
To resume a suspended data source instance by using the administration console, perform the following
steps:
1. Select Services > Data Sources.
2. Select a data source from the list of available data sources.
3. Click the data source’s Control tab.
4. Select the target of the suspended data source.
5. Click the Resume button to return the data source to a Running state:
- If the data source was suspended gracefully, all connections are preserved and are usable
again.
- If the data source was suspended forcefully, all clients must reserve new connections to
perform work.
6. Ensure that the data source is in the Running state.

Data Source Interceptors
Data Source interceptors:

• Intercept dynamic cluster scale up operations.
• Determine the maximum number of connection that could be created after scaling.
• Stop or continue the scaling operation based on whether the maximum is exceeded.
To configure a data source interceptor: 3
1
Lock the domain
2

Click New to
Navigate to start the
Diagnostics > wizard.
Interceptors
During dynamic cluster scale up operations, new dynamic server instances in a dynamic cluster are started.
For data sources targeted to the dynamic clusters, scaling can result in the creation of additional
connections to the database. Scaling these connections may result in exceeding database capacities.
Datasource interceptors intercepts scaling actions. A data source interceptor intercepts a dynamic cluster
scale up operation to validate that the scaling operation will not overload the database.
To configure a datasource script interceptor:
1. Lock the configuration
2. In the Domain Structure pane navigate to Diagnostics > Interceptors.
3. In the Interceptors pane select the Datasource Interceptors tab and then click New.

Data Source Interceptor
4 5
Configure
name, quota
and priority.
Enter a URL
pattern and

click finish.
4. Enter the name, connection quota and priority of the interceptor. Interceptors are run in priority order,
highest first.
5. Enter a URL pattern for the interceptor. Patterns can be based on existing URLs.
6. Click Finish to create the interceptor.
7. Activate changes.

Practice 12-1 Overview: Controlling a Data Source

• Suspending a data source
• Resuming a data source


Agenda
• Review


Oracle Real Application Clusters (RAC): Overview
Oracle RAC:
• Supports multiple Oracle database servers for greater scalability
• Relies on database servers having access to a shared and highly available storage
device
RAC
node 1
Driver Shared
Storage
RAC

Application node 2
Oracle Real Application Clusters (RAC) is software that enables users on multiple machines to access a
single database with increased reliability. RAC is made up of two or more Oracle database instances
running on two or more clustered machines that access a shared storage device via cluster technology. To
support this architecture, the machines that host the database instances are linked by a high-speed
interconnect to form the cluster. This interconnect is a physical network used as a means of communication
between the nodes of the cluster. Cluster functionality is provided by the operating system or compatible
third-party clustering software.
Because every RAC node in the cluster has equal access and authority, the loss of a node may impact
performance, but does not result in down time.

Oracle GridLink for RAC
WebLogic Server’s GridLink data source is “RAC-aware.” It:

• Performs intelligent load balancing based on the current RAC workload
• Implements RAC’s Fast Connection Failover (FCF) pattern
• Ensures that all database operations within a global transaction are routed to the same
RAC node (“XA affinity”)
WebLogic Server RAC
node 1
GridLink RAC
Data Source node 2

RAC
Applications
node 3
A single GridLink data source provides connectivity between WebLogic Server and an Oracle database
service that has been targeted to an Oracle RAC cluster. This type of data source automatically adjusts the
distribution of work based on the current performance metrics reported by each RAC node, such as CPU
usage, availability, and response time. If this capability is disabled, GridLink data sources instead use a
round-robin, load-balancing algorithm to allocate connections to RAC nodes.
A GridLink data source implements Oracle’s Fast Connection Failover (FCF) pattern, which:
• Provides rapid failure detection
• Aborts and removes invalid connections from the connection pool
• Performs graceful shutdown for planned and unplanned Oracle RAC node outages
• Adapts to changes in topology, such as adding or removing a node
• Distributes runtime work requests to all active Oracle RAC instances, including those rejoining a
cluster
XA affinity ensures that all the database operations performed on a RAC cluster within a global transaction
are directed to the same RAC instance. This increases performance and also helps ensure data integrity
after a failure.

Agenda
• Review
– Multi Data Source Architecture
– Comparison of GridLink and Multi Data Sources
– Multi Data Source Failover Option
– Multi Data Source Load Balancing Option


Multi Data Sources
• To avoid a single point of failure and to achieve greater scalability, many enterprises
employ multiple database servers.
• A multi data source:
– Is a pool of data sources
– Is used by applications exactly like a standard data source
– Transparently provides load balancing or failover across the member data sources
– Can be XA or non-XA

A multi data source is an abstraction around a group of data sources that provides load balancing or failover
processing between the data sources associated with the multi data source. Multi data sources are bound to
the JNDI tree or local application context just like data sources are bound to the JNDI tree. Applications look
up a multi data source on the JNDI tree just like they do for data sources, and then request a database
connection. The multi data source determines which data source to use to satisfy the request depending on
the algorithm selected in the multi data source configuration: load balancing or failover.
All data sources used by a multi data source to satisfy connection requests must be deployed on the same
servers and clusters as the multi data source. A multi data source always uses a data source deployed on
the same server to satisfy connection requests. Multi data sources do not route connection requests to other
servers in a cluster or in a domain. To deploy a multi data source to a cluster or server, you select the server
or cluster as a deployment target. When a multi data source is deployed on a server, WebLogic Server
creates an instance of the multi data source on the server. When you deploy a multi data source to a cluster,
WebLogic Server creates an instance of the multi data source on each server in the cluster.

Multi Data Source Architecture
Multi Data Source
Data Source A
1. JNDI Lookup Connection

2. Get Connection
Connection
3. Perform SQL
4. Return Connection Connection
JDBC Driver
Synchronize
Data Source B

Applications Data Source C
A multi data source can be thought of as a pool of data sources. Multi data sources are best used for
failover or load balancing between nodes of a highly available database system, such as redundant
databases. Multi data sources do not provide any synchronization between databases. It is assumed that
database synchronization is handled properly outside of WebLogic Server so that data integrity is
maintained.
You create a multi data source by first creating data sources, then creating the multi data source by using
the administration console or the WebLogic Scripting Tool (WLST), and then assigning the data sources to
the multi data source.
The data source member list for a multi data source supports dynamic updates. You can remove a database
node and corresponding data sources without redeployment. This capability provides you the ability to shut
down a node for maintenance or shrink a cluster.
Some examples of database replication technologies include Oracle Streams, Oracle Golden Gate, Oracle
Data Guard, IBM InfoSphere, Sybase Replication Server, and MySQL Replication.

Comparison of GridLink and Multi Data Sources
GridLink and multi data sources are used for different scenarios:
GridLink Multi Data Source
Used only for Oracle RAC databases Used for any database that supports replication
Specialized to leverage Oracle RAC features No specialization for any databases
Provides high availability for access to a database that Provides high availability for multiple databases that
is viewed as a single database are synchronized using another technology


Failover Option
• The multi data source uses the first member data source to handle all connection
requests.
• During a connection request, the other member data sources are tried in succession if
the current data source:
– Becomes unavailable
– Has no unused connections (optional)
– Is suspended by the administrator
• If a connection fails when in use, the application must still handle it programmatically.

Use as primary
Data Source A
Multi Data
Source Use as backup
Data Source B
The multi data source failover algorithm provides an ordered list of data sources to use to satisfy connection
requests. Normally, every connection request to this kind of multi data source is served by the first data
source in the list. If a database connection test fails and the connection cannot be replaced, or if the data
source is suspended, then a connection is sought sequentially from the next data source on the list.
JDBC is a highly stateful client-DBMS protocol, in which the DBMS connection and transactional state are
tied directly to the socket between the DBMS process and the client (driver). Therefore, it is still possible for
a connection to fail after being reserved, in which case your application must handle the failure. WebLogic
Server cannot provide failover for connections that fail while being used by an application. Any failure while
using a connection requires that the application code handle it, such as restarting the transaction.

Load Balancing Option
• The multi data source selects member data sources to satisfy connection requests using
a round-robin scheme.
• Data source failure is handled in the same way as described for the Failover option.
Round robin
Data Source A
Multi Data
Source
Data Source B

The load balancing option is suitable for scenarios where a single database resource may not be able to
keep up with the load of the system. The multi data source balances the load across databases to evenly
distribute the workload across a scaled out data tier.
Connection requests to a load-balancing multi data source are served from any data source in the list. The
multi data source selects member data sources to satisfy connection requests using a round-robin scheme.
When the multi data source provides a connection, it selects a connection from the data source listed just
after the last data source that was used to provide a connection. Multi data sources that use the load
balancing algorithm also fail over to the next data source in the list if a database connection test fails and
the connection cannot be replaced, or if the data source is suspended.

Quiz Q
Which of the following is true when a client has a reserved connection from a multi data
source and the database for that connection crashes?
a. JDBC calls from the client fail over to another data source.
b. JDBC calls from the client fail and the client must reserve a new connection.
c. The multi data source provides the client with a new connection to another data source.
d. JDBC calls from the client hang.

Answer: b

Agenda
• Review


Connection Testing
To provide failover, multi data sources require that all member data sources be configured to
use connection testing.
Test before giving a

connection to application.
Test connections
periodically.

Table name or
custom SQL to Seconds to trust a connection
test connection before testing again
Data sources rely on the Test Reserved Connections feature to know when database connectivity is lost.
Testing reserved connections must be enabled and configured for all the data sources within the multi data
source. WebLogic Server will test each connection before giving it to an application. With the failover
algorithm, the multi data source uses the results from connection test to determine when to fail over to the
next data source in the multi data source. After a test failure, the data source attempts to re-create the
connection. If that attempt fails, the multi data source fails over to the next data source.
• Test Frequency: You can enable periodic background connection testing by entering the number of
seconds between periodic tests.
• Test Reserved Connections: Select this check box to test the database connection before giving it
to your application when your application requests a connection from the data source.
• Test Table Name: Enter the name of a small table to use in a query to test database connections.
The standard query is select count(*) from <table>. Most database servers optimize this
SQL to avoid a full table scan, but it is still a good idea to use the name of a table that is known to
have few rows, or even no rows. If you prefer to use a different query as a connection test, enter
SQL followed by a space and the SQL code that you want to use to test database connections.
• Seconds to Trust an Idle Connection Pool: This specifies the number of seconds that WebLogic
trusts that an already reserved idle connection is valid before performing another connection test.

Agenda
• Review


Proxy Data Sources
• Provide a lightweight mechanism for accessing data sources bound to partitions

• Allow quick access to a data source by name
• Avoid applications needing to know details of the underlying datasource
• Require minimal configuration and overhead
Domain
Partition
Source
Source
Proxy
Data
Data

JMS App App
In WebLogic Server Multitenant environments, data sources are replicated for each partition.
A proxy data source provides a mechanism for access to a data source associated with a partition or tenant.
It enables access to a data source without the need to have naming conventions such as context names,
partitions, or tenants. Proxy data sources simplify the administration of multiple data sources by providing a
lightweight mechanism for accessing a data source associated with a partition or tenant. Applications often
need to quickly access a data source by name without needing to know the naming conventions, context
names (partitions or tenants), and so on. A proxy data source provides access to the underlying data
sources. All of the significant processing happens in the data sources to which it points. That is, the
underlying data sources actually handle deployment, management, security, and so on.

Creating a Proxy Data Source
3
2

1
To create a proxy data source after clicking Lock & Edit in the Change Center, perform the following tasks:
1. In the Domain Structure tree, expand Services and then select Data Sources.
2. Above (or below) the table of data sources, click the New drop-down list and select Proxy Data
Source.
3. On the first page of the data source creation wizard, enter or select the following information and
then click Next:
- Name: The configuration name for this data source
- JNDI Name: The JNDI “binding name” for this data source. Applications look up the data
source on the server’s JNDI tree by this name. The name can include contexts by placing
dots in the string. Note that the name and JNDI name can be different.
- Switching Properties: Enter the switching properties to be passed to the switching callback
method for the Proxy data source. This value is dependent on the requirements of the
switching callback. The format of the proxy switching properties is
partition1=datasource1;partition2=datasource2;...;default=datasource.

Creating a Proxy Data Source

4. Select the servers or clusters to which the data source should be deployed and then click Finish. If
no servers are targeted, the data source is created, but not deployed. You will need to target it later.
As usual, to confirm the changes, in the Change Center, click Activate Changes.

Monitoring Proxy Data Source JDBC Resources

You can monitor a variety of statistics for each data source instance in your domain, such as the current
number of database connections in the connection pool, current number of connections in use, and the
longest wait time for a database connection.
To view the statistics of a Proxy JDBC Data source:
1. In the Domain tree, expand Services node and then select Data Sources.
2. On the Summary of Data Sources page, click the Proxy Data Source name.
3. Select the Monitoring: Statistics tab. Statistics of the deployed instance of the Proxy Data source are
displayed.

Agenda
• Review
• (Optional) Creating a Multi Data Source


Creating a Multi Data Source
1 3

1. In the Domain Structure panel, expand Services and then select Data Sources.
2. Click New > Multi Data Source.
3. Enter or select the following information and click Next:
- Name: Enter a unique name for this JDBC multi data source.
- JNDI Name: Enter the JNDI path to where this JDBC data source will be bound. Applications
look up the data source on the JNDI tree by this name when reserving a connection. To
specify multiple JNDI names for the multi data source, enter each on a separate line.
- Algorithm Type: Select an algorithm option:
Failover: The multi data source routes connection requests to the first data source in the list; if the request
fails, the request is sent to the next data source in the list, and so forth.
Load-Balancing: The multi data source distributes connection requests evenly to its member data sources.

Creating a Multi Data Source

Limits which data
6 sources can be
added as members
4. Select the servers or clusters on which you want to deploy the multi data source. The targets that
you select will limit the data sources that you can select as part of the multi data source. You can
select only data sources that are deployed to the same targets as the multi data source. Click Next.
5. Select one of the following options and click Next. The option that you select limits the data sources
that you can select as part of the multi data source in a later step. Limiting data sources by JDBC
driver type enables the WebLogic Server transaction manager to properly complete or recover global
transactions that use a database connection from a multi data source:
- XA Driver: The multi data source will use only data sources that use an XA JDBC driver to
create database connections.
- Non-XA Driver: The multi data source will use only data sources that use a
non-XA JDBC driver to create database connections.
6. Select the data sources that you want the multi data source to use to satisfy connection requests.
Then use the supplied arrow buttons to reorder the chosen data source list as desired and click
Finish. For convenience, you can also create new data sources at this time using the “Create a New
Data Source” button.

Configuring a Multi Data Source
Change member
data sources.
Change the
algorithm option.
Also fail over if data

source has no free
connections

How often to check
status of member data
sources
1. In the Domain Structure panel, expand Services, and then select Data Sources.
2. Click the existing multi data source.
3. Edit any of the following fields, and then click Save. In general, changes take effect after you
redeploy the multi data source or restart the server:
- JNDI Name: Same field as when creating a new multi data source
- Algorithm Type: Same field as when creating a new multi data source
- Failover Request if Busy: For multi data sources with the failover algorithm, enables the
multi data source to fail over connection requests to the next data source if all connections in
the current data source are in use
- Test Frequency Seconds: The number of seconds between when WebLogic Server tests
unused connections (requires that you specify a test table name). Connections that fail the
test are closed and reopened to reestablish a valid physical connection. If the test fails again,
the connection is closed. In the context of multi data sources, this attribute controls the
frequency at which WebLogic Server checks the health of data sources it had previously
marked as unhealthy. When set to 0, the feature is disabled.

Multi Data Source WLST Example
Create a new multi data source:
edit()
startEdit()
jdbcSystemResource = cmo.create('HRMSMultiDataSource',
'JDBCSystemResource')
jdbcResource = jdbcSystemResource.getJDBCResource()
jdbcResource.setName('HRMSMultiDataSource')
jdbcResourceParams = jdbcResource.getJDBCDataSourceParams()
jdbcResourceParams.setJNDINames(['jdbc.hr.HRMSDS'])
jdbcResourceParams.setAlgorithmType('Failover')
jdbcResourceParams.setDataSourceList('DataSourceA',
'DataSourceB')

jdbcSystemResource.addTarget(getMBean('/Servers/serverA'))
save()
activate(block='true')
CreateMultiDataSource.py
The same JDBCSystemResourceMBean used to configure standard data sources is also used to configure
multi data sources. This MBean has a child MBean of type JDBCDataSourceBean, which in turn has a
child of type JDBCDataSourceParamsBean. Several of these parameters are applicable only to multi data
sources, including:
• AlgorithmType
• DataSourceList
• FailoverRequestIfBusy

Managing Multi Data Source Members
To add a new database node:

1. Start the database.
2. Create a new data source.
3. Add the data source to the multi data source members list.
To remove a database node:
1. Remove the data source from the multi data source members list.
2. When all transactions have completed, suspend and then shut down the corresponding
data source.
3. Shut down the database.

The data source member list for a multi data source supports dynamic updates. This allows environments to
add and remove database nodes and corresponding data sources without restarting the server or losing
connectivity to other member data sources. For example, situations may arise in which you need to grow
and shrink your multi pool in response to throughput, or shut down multi pool nodes for maintenance. You
can do all the required steps in one configuration edit session.
To improve performance when a data source within a multi data source fails, WebLogic Server automatically
disables the data source when a pooled connection fails a connection test. After a data source is disabled,
WebLogic Server does not route connection requests from applications to the data source. Instead, it routes
connection requests to the next available data source listed in the multi data source.
After a data source is automatically disabled because a connection failed a connection test, the multi data
source periodically tests a connection from the disabled data source to determine when the data source (or
underlying database) is available again. When the data source becomes available, the multi data source
automatically re-enables the data source and resumes routing connection requests to the data source,
depending on the multi data source algorithm and the position of the data source in the list of included data
sources. Frequency of these tests is controlled by the Test Frequency Seconds attribute of the multi data
source.

Quiz Q
Which of the following is a data source attribute associated with connection testing?
a. Test Statement
b. Test Capacity
c. Test Table Name
d. Test LLR

Answer: c

Quiz Q
Name three attributes used to configure a multi data source.
a. Statement Cache Type
b. Logging Last Resource
c. Algorithm Type
d. Failover Request if Busy
e. JNDI Name

Answer: c, d, e

Summary

• Suspend and resume a data source
• Configure a multi data source


Practice 12-2 Overview (Optional): Creating and Using a Multi Data
Source
• Creating a multi data source
• Adding data sources to a multi data source
• Configuring a multi data source for failover
• Testing data source failover


Practice 12-3 Overview (Optional): Creating and Using Proxy Data
Sources
• Creating a proxy data source
• Modifying an application to use a proxy datasource
• Deploying and testing a proxy database based application


13
Diagnostic Framework

Objectives
After completing this lesson, you should be able to configure the WebLogic Diagnostic
Framework (WLDF) to monitor a domain.


Agenda
• General Architecture
– WebLogic Diagnostics Framework (WLDF)
– Diagnostic Archives
– Diagnostics Modules
• Diagnostic Images
• Harvesters
• Policies and Actions


WebLogic Diagnostics Framework (WLDF)
• WLDF provides a generic framework to gather and analyze WebLogic runtime data for
monitoring and troubleshooting.
• Use WLDF to:
– Capture a snapshot of key server metrics for distribution to support personnel
– Capture metrics at specific code points in WebLogic or your application
– Periodically record selected MBean attributes
– Send notifications when attributes meet certain conditions

WLDF consists of several components that work together to collect, archive, and access diagnostic
information about a WebLogic Server instance and the applications it hosts.

WLDF Architecture
WLDF
Image Capture
MBeans
Harvester
Data
Metric Collectors Archive
Logs
Actions
Policies
Code

Instrumentation
Event
Monitors Archive
Data creators generate diagnostic data, which is consumed by the logger and the harvester. Those
components coordinate with the archive to persist the data, and they coordinate with the watch and
notification subsystem to provide automated monitoring. The data accessor interacts with the logger and the
harvester to expose current diagnostic data and with the archive to present historical data. MBeans make
themselves known as data providers by registering with the harvester. Collected data is then exposed to
both the watch and notification system for automated monitoring and to the archive for persistence.
The instrumentation system creates monitors and inserts them at well-defined points in the flow of code
execution within the JVM. These monitors trigger events and publish data directly to the archive. They can
also take advantage of policies and actions.
Diagnostic image capture support gathers the most common sources of the key server state used in
diagnosing problems. It packages that state into a single artifact, which can be made available to support
technicians.
The past state is often critical in diagnosing faults in a system. This requires that the state be captured and
archived for future access, creating a historical archive. In WLDF, the archive meets this need with several
persistence components. Both events and harvested metrics can be persisted and made available for
historical review.

Diagnostic Archives
• Collected MBean metrics and events are recorded in the server’s diagnostic archives:
– WLDF file store (<server>/data/store/diagnostics, by default)
– WLDF JDBC store
• Recorded data can be limited using size- or age-based retirement policies.
Module1 Module2
Harvested Data Archive
Harvester Harvester
Instrumentation Instrumentation

Event Data Archive
The Archive component of the WebLogic Diagnostic Framework (WLDF) captures and persists all data
events, log records, and metrics collected by WLDF from server instances and applications running on
them. You can access archived diagnostic data in online mode (that is, on a running server). You can also
access archived data in offline mode using the WebLogic Scripting Tool (WLST). You configure the
diagnostic archive on a per-server basis.
For a file-based store, WLDF creates a file to contain the archived information. The only configuration option
for a WLDF file-based archive is the directory where the file will be created and maintained. The default
directory is <domain>/servers/<server>/data/store/diagnostics. When you save to a
file-based store, WLDF uses the WebLogic Server persistent store subsystem.
To use a JDBC store, the appropriate tables must exist in a database, and JDBC must be configured to
connect to that database. The wls_events table stores data generated from WLDF Instrumentation
events. The wls_hvst table stores data generated from the WLDF Harvester component. Refer to the
WebLogic Configuring Diagnostic Archives documentation for the required schema.
WLDF includes a configuration-based, data-retirement feature for periodically deleting old diagnostic data
from the archives. You can configure size-based data retirement at the server level and age-based
retirement at the individual archive level.

Configuring Server Diagnostic Archives
2
1
For file
store option

For JDBC
store option
Retire old data?
Log files are archived as human-readable files. Events and harvested data are archived in binary format, in
a WebLogic persistent store or in a database.
1. In the left pane, expand Diagnostics and select Archives.
2. Click the name of the server for which you want to configure diagnostic archive settings.
3. Select one of the following archive types from the Type list:
- Select File Store to persist data to the file system. If you choose this option, enter the
directory in the Directory field.
- Select JDBC to persist data to a database. If you choose this option, select the JDBC data
source from the Data Source list. You must first configure JDBC connectivity to use this
option.
4. Select or deselect Data Retirement Enabled to enable or disable data retirement for this server
instance, respectively. In the Preferred Store Size field, enter a maximum data file size, in
megabytes. When this size is exceeded, enough of the oldest records in the store are removed to
reduce the size of the store below the maximum. In the Store Size Check Period field, enter the
interval, in minutes, between the times when the store will be checked to see if it has exceeded the
preferred store size.

Diagnostic Modules
A diagnostic module is used to contain the configuration of WLDF components and is used
to target that configuration to servers and clusters.
• Built-in modules
• User-created system modules
Server
Instrumentation Harvester

Monitors Metric Collectors
Policies & Actions

Diagnostic Module
To configure and use the Instrumentation, Harvester, and Watch and Notification components at the server
level, you must first create a system resource called a “diagnostic system module.” System modules are
globally available for targeting to servers and clusters configured in a domain. In WebLogic 12c, you can
target multiple diagnostic system modules to any given server or cluster.
There are two types of diagnostic modules:
• Built-in: These are diagnostic modules that are part of the WebLogic product:
- Production mode domains have a built-in module enabled by default.
- Development mode domains have all built-in modules disabled by default.
- Modules provide for low overhead historical server performance metrics.
- There are three built-in modules:
- Low: Captures the most important data from key WebLogic MBean attributes (default)
- Medium: Captures additional attributes captured by Low and data from other MBeans
- High: Captures more verbose data than Medium and from a larger number of MBeans
- Built-in modules can be cloned to customize a new module based on a built-in module.

• User created: These are diagnostic modules that are created and deployed to WebLogic by using
the administration console or WLST. The configuration contained within is configured by an
administrator.
WLDF provides features for generating, gathering, analyzing, and persisting diagnostic data from
WebLogic Server instances and from applications deployed to them. For server-scoped diagnostics,
some WLDF features are configured as part of the configuration for a server in a domain. Other features
are configured as system resource descriptors that can be targeted to servers (or clusters). For
application-scoped diagnostics, diagnostic features are configured as resource descriptors for the
application.
The harvester, watch, and instrumentation features are configured, packaged, and targeted as part of a
diagnostic module, similar to a JMS module resource. Only instrumentation monitors can be defined in
application-scoped modules, which are placed in the application’s weblogic-diagnostics.xml file.
You create a diagnostic system module through the administration console or WLST. It is created as a
WLDFResourceBean, and the configuration is persisted in a resource descriptor file called
<module>.xml, where <module> is the name of the diagnostic module. The file is created by default

in the domain’s config/diagnostics directory with a .xml extension.

Dynamic Diagnostic Modules
Dynamically create or destroy a diagnostic

module by using the administration console or
WLST.
Server
Instrumentation Harvester
Monitors Metric Collectors
Policies & Actions

Diagnostic Module

Dynamically activate or deactivate a
diagnostic module by using the administration
console or WLST.
When a server hosting a dynamic diagnostic module shuts down, the module reverts to whatever is
contained in the configuration when the server is restarted.

Resource Descriptors
A diagnostic system module has a corresponding resource descriptor:
<wldf-resource
xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-
diagnostics/1.0/weblogic-diagnostics.xsd">
<name>MyDiagnosticModule</name>
<instrumentation>

</instrumentation>
<harvester>

</harvester>

<watch-notification>

</watch-notification>
</wldf-resource> MyDiagnosticModule.xml
A resource descriptor contains the actual configuration of WLDF components and features within an XML
file. There are two types of resource descriptors:
• Configured:
- Is part of the domain configuration stored in $DOMAIN_HOME/config/diagnostics
- Is referenced by the config.xml file
- Can be deployed, activated, and deactivated dynamically
• External:
- Is external to the domain configuration
- Is not referenced by the config.xml file
- Is only deployed, activated, and deactivated dynamically, and can be administered only by
WLST
- Resides in memory of the server until the server is shut down
- Never gets persisted to the domain configuration

Creating a Diagnostic Module
1
2
Configure
Target to one or
resources
more servers

Perform the following steps to create a diagnostic module:

1. In the left pane, expand Diagnostics and select Diagnostic Modules.
2. Click New. Enter a name for the module and, optionally, enter a description. Then click OK.
3. Use the various Configuration tabs to add diagnostic components to this module.
4. To target the module to a server or cluster, click the Targets tab.

WLST: Example
serverConfig> listSystemResourceControls() Modules defined as

External Enabled Name part of the domain
-------- ------- ------------------------------
false false MyModule1
serverConfig> createSystemResourceControl('external-wldf', 'external-wldf.xml')

serverConfig> listSystemResourceControls()
External Enabled Name Modules defined outside the domain in the
-------- ------- external-wldf.xml resource descriptor
------------------------------
true false external-wldf
serverConfig> enableSystemResource('external-wldf')
serverConfig> listSystemResourceControls()

External Enabled Name
-------- ------- ------------------------------
true true external-wldf
DiagnosticModuleExamples.py

WLST Commands for WLDF
Command Description
listSystemResourceControls Lists all available diagnostic system modules
enableSystemResource Activates a diagnostic system module
disableSystemResource Deactivates a diagnostic system module
createSystemResourceControl Creates a diagnostics system module dynamically by

using a specified descriptor file
destroySystemResourceControl

Destroys a previous dynamically created system
module
dumpDiagnosticData Dumps the diagnostics data from a harvester to a local
file

Quiz Q
The WebLogic Diagnostic Framework (WLDF) enables administrators to analyze archived
diagnostic data only in online mode. If the WebLogic cluster is down, no diagnostic data is
available.
a. True
b. False

Answer: b
Archived data can also be accessed in offline mode by using WLST.

Agenda
– What Is a Diagnostic Image?
– Capturing a Diagnostic Image
• Harvesters


What Is a Diagnostic Image?
A diagnostic image is a post-failure snapshot of the state of a running WebLogic Server

instance:
machine
Server 1
Application Application
Diagnostic image is sent to
Oracle Support for analysis.

config.xml JNDI Work JVM Logs
Managers
Image Capture
Diagnostic image capture support gathers the most common sources of the key server state used in
diagnosing problems. It packages that state into a single artifact, which can be made available to support
technicians.
The past state is often critical in diagnosing faults in a system. You use the diagnostic image capture
component of WLDF to create a diagnostic snapshot, or dump, of a server’s internal runtime state at the
time of the capture. This information helps support personnel analyze the cause of a server failure. You can
capture an image manually by using the console or WLST, or generate one automatically as part of a watch
notification.
Because the diagnostic image capture is meant primarily as a post-failure analysis tool, there is little control
over what information is captured. It includes the server’s configuration, log cache, JVM state, work
manager state, JNDI tree, and most recently harvested data. The image capture subsystem combines the
data files produced by the different server subsystems into a single zip file.
If Java's Flight Recorder feature is enabled on your JVM, the diagnostic image will also contain the
recording file, which you can view with Java Mission Control (JMC). If enabled, WebLogic can record its own
events to this JVM file, which you can also browse with JMC.

Capturing a Server Diagnostic Image
Location of image
file (.zip)
1
3

2
Perform the following steps to capture a server image by using the console:
1. In the left pane, expand Diagnostics and select Diagnostic Images.
2. Select the server for which you want to capture a diagnostic image, and click Capture Image.
3. Enter a new directory in the Destination Directory field, or accept the default directory. If you change
the directory for this image capture, it does not change the default directory for capturing images for
this server when they are captured by other means, such as a watch notification. Then click OK.

WLST: Example
Capture a server diagnostic image:
serverRuntime()
wldfCapture = getMBean('WLDFRuntime/WLDFRuntime/
WLDFImageRuntime/Image')
wldfCapture.captureImage('logs/diagnostic_images',30)
CreateImage.py

Additional WLDF WLST examples can be found in the WLDF guide in the product documentation.
Refer to the following MBeans for more information about MBeans related to the diagnostic framework:
• WLDFResourceBean
• WLDFHarvesterBean (a subclass of WLDFResourceBean)
• WLDFHarvestedTypeBean (a component of WLDFHarvesterBean )
• WLDFInstrumentationBean (a subclass of WLDFResourceBean )
• WLDFInstrumentationMonitorBean (a component of WLDFInstrumentationBean )
• WLDFWatchNotificationBean (a subclass of WLDFResourceBean )
• WLDFWatchBean (a component of WLDFWatchNotificationBean )
• WLDFNotificationBean (abstract; subclasses exist for each notification type )
• WLDFRuntimeMBean
• WLDFImageRuntimeMBean (a component of WLDFRuntimeMBean )
• WLDFControlRuntimeMBean
• WLDFSystemResourceControlRuntimeMBean

Quiz Q
The MBean method used to obtain a post-failure snapshot of the state of a running
WebLogic Server from a WLST script is:
a. getSnapshot()
b. capturePic()
c. captureImage()
d. dumpState()

Answer: c

Agenda
• Harvesters
– What Is a Harvester?
– Configuring Metric Collection


What Is a Harvester?
The Harvester is a WLDF component that you can configure to capture WebLogic runtime
MBean data.
Metric collectors tell the

Harvester what to capture.
Harvester
Data
MBeans
Metric Collectors Archive

Data is archived for
historic analysis.

Metric Collectors
• A metric collector definition for the Harvester includes:

– The runtime MBean type to query
– The specific MBean instance names to query (all instances, by default)
– The MBean attributes to collect (all attributes, by default)
– How often to sample data
• Alternatively, use the MBean expression syntax, which also supports wildcards and
complex attributes.
MBean attributes
mydomain: Type=JMS*RuntimeMBean, Name=hr*, MessagesHighCount

MBean type MBean name
Harvesting metrics is the process of gathering data that is useful for monitoring the system state and
performance. Metrics are exposed to WLDF as attributes on qualified MBeans. The Harvester gathers
values from selected MBean attributes at a specified sampling rate. Therefore, you can track potentially
fluctuating values over time. For custom MBeans, the MBean must be currently registered with the JMX
server.
You can configure the Harvester to harvest data from named MBean types, instances, and attributes. If only
a type is specified, data is collected from all attributes in all instances of the specified type. If only a type and
attributes are specified, data is collected from all instances of the specified type.
The sample period specifies the time between each cycle. For example, if the Harvester begins execution at
time T, and the sample period is I, the next harvest cycle begins at T+I. If a cycle takes A seconds to
complete and if A exceeds I, then the next cycle begins at T+A. If this occurs, the Harvester tries to start the
next cycle sooner, to ensure that the average interval is I.
WLDF allows for the use of wildcards (*) in type names, instance names, and attribute specifications. WLDF
also supports nested attributes using a dot delimiter, as well as complex attributes such as arrays and
maps. WLDF watch expressions also support similar capabilities.

Configuring a Metric Collector
Select the type,

attributes, and/or
instance names.

3
Metrics are configured and collected in the scope of a diagnostic system module targeted to one or more
server instances. Therefore, to collect metrics, you must first create a diagnostic system module.
1. Click the name of the module for which you want to configure metric collection. Then click
Configuration > Collected Metrics.
2. To enable or disable all metric collection for this module, select or deselect the Enabled check box.
To set the period between samples, enter the period (in milliseconds) in the Sampling Period field.
To define a new collected metric, click New.
3. From the MBean Server Location drop-down list, select either DomainRuntime or ServerRuntime.
Then click Next. Select an MBean that you want to monitor from the MBean Type list. Then click
Next again.
4. In the Collected Attributes section, select one or more attributes from the Available list and move
them to the Chosen list (default is all attributes). Click Next.
5. In the Collected Instances section, select one or more instances from the Available list and move
them to the Chosen list (default is all instances). Click Finish.
6. Click Save.

WLST: Example
Create a diagnostic module and metric collector (harvester):
module = cmo.createWLDFSystemResource('JMSDebugModule')
module.addTarget(getMBean('/Servers/serverA'))
harvester = getMBean('/WLDFSystemResources/JMSDebugModule/
WLDFResource/JMSDebugModule/Harvester/JMSDebugModule')
harvester.setSamplePeriod(300000)
harvester.setEnabled(true)
harvestType = harvester.createHarvestedType
('weblogic.management.runtime.JMSServerRuntimeMBean')
harvestType.setEnabled(true)
harvestType.setHarvestedAttributes(['MessagesHighCount'])

CreateWLDF.py
Additional WLDF WLST examples can be found in the WLDF guide in the product documentation.
Refer to the following MBeans for more information about MBeans related to the diagnostic framework:
• WLDFResourceBean
• WLDFHarvesterBean (a subclass of WLDFResourceBean)
• WLDFHarvestedTypeBean (a component of WLDFHarvesterBean )
• WLDFInstrumentationBean (a subclass of WLDFResourceBean )
• WLDFInstrumentationMonitorBean (a component of WLDFInstrumentationBean )
• WLDFWatchNotificationBean (a subclass of WLDFResourceBean )
• WLDFWatchBean (a component of WLDFWatchNotificationBean )
• WLDFNotificationBean (abstract; subclasses exist for each notification type )
• WLDFRuntimeMBean
• WLDFImageRuntimeMBean (a component of WLDFRuntimeMBean )

Quiz Q
The Harvester is a WLDF component that:
a. Checkpoints performance metrics, received from the Collector, either to disk or database
b. Captures WebLogic runtime MBean data
c. Gathers statistics from the Oracle database
d. Uses a two-phase commit protocol to synchronize the collection of performance metrics
across the enterprise

Answer: b

Agenda
• Harvesters


Policies and Actions
Policies:
• Identify situations used to capture data
• Are used to analyze log records, data events, and harvested metrics
• Include expressions, alarms and action handlers
Actions:
• Are executed when an associated policy expression evaluates to true
• Include support for Scaling dynamic clusters, interacting with JMX, JMS, SMTP, SNMP,
REST and so on

GET
POST
Command line
cURL PUT
linux $>
DELETE
win c:\
JMS SNMP
REST SMTP WLST
A policy identifies a situation that used to trap for monitoring or diagnostic purposes. You can configure
policies to analyze log records, data events, and harvested metrics.
A policy includes:
• A policy expression (with the exception of calendar-based policies)
• An alarm setting
• One or more action handlers
You can configure policies to enable elasticity in dynamic clusters; for example, to automatically scale a
dynamic cluster up or down by a specific number of server instances. Policies support two categories of
elasticity:
• Calendar-based scaling: Scaling operations on a dynamic cluster that are executed on a particular
date and time
• Policy-based scaling: Scaling operations on a dynamic cluster that are executed in response to
changes in demand

An action is an operation that is executed when a policy expression evaluates to true. WLDF supports
the following types of actions:
• Scaling a dynamic cluster
• Java Management Extensions (JMX)
• Java Message Service (JMS)
• Simple Mail Transfer Protocol (SMTP), for example, email
• Simple Network Management Protocol (SNMP)
• REST
For policies to be useful, they must be associated with actions.
Policies and actions are configured separately from each other. An action can be associated with
multiple policies, and a policy can be associated with multiple actions. This provides the flexibility to
recombine and reuse policies and actions, according to current needs.

Policy Types
Policy Type Description
Smart Rules Use a set of prepackaged functions and configurable parameters that allow for the creation
of complex policy expressions combinations of functions and parameters
Calendar Based Are scheduled at a specific time, after a duration of time, or at timed intervals
Collected Metrics Use WLDF-provided beans and functions within policy expressions based on a variety of
MBeans including WebLogic Server Runtime, Domain Runtime, and JVM platform Mbeans.
Server Log Use various server variables to define policy expressions. Fields include SERVER,
MACHINE, SUBSYSTEM and so on

Domain Log Use various domain variables to define policy expressions
Event Data Use various event data generated by instrumentation and stored in the event archive
Policies are based on one of the six policy types:

• Smart Rules
• Calendar Based: Policy based on calendar or timed events such as a specific date and time, a
certain duration of time, or at specific intervals
• Collected Metrics: Policy based on WLDF-provided beans and functions and policy expressions.
Based on JavaBean objects that can obtain access to common WebLogic Server JMX data sources,
such as WebLogic Server Runtime, Domain Runtime MBean Server, and JVM platform MBeans.
• Server log: Policies based on a number of available log fields including SERVER, MACHINE,
SUBSYSTEM, THREAD, SEVERITY, USER ID and so on. See the WLDF Appendix C for a
complete list.
• Domain Log: Policies based on a domain log fields. See the WLDF appendix C for a complete list.
• Event Data: Policies based on event data, generated by instrumentation, and stored in the event
archives

Configuring Policies
1 In the administration console, select the Domain Structure pane.
2 Under the domain, select Diagnostics > Diagnostic Modules.
3 Select a Module name.
4 Select Configuration > Policies and Actions.

5 In the Policy subtab, click New.
To create a policy for a diagnostic system module:

1. Log in to the WebLogic console and in the Domain Structure pane.
2. Expand Diagnostics > Diagnostic Modules.
3. On the Summary of Diagnostic Modules page, click the name of the module to house the new policy.
4. On the Settings for [Module Name] page, select Configuration > Policies and Actions > Policies.
5. Select the Policies tab and click New.

Configuring Policies
6 Name the policy. 8 Configure the policy based on type.
Example
Smart Rule
...
Example

Server Log
7 Select a policy rule type.
6. On the Create Policy page, do the following:

a. Enter a name for the policy in the Policy Name field.
b. Select a policy type from the Policy Type list:
- Select Calendar Based to set a policy based only on a schedule.
- Select Smart Rule to set a policy based on a single built-in smart rule, evaluated on a
schedule.
- Select Collected Metrics to set a custom Java EL policy expression based on metrics
exposed through JMX, evaluated on a schedule.
- Select Server Log to set a policy based on data written to server logs.
- Select Domain Log to set a policy based on data written to the domain log.
- Select Event Data to set a policy based on data from an instrumentation event generated by
WLDF instrumentation monitors.
c. To enable or disable the policy, select or deselect the Enable Policy check box.
7. Click Next.
8. The pages that are displayed next vary based on the policy type you selected above.
9. Click Finish when you are done creating your new policy.
10. In the Change Center, click Activate Changes.

Configuring Actions
1 In the administration console, select the Domain Structure pane.
2 Under the domain, select Diagnostics > Diagnostic Modules.
3 Select a Module name.
4 Select Configuration > Policies and Actions.

7 Enter Name … click Next.
5 In the Actions subtab, click New.
6 Select a Type and click Next.

An action is an operation that is executed when a policy expression evaluates to true. WLDF supports the
following types of diagnostic actions, based on the delivery mechanism:
To create an action:
1. Log in to the WebLogic console and in the Domain Structure pane, click Lock & Edit.
2. Expand Diagnostics > Diagnostic Modules.
3. On the Summary of Diagnostic Modules page, click the name of the module to house the new policy.
4. On the Settings for [Module Name] page, select Configuration > Policies and Actions > Policies.
5. Select the Actions tab and click New.

6. On the Create Action page, select an action type from the Type list and click Next:
a. Select SMTP (E-Mail) to create an action that will deliver a notification through email.
b. Select JMS Message to create an action that will deliver a notification through JM
c. Select Diagnostic Image to capture a diagnostic image.
d. Select JMX Action to create an action that will deliver a notification through JMX.
e. Select SNMP Trap to create an SNMP trap.
f. Select Scale Up to create an action that will expand a dynamic cluster by a specified
number of dynamic server instances.
g. Select Scale Down to create an action that will reduce a dynamic cluster by a specified
number of dynamic server instances.
h. Select Script to create a script execution action.
i. Select REST to create an action that will deliver a notification through REST.
Note: Only one scaling action can be assigned to a given policy.

7. Enter a name for the action in the Action Name field.
Enter the timeout period in the Timeout (in seconds) field. The timeout period is the length of
time, in seconds, that an action has to complete execution before WebLogic Server attempts to
cancel it. By default, the timeout period is 0, which disables the action timeout.
To enable or disable the action, select or deselect the Enable Action check box, as appropriate.
Click Next. The page that is displayed next is different for each of the different action types,
listed above.

Configuring Actions
8 Complete the action.

8. Click Finish when you are done creating your new action.
9. In the Change Center, click Activate Changes.

Elastic Actions and Scaling
Elastic actions:
• Are used to increase or decrease the size of a dynamic cluster
• Are triggered when policy guidelines are met
• Are associated 1:1 with policy Only one elastic scaling action
per/policy.
• Are configured within domain-scope There may be other actions.
diagnostic system modules
• Are configured with scale-up/down-actions
inside wldf-resources

scaleUp
scaleDown
Elastic actions are actions used to scale up or down a dynamic cluster when certain policy conditions are
met, such as load or demand. The scale up and scale down actions are used to add or remove running
dynamic server instances from a dynamic cluster during scaling operations. Elastic actions can be
associated with policies. As a policy’s conditions are met, the elastic action is triggered and the scaling
operation begins. This type of scaling is called policy-based scaling. Only one elastic action can be
assigned to a policy. However, any number of non-scaling actions can be assigned to a policy, and elastic
actions can be used in conjunction with those non-scaling actions.
You can configure a scale up action in WLST using code similar to:
startEdit()
scaleUp=wn.createScaleUpAction('scaleUp')
scaleUp.setScalingSize(1)
scaleUp.setClusterName('DynamicCluster')
save()
activate()

Scale Up Action
Scale up actions add dynamic server instances to the specified dynamic cluster.
<wldf-resource>
<name>ClusterManager</name>

<scale-up-action>
<name>scaleUp</name>
<cluster-name>DynamicCluster</cluster-name>
<scaling-size>1</scaling-size>
</scale-up-action>


A resource descriptor contains the actual configuration of WLDF components and features within an XML
file. There are two types of resource descriptors:
• Configured:
- Is part of the domain configuration stored in $DOMAIN_HOME/config/diagnostics
- Is referenced by the config.xml file
- Can be deployed, activated, and deactivated dynamically
• External:
- Is external to the domain configuration
- Is not referenced by the config.xml file
- Is only deployed, activated, and deactivated dynamically, and can be administered only by
WLST
- Resides in memory of the server until the server is shut down
- Never gets persisted to the domain configuration

Scale Down Action
Scale down shuts down and removes dynamic server instances in the specified dynamic
cluster.
<wldf-resource>
<name>ClusterManager</name>

<scale-down-action>
<name>scaleDown</name>
<cluster-name>DynamicCluster</cluster-name>
<scaling-size>1</scaling-size>
</scale-down-action>


This slide shows a scale down XML example. The scale-down-action is specified within a watch-
notifications element which itself is within a wldf-resource element. The scale down element,
much like scale up, includes the name of the cluster as well as the scaling-size.
Similar code, but performed using WLST might resemble:
startEdit()
scaleDown=wn.createScaleDownAction('scaleDown')
scaleDown.setScalingSize(1)
scaleDown.setClusterName('DynamicCluster')
save()
activate()

Quiz Q
A policy identifies:
a. A specific set of policies types used to generate alerts
b. A situation that one wants to trap for monitoring or diagnostic purposes
c. A mechanism used to capture data based on logs, data, or harvested metrics used in
conjunction with actions
d. A notification mechanism used to alert administrators in case of suboptimal performance
e. A set of database tables or tables containing performance metrics

Answer: c

Summary
In this lesson, you should have learned how to configure the WebLogic Diagnostic
Framework (WLDF) to monitor a domain.


Practice 13-1 Overview: Using a Built-in Diagnostic Module

• Configuring a built-in diagnostic module
• Changing the settings of a built-in module
• Cloning and customizing a built-in module


14
WebLogic and Coherence Integration

Objectives
After completing this lesson, you should be able to configure:

• Coherence*Web
• Managed Coherence Servers


Agenda
• Coherence Overview
• Coherence*Web Session Replication


Oracle Coherence: Overview
Coherence:
• Provides a distributed, in-memory caching solution for Java
• Is based on a grid of cache servers or nodes
• Automatically distributes or partitions cached data across the grid based on the number
of servers
• Implements replication for high availability
• Includes a decentralized management and monitoring model based on JMX
• Supports a proxy architecture to provide connectivity beyond the Coherence cluster
• Supports additional languages such as .NET and C++

One of the primary uses of Oracle Coherence is to cluster an application’s objects and data. In the simplest
sense, this means that all the objects and data that an application delegates to Coherence are automatically
available to and accessible by all servers in the application cluster. None of the objects or data will be lost in
the event of server failure. By clustering the application’s objects and data, Coherence solves many of the
difficult problems related to achieving availability, reliability, scalability, performance, serviceability, and
manageability of clustered applications.
Oracle Coherence is a JCache-compliant, in-memory caching and data management solution for clustered
Java EE applications and application servers. Coherence makes sharing and managing data in a cluster as
simple as on a single server. It accomplishes this by coordinating updates to the cached data by using
clusterwide concurrency control, replicating and distributing data modifications across the cluster, and
delivering notifications of data modifications to any servers that request them. Developers can easily take
advantage of Coherence features by using the standard Java Collections API to access and modify data,
and by using the standard JavaBean event model to receive data change notifications.
Coherence provides a clusterwide view of management information through the standard JMX API, so that
the entire cluster can be managed from a single server. The information provided includes cache sizes
along with hit and miss rates.

Oracle Coherence: Overview
No data replication or
partitioning on these nodes Data replication and
partitioning across
these nodes
Grid
Application Cache Server
Replicated
data
provides a
Network
backup for
failover

Cached
Object
Partitioning refers to the ability of Coherence to load-balance data storage, access, and management
across all the servers in the cluster. For example, when using Coherence data partitioning, if there are four
servers in a cluster, each will manage 25% of the data. And if another server is added, each server will
dynamically adjust so that the five servers will manage 20% of the data. This data load balancing will occur
without any application interruption and without any lost data or operations. Similarly, if one of those five
servers were to fail, each of the remaining four servers would readjust to managing 25% of the data. Once
again, there is no data loss, including the 20% of the data that was being managed on the failed server.
While the partitioning feature dynamically load balances data evenly across the entire server cluster,
replication ensures that a desired set of data is always available and up-to-date at all times in the cluster.
Replication allows operations running on any server to obtain the data that they need locally, at basically no
cost, because that data has already been replicated to that server. The only downside of partitioning is that
it introduces latency for data access, and in most applications the data access rate far outweighs the data
modification rate. To eliminate the latency associated with partitioned data access, Coherence can employ
“near caching.” Frequently and recently used data from the partitioned cache are maintained on the specific
servers that are accessing that data within a near cache, and this local data is kept up-to-date by using
event-based invalidation.

Agenda
– Types of Session Persistence
– Coherence*Web
– Coherence*Web and WebLogic Clusters
– Coherence*Web Session Failover
– Configuring Coherence*Web in WebLogic


Types of Session Persistence
WebLogic Server supports several strategies so that the session information is not lost when
a server fails:
• In-memory session persistence
• File session persistence
• JDBC (database) session persistence
• Coherence*Web session persistence

Java web application components, such as Servlets and JavaServer Pages (JSPs), can maintain data on
behalf of clients by storing objects in an HttpSession. An HttpSession is available on a per-client basis.
After an instance of WebLogic Server creates a session for a client, it also writes a cookie to the client’s web
browser. This cookie indicates which server has this client’s session. The cluster proxy checks this cookie
on subsequent client requests, and routes the client to the instance of WebLogic Server that has the client’s
session.
If the server that has the client’s session fails, when the client makes their next request, they cannot be
routed to that server. The proxy chooses another server. That server does not have the client’s session, so
information about the client is lost.
To provide transparent failover for web applications, replication or persisted, shared access to the
information in each HttpSession object must be provided. This is accomplished in WebLogic Server by
using in-memory persistence, file system persistence, database persistence, or Coherence*Web
persistence. Each of these options is configured in the web application’s WebLogic deployment descriptor,
weblogic.xml. Each option has its own configurable parameters that are also entered in weblogic.xml.
Note that in-memory and JDBC persistence have two options: synchronous and asynchronous. The
asynchronous option persists data in batches to improve cluster performance.

Coherence*Web
• Is a plug-in that enhances WebLogic Server’s session management implementation with

a Coherence grid
• Provides a highly scalable session replication solution that can span WebLogic domains
and clusters
• Reduces WebLogic Server’s memory footprint
• Requires no changes to existing application code
• Allows session data to be shared across applications
• Can be enabled on an application basis

Coherence*Web is an application server plug-in dedicated to managing session state in clustered

environments. It brings the scalability, availability, reliability, and performance characteristics of a
Coherence data grid to in-memory session management and storage. Also, because it is not constrained by
the deployment topologies of the application server, it enables session sharing and management across
different web applications, domains, and even different application server products. Sometimes you may
want to explicitly prevent session data from being shared by different Java EE applications that participate in
the same Coherence cluster, so Coherence*Web supports this approach as well.
If sessions are shared across web applications, you may want to scope individual session attributes so that
they are either globally visible (that is, all web applications can see and modify these attributes) or scoped to
an individual web application (that is, not visible to any instance of another application). The latter approach
may be desired to help avoid namespace collisions when multiple applications use the same session
attribute names.
With Coherence*Web, session data is stored outside of the application server, thereby freeing server heap
space. This architecture also allows you to individually tune and scale the sizes of your application server
clusters and session data grids.

Coherence*Web and WebLogic Clusters
WebLogic clusters of servers with Cached HTTP

Coherence*Web configuration sessions
Coherence Distributed Data Grid

Cluster Cache Server
Cache Server
Cluster Network
Cache Server

Storage-disabled Storage-enabled
Coherence*Web is not a replacement for WebLogic Server's in-memory HTTP state replication services.
However, Coherence*Web should be considered when an application has large HTTP session state
objects, when running into memory constraints due to storing HTTP session object data, or if you have an
existing Coherence cluster and want to offload HTTP Session storage to a Coherence cluster.
Coherence*Web is configured with local storage disabled. This means that although the WebLogic server
instance is a member of the Coherence cluster, it is not a data storage member of the cluster. Storage-
disabled members rely on other Coherence cluster members to manage and replicate data.
By default, Coherence*Web creates a single HTTP session across all web applications for each client and
scopes the session attributes to each web application. This means that if a session is invalidated in one web
application, that same session is invalidated for all web applications in WebLogic Server that are using
Coherence*Web. If you do not want this behavior, a potential work-around is to edit the <cookie-path>
element of the weblogic.xml descriptor.

Coherence*Web Session Failover
Web Application
Coherence
Web
Java EE or Servlet Current
Container Sessions
Router
Web Application
Application
Coherence
Coherence
Web Load Web
tier balanced
Java EE
Java EE or
or Servlet
Servlet Application
Current

Container
Container State
Sessions
Clustered WebLogic Servers
In-memory
Coherence data grid
for session state
The diagram in the slide illustrates that if a server were to fail, if you lose the entire application server or a
JVM, Coherence still maintains the data. Therefore, you do not lose any session state information. Using
your existing infrastructure, the user session fails over to one of the other application servers, or the one that
is surviving. Therefore, no data is lost. The end user may not even notice that there is an outage. The user
session continues without the user even noticing that anything went wrong because Coherence manages
the data.
One common use case for Coherence clustering is to manage user sessions (conversational state) in the
cluster. This capability is provided by the Coherence*Web module, which is a built-in feature of Oracle
Coherence. Coherence*Web provides linear scalability for HTTP Session Management in clusters of
hundreds of production servers. It can achieve this linear scalability because, at its core, it is built on Oracle
Coherence dynamic partitioning.

Configuring Coherence*Web in WebLogic
1. Start one or more Coherence cache servers on your network.

2. Update each application’s weblogic.xml descriptor file and set the session
persistence type to coherence-web.
<weblogic-web-app>
<session-descriptor>
<persistence-store-type>
coherence-web
</persistent-store-type>
</session-descriptor>
</weblogic-web-app>
weblogic.xml

The WebLogic Server Coherence*Web plug-in consists of the coherence-web.jar and

coherence.jar files, located in the coherence/lib directory in the Coherence distribution. When
WebLogic is installed, these files are included in the WebLogic system classpath. The coherence-
web.jar file will load application classes from the appropriate WebLogic classloader so you do not have to
include Coherence JAR files in the web application's classpath. All Coherence*Web-enabled applications
running on WebLogic 12c (12.1.2) have application server scope. As a result, all applications become part
of the same Coherence node.
The Coherence caches used by Coherence*Web are configured by the default-session-cache-
config.xml file included in the coherence-web.jar file. Although the default configuration should be
sufficient for most deployments, it can be overridden by placing a session-cache-config.xml file in
your web application’s WEB-INF/classes folder. If you are using the default session cache configuration
file, you can package and deploy your applications just like any other Java EE application. However, if you
are using a custom session cache configuration file, you must package and deploy your application in a
GAR file.
Note: GAR files are covered later in this lesson.

Quiz Q
What is the primary purpose of Coherence*Web?
a. To use Coherence caching for application data
b. To integrate Coherence with application servers
c. To use Coherence caching for HTTP sessions
d. To use Coherence caching for client connections

Answer: c

Practice 14-1 Overview: Configuring Coherence*Web

• Configuring the default Coherence cluster in WebLogic to use multicast networking
• Configuring Coherence stand-alone cache servers to use the same cluster settings as
the WebLogic default Coherence cluster
• Starting Coherence cache servers
• Deploying the ShoppingCart application to WebLogic
• Testing Coherence*Web HTTP sessions


Agenda
– What Are Managed Coherence Servers?
– What Are Coherence Container Applications?
– What Are the Benefits of the Coherence Container
– Installing WebLogic with Coherence Support
– Coherence Grid Archives
– Coherence Cluster


Coherence and WebLogic Server
Oracle WebLogic 12c provides comprehensive support for

Coherence including:
• Managed Coherence servers: The ability to configure, start,
stop, and otherwise manage Coherence servers natively within a
WebLogic environment
• Coherence Grid Archives (GARs): A Java EE-like artifact that Deploy
encapsulates all the elements of a Coherence application into a
single deployable unit

WebLogic 12c provides two new features for Coherence.

• Managed Coherence servers: With earlier versions of WebLogic Server, developers could manage
Coherence by using WebLogic node manager. However, the process was often difficult and error-
prone, and ultimately took advantage of the management capabilities of only a WLS cluster to
manage Coherence instances. Coherence was still a stand-alone process. With WebLogic Server
12c, Coherence is fully integrated into WebLogic as a first-class member of the cluster, with the
ability to take advantage of all aspects of the Java EE as well as all aspects of WebLogic Server
management.
• Coherence Grid Archives (GARs): Additionally, Coherence applications are now first-class citizens
of a WebLogic Server cluster. Coherence artifacts, including all configuration and deployment
information, are packaged into a single file, known as a GAR. A GAR contains everything required to
deploy and run Coherence applications. To make this happen, WebLogic now supports an additional
container, often referred to as the Coherence Container. The Coherence Container provides all the
same services as an EJB or similar container to Coherence applications. Lifecycle, injection, startup,
shutdown, class management, isolation, and similar capabilities are provided for Coherence.

WebLogic Managed Coherence Servers
Operations
The WebLogic Server Container for Oracle Coherence:
Coherence ... Coherence
• Is a simplified model for managing operational Server Server
configuration Pre 12.1.2 Coherence Cluster
• Is conceptually similar to other Java EE containers 12.1.2 Coherence Cluster

WebLogic Machine
• Is fully integrated and installed with WebLogic and Domain
Node Manager
includes Coherence Admin

Server
• Is managed via the configuration wizard, WebLogic
Machine Machine
console, WLST, JMX, and Fusion Middleware Control
Node Manager Node Manager
• Manages Grid Archives (GARs) WebLogic/

... WebLogic/
Coherence Coherence
Server Server

Coherence cluster boundary
Traditionally, Coherence has been deployed as a JAR, incorporated into a Java application along with a tier
of stand-alone cache server JVMs. For example, the use of embedded Coherence from within a WAR, was
referred to as clients and the stand-alone cache servers were referred to as servers. The life cycles of the
“clients” and cache servers were managed separately, often manually. Application development and
deployment in this model was a complicated process involving many moving parts that required custom
management processes.
The WebLogic Server Coherence Container for applications provide tight integration between WebLogic
Server and Coherence and eliminate the difficulty of managing Coherence instances and applications in a
WebLogic environment. This integration allows for simplified and streamlined development and
management environments of distributed applications. The Coherence Container allows end users to build a
new archive type (GAR) that can be deployed and managed via standard WebLogic Server methods. Using
the Coherence Container:
• Developers can now streamline their build processes to Coherence applications
• Operations departments can now standardize deployment of Coherence instances and Coherence
servers

What Is a Grid Archive (GAR)?
Coherence applications or GARs:

• Are structurally similar to enterprise/web applications, but are packaged as a Grid
Archive with the extension .gar
• Define the elements required for deployment to the WebLogic Coherence Container
• Are composed of:
– A deployment descriptor, coherence-application.xml
– A cache configuration, named in the deployment descriptor
– Java classes including entry processors, event handlers, filters, application classes,
and others
– Optional support libraries

Coherence applications are packaged into Grid Archive or GAR files. In general, a GAR contains all the
artifacts required to service a particular cache or invocation request and mirrors, to a high degree, the
structure of other Java EE artifacts, such as web archives. Specifically, a GAR contains:
• A deployment descriptor, coherence-application.xml, which defines the location of a cache
configuration as well as a variety of other content such as POF configuration. The deployment
descriptor may include references to several other optional elements, such as lifecycle handlers.
• A cache configuration, referenced from the deployment descriptor
• Java classes representing the application. These classes typically include the entities and other
application classes, POF support, entry processors, event handlers, and similar classes.
• A set of optional library JAR files
The entire set of classes is encapsulated into a JAR known as a Coherence Grid Archive, which mirrors
similar constructs for web applications, enterprise applications, and JAR files in general.
GAR files are also deployable directly to stand-alone Coherence (without WebLogic present at all),
reinforcing their JAR-like structure.

Coherence Application Deployment on WebLogic
Coherence applications can be deployed in several ways:

• Stand-alone: GAR is deployed to a server by itself.
It is analogous to the traditional default cache server. Coherence
Server
• Java EE: The application is included as part of: GAR
– Web Application (WAR): GAR resources available to WAR only

Coherence
– Enterprise Application (EAR): GAR resources Server
available to WAR and other Java EE resources, GAR
EAR
such as EJBs WAR
• Shared library: GAR resources are available to all WARs and EARs
Coherence
located on the server. Server

JAR
EAR
WAR
GAR
Coherence applications can be deployed in several ways. Deployment models include:

• Stand-alone: A stand-alone deployed Coherence application exposes caches to applications, but
does not expose resources directly to WAR or EAR files. Such a deployment is most common when
configuring a data tier.
• Java EE: GAR files can be deployed as components of a WAR or an EAR file. Such deployments
make Coherence resources available to the WAR and/or EAR directly. EJBs, web applications,
JSPs, and other Java EE artifacts can use dependency injection to access a cache resource. Such a
deployment scopes the caches to the EAR itself. An identical deployment, to a different EAR, would
result in a similar set of caches, but scoped to the EAR/WAR.
• Shared library: With a shared library deployment, similar to a stand-alone deployment, all WAR and
EAR artifacts can access the cache resources directly.

Coherence Container: Benefits
• Simplified installation: Coherence and WebLogic installed together

Stand-alone Coherence
• Simplified operations management:
is still supported.
– Configure, manage, and deploy Coherence applications from the WebLogic
administration console and WLST.
– Manage Coherence resources centrally.
WebLogic to Coherence Coherence benefits to WebLogic

• Simplified application packaging

• Instance management • Multiple deployment models
• Dependency injection – Stand-alone (GAR)
• Application lifecycle management – GAR within web application
• Scripting support (deployment etc) – GAR within Enterprise application
– Shared library
With WebLogic Server 12c, Coherence is provided and installed with WebLogic Server. Both WebLogic
Server and Coherence provide services to each other.
WebLogic Server provides several services to Coherence, including:
• Coherence, separate from WebLogic, cluster, member, and application management and scoping.
Applications can be scoped to be stand-alone, WAR, EAR, or shared library scoped. Coherence also
provides a cache-level scoping mechanism much like namespaces for caches and data.
• Packaging: Available on the system classpath, simplifying packaging
• Management: Coherence is now a first-class member of the cluster and fully supported by the
console and WLST.
• Instance support: Full support for creating and managing Coherence instances
• Application support: Full support for application development and runtime life cycle
• Cluster support: Full support for defining and managing Coherence Clusters

Coherence Cluster
Coherence clusters consist of multiple, managed Coherence server instances.
M'ged Coherence M'ged Coherence M'ged Coherence

Managed Coherence server can: server server server
• Be storage enabled or disabled GAR
Storage-enabled
GAR
Storage-enabled
... GAR
Storage-enabled
• Share configuration and Data-tier WLS cluster
overrides
• Have one or more deployed Coherence Coherence Coherence
Coherence applications server server
... server
EAR
EAR
EAR
GAR GAR GAR
WAR WAR WAR

Storage-disabled Storage-disabled Storage-disabled
Web-tier WLS cluster
Coherence clusters are a mechanism for logically grouping sets of managed Coherence servers. In general,
Coherence clusters consist of multiple managed Coherence servers, which together form a distributed data
grid. Coherence clusters are different from WebLogic Clusters in several ways. First and foremost
Coherence clusters often span multiple WebLogic clusters and are intended to represent Coherence
servers, which logically represent a single data grid. Additionally, Coherence clusters use different clustering
protocols, ports, and are configured separately from WebLogic Clusters. Managed Coherence servers can
be associated with a Coherence cluster or with a WebLogic Cluster, which itself is associated with a
Coherence cluster.
Typically, a Coherence cluster is associated with one or more WebLogic Clusters, which together represent
a tiered architecture, typically having data, web, and proxy tiers. In the sample shown, two WebLogic
Clusters, a data-tier cluster and a web-tier cluster, are defined. These two WebLogic Clusters are bound
together into a single Coherence cluster. Typically, such a cluster shares a set of Coherence configurations
and applications. In the example shown, the same Coherence GAR is deployed to each Coherence
managed server, but packaged differently. On the data tier, the application is packaged as a simple GAR
and deployed stand-alone. On the web tier, the same GAR is packaged as a component of an EAR and
accessible from any other Java EE application within that EAR.

Managed Coherence Server
A domain can have zero or more managed Coherence servers.

A managed Coherence server:
• Is a WebLogic managed server that encapsulates a Coherence instance
• Can be storage enabled or disabled
• Can host Coherence applications
• Must be a member of a Coherence Cluster
Coherence Cluster

Managed Managed Managed Managed
Coherence Coherence Coherence Coherence
server server server server
Managed Coherence servers are server instances that are associated with a Coherence cluster. These
servers work together and collectively form a Coherence cluster. Members of a Coherence cluster are
historically referred to as Coherence instances, and are referred to as managed Coherence servers within a
WebLogic installation. However, managed Coherence servers are not the same as Coherence servers.
Managed Coherence servers are specific to the WebLogic Server Coherence Container integration. The use
of Coherence servers, a resource defined in the previous ActiveCache integration, is deprecated. Managed
Coherence servers conceptually are no different from earlier Coherence server instances running
stand-alone, but there are differences. Some of the differences include:
• Managed Coherence servers that are managed within a WebLogic Server domain must not join an
external Coherence cluster comprised of stand-alone JVM cluster members.
• Stand-alone JVM cluster members cannot be managed within a WebLogic Server domain.
• The administration server is typically not used as a managed Coherence server in a production
environment.
Managed Coherence servers are distinguished by their role in the cluster, and can be:
• Storage enabled: A managed Coherence server that is responsible for storing data in the cluster.
Coherence applications are packaged as Grid Archives (GARs) and are deployed on storage-
enabled managed Coherence servers.
• Storage disabled: A managed Coherence server that is not responsible for storing data and is used
to host Coherence applications (cache clients). A Coherence application GAR is packaged within an
EAR and deployed on storage-disabled managed Coherence servers.
• Proxy: A managed Coherence server that is storage disabled and allows external clients (non-
cluster members) to use a cache. A Coherence application GAR is deployed on managed
Coherence proxy servers.

Quiz Q
Which two of the following are supported by GAR deployments?
a. GAR files do not support deployment
b. Deployment to standalone Coherence without WebLogic
c. Deployment to a WebLogic server within an EAR file
d. None of the above

Answer: b, c

Summary
In this lesson, you should have learned how to configure:

• Coherence*Web


Practice 14-2 Overview: Configuring Managed Coherence Servers

• Configuring a new Coherence cluster
• Deploying a stand-alone GAR application
• Deploying an EAR application with an embedded GAR
• Configuring Coherence cluster settings
• Testing the Coherence cluster


15
Application Staging and Deployment Plans

Objectives

• Configure a server’s staging mode
• Create and use deployment plans


Agenda
• Review:
– Java EE applications
– Deployment
• Server staging modes
• Deploying an application to multiple environments
• Java EE deployment descriptors and annotations
• Deployment plans
• Deployment plan tools


Review: Java EE Applications
Web
container
Java
APIs
EJB
Container
Clients Back-end
Application systems

server and
databases
Java Virtual Machine (JVM)
Hardware
The Java Enterprise Edition (EE) platform consists of the following:

• Application components including enterprise applications (EAR), web applications (WAR), applets,
servlets and JSPs, Enterprise JavaBeans (EJB), and so on
• The containers that provide the runtime support for the components
• Resource manager drivers that implement network connectivity to external resource managers
• Various specifications and application program interfaces (APIs) including Java Transaction API
(JTA), Java Database Connectivity (JDBC), Java Message Service (JMS), and Java Naming and
Directory Interface (JNDI)
All of this Java code runs within a Java Virtual Machine (JVM).

Review: Deployment
2
4
Managed
The administrator uses a tool, server
such as the admin console, to Clients
1 communicate with the admin
server and deploy the application.
The deployment is pushed
out to target servers. The
3 The archive is uploaded to deployed application is
the admin server and the “turned on” to start
The developer develops deployment is targeted. servicing client requests.

the application and The admin server updates
provides the archive file the domain configuration.
to the administrator.
Admin
server
1. First, an application must be developed, tested, and packaged (usually as an application archive).
2. The application archive file is placed somewhere that an administrator in charge of deployment can
access it. A deployment tool, like the administration console, is used to communicate with the
administration server of the domain, which is in charge of any configuration changes, including
application deployment.
3. The deployment tool gives the administration server access to the application, and allows the
deployment administrator to target a server (or servers) on which to run the application. The
administration server updates the domain’s configuration.
4. The administration server pushes the application’s code out to the target managed server (or
servers). After the application is “activated” (told to start servicing requests), it becomes accessible to
clients.

Agenda
• Review
– Staged mode example
– No stage mode example
– External stage mode example
– Configuring the staging mode


Server Staging Modes
You can configure

deployment per server
or for each application.

WebLogic provides you with control over whether or not, where, and by whom application files are copied
before being deployed. All applications that are targeted to the managed servers can be copied by the
administration server to the managed server before being prepared. This is called staging, and the files are
staged to a configurable staging area for each server. There are three kinds of staging:
• stage: (default) Files are copied to the preconfigured staging directory for preparation and
activation.
• nostage: Files are deployed from a static location.
• external stage: Files are copied by a user or a third-party tool (for example, JDeveloper or
Eclipse) before deployment.
Applications can be deployed from the source location by changing the configuration (StagingMode). If the
managed servers are running on a machine other than the administration server, it means that either the
source location is on a file system that is accessible to the managed server (StagingMode = nostage) or
the user or third-party tool performs the copy before the deployment request is issued (StagingMode =
external stage).

Staged Mode Example
The administration server first copies the deployment files to the staging directories of target
servers.
Machine B
Machine A
Managed server 1
3 Deploy
Admin
server Application
1 Distribut
e 4 Deploy to
Copy files to 2 server

staging DOMAIN_HOME/servers/server1/stage
folder
When a server is configured with the stage staging mode, it causes the administration server to first
distribute deployment files to the server’s configured stage folder so the files are available to the server for
the deployment process. This staging mode is best used for small to medium-sized applications to multiple
WebLogic Server instances or a cluster. If applications are very large in size, then other staging modes may
provide a better deployment experience. The stage mode deployment process involves:
1. The first aspect of the deployment process causes the administration server to execute the
distribution process, which copies the deployment's files to the stage folder that is configured for the
target server.
2. The administration server copies the files to the stage folder of the server instance. This is done by
sending the files to the server instance and the instance places the files in its staging folder.
3. After the distribution phase of deployment is complete, the administration server executes the
deployment process on all targeted servers.
4. The target server receives the deployment command, performs its internal preparation of the
deployment, and performs the actual deployment of the application on the server.

No Stage Mode Example
The administration server does not copy deployment files. All servers deploy the same
physical copy of files from a location that is accessible to all servers.
Machine B
Machine A
Managed server 1
1 Deploy
Admin
server application

2 Deploy to
server
/nfshome/application_repository
Shared file system
When a server is configured with the nostage staging mode, the administration server only issues the
deployment command to all targeted servers because the files are already accessible to all servers
involved. When the nostage staging mode is used in conjunction with exploded deployment files,
WebLogic automatically detects changes to web components and refreshes the deployment to reflect the
latest state. This staging mode is best used for deploying:
• To a single server domain because all files would be local to the administration server by default
• To a cluster on a multihomed machine to avoid multiple copies of the same files on one machine
• Very large applications to multiple targets to avoid multiple copies that take up a lot of disk space
and to leverage the infrastructure of a shared file system for faster deployments
• Exploded deployments to refresh any changes
• Applications that require dynamic updates of deployment descriptors
The nostage mode deployment process involves the following steps:
1. The administration server executes the deployment process on all targeted servers.
deployment and the actual deployment of the application on the server using the files available on
shared storage.

External Stage Mode Example
The administration server does not copy deployment files. The administrator must ensure
that all files are distributed and available to all servers before deployment.
Machine B
Machine A
Managed server 1
2 Deploy
Admin
server Application
3 Deploy to

server
DOMAIN_HOME/servers/server1/stage
1 Copy files to
staging
folder
When a server is configured with the external stage staging mode, the administration server does not
take responsibility for distributing deployment files to targeted servers. The WebLogic administrator must
ensure that all deployment files are distributed before performing a deployment. File distribution can take
place in the form of running a script, using a third-party tool, manually copying files, and so on. All that
matters is that the files are distributed before performing a deployment. When using the external stage
staging mode, the administration server requires a copy of the deployment files, which it uses for validation
purposes during deployment. WebLogic supplies the -noversion option to disable this requirement, but
this also renders production redeployment impossible.
This staging mode is best used for deployments:
• Where an administrator requires or wants manual control over file distribution
• Where other mechanisms used in operations procedures manage file distribution, such as scripts or
third-party systems
• That do not require dynamic updating or partial redeployment
The external stage mode deployment process involves:
1. The WebLogic administrator performs the operational process that copies deployment files to the
stage folder that is configured for the target server.
2. The WebLogic administrator performs a deployment operation on WebLogic. The administration
server executes the deployment process on all targeted servers.
deployment, and performs the actual deployment of the application on the server.

Configuring the Staging Mode
Override default
server staging mode
during deployment

The server staging mode specifies a staging mode for a server when no staging mode is indicated at the
time of deployment. The default staging mode for the administration server is nostage, and the default
staging mode for managed servers is stage. You can configure the staging mode of a server using the
administration console by selecting a server's Configuration > Deployment tab. This page provides three
fields for configuring the server's staging mode:
• Staging Mode: This is where you specify the default staging mode used by this particular server.
• Staging Directory Name: This is the relative path to the folder where deployment files are stored for
this server before deployment.
• Upload Directory Name: When a remote client not running on the machine where the
administration console is located is used to deploy an application, such as WLST, the command
uploads the deployment files to this upload folder on the administration server. This specifies a
relative path of the administration server used before beginning the staging and deployment process.

Quiz Q
The ___________ staging mode requires that all servers have shared access to deployment
files.
a. Stage
b. No Stage
c. External stage
d. Shared stage

Answer: b

Agenda
• Review
– Development to test to production
– Examples of deployment descriptor values to change


Development to Test to Production
Applications are deployed to several different environments during a full development life
cycle:
MyEJB.jar MyEJB.jar MyEJB.jar

application application application
WebLogic Server WebLogic Server WebLogic Server
Development Testing Production

Each deployment environment requires
different configuration properties.
The full development life cycle of a WebLogic application involves some variation of development, test, and
production environments. Whether it includes multiple levels of any of these environments is irrelevant, such
as a development environment for each individual developer and an integrated development environment to
see how components coexist with components from other developers. The main point is that the application
is going to begin in a development phase, graduate to a testing environment, and graduate again into a live
production environment. Each environment presents a new ecosystem in which the application gets
deployed. The application must be able to adapt accordingly in order to function in each environment. This
means that the application’s configuration properties must change from one environment to the next.

Examples of Deployment Descriptor Values That Can Change
Deployment Descriptor Description Example Properties
web.xml Contain standard and WebLogic specific Standard:

properties for web applications <login-config>
weblogic.xml
WebLogic:
<context-root>
ejb-jar Contain standard and WebLogic specific Standard:

properties for EJB applications <jta-data-source>
weblogic-ejb-jar
WebLogic:
persistence.xml <jndi-name>
application.xml Contain standard and WebLogic specific Standard:

properties for enterprise applications <library-directory>
weblogic-
application.xml WebLogic:
<min-threads-constraint>
<coherence-cluster-ref>

Agenda
• Review
– Java EE deployment descriptors
– Java EE annotations
– appmerge and appc


Java EE Deployment Descriptors
EJB
EJB (JAR) Deployment descriptor
EJB ejb-jar.xml J2EE Enterprise
weblogic-ejb-jar.xml
Application (EAR)
EJB
application.xml
Web application (WAR) weblogic-application.xml
Web web.xml
weblogic.xml
Web
EJB-JAR
Application client (JAR)
weblogic-appclient.xml WAR

JAR
Resource adapter (RAR)
RAR
weblogic-ra.xml
Java EE deployment descriptors configure Java EE application features. These configuration settings are
different depending on the type of component the descriptor represents. Deployment descriptors are useful
because they are external to the code of an application and provide a way for developers to include
configuration settings along with their applications. The drawbacks to deployment descriptors include:
• Sometimes difficult to learn and format because each is defined by an XML schema that is not visibly
available when editing files. Administrators are not typically familiar with an application’s code and it
is possible that they lack the knowledge required to make descriptor changes directly.
• Difficult to modify because components are typically provided in the form of a packaged archive file
with the descriptors contained within the archive. Modification requires unpacking the archive,
modifying the descriptors, and repacking the archive correctly. Descriptors almost always require
some modification during the full development life cycle when they move from development to test,
and then from test to production.

Annotations
package com.examples;
@Stateless
@Local(MyEJBInterface.class)
public class MyEJB {
@Resource(mappedName = "jdbc/employeeDatabase")
private DataSource myDS;
...
} MyEJB.java
MyEJB.jar
.. <ejb-jar>

..
@Stateless <ejb-jar>
...
..@Stateless ...
</ejb-jar>
.. </ejb-jar> DEPLOY WebLogic
Server
Annotated Deployment
classes descriptors
A Java annotation is a way of adding metadata to Java source code that is also available to the program at
run time. Annotations are an alternative to deployment descriptors, that were required by J2EE 1.4 and
earlier. In fact, Java EE metadata annotations now make standard deployment descriptors optional.
Annotations are realized by WebLogic during deployment, just like deployment descriptors. Developers use
annotations to simplify development, by specifying within the Java class how the application component
behaves in the container. Annotations make development easier, but how do they affect administrators?
• Developers are no longer required to create deployment descriptors to configure their components.
As a result, some configuration hooks that would have previously been present in the descriptors of
components passed from developers to administrators are no longer available by default.
• Administrators have no visibility into what configuration is contained within the annotations of Java
source files by default. This is because components passed to administrators for deployment do not
include source code, and administrators are not always developers who understand the syntax of
annotations.
These situations are avoided by following some best practices and leveraging some tools that make the
configuration provided by annotations visible to administrators.

appmerge and appc
WebLogic provides tools to debug annotations and deployment descriptors. These tools can
work together to troubleshoot problems in your configuration.
-writeInferredDescriptors flag metadata-complete attribute
$ java weblogic.appmerge \ <ejb-jar

-writeInferredDescriptors \ metadata-complete="true">
-output app.debug/app.jar \ ...
MyEJB.jar </ejb-jar>
Command line ejb-jar.xml

weblogic.appmerge is a tool that is used to merge libraries into an application, with merged
contents and merged descriptors. It is often used when multiple versions of libraries are required.
WebLogic’s appmerge and appc tools have a “-writeInferredDescriptors” flag to see how the
container views the configuration of deployments.
These tools process the descriptors and annotations of your component like the container does and write
everything out to descriptors for you to review.
The example in this slide shows how to use “–writeInferredDescriptors” with the appmerge tool.
The “–writeInferredDescriptors” flag automatically sets “metadata-complete” to true in
deployment descriptors.
Setting “metadata-complete” to true in a deployment descriptor instructs annotation processors to ignore
the annotations in your deployments and only use what is contained in deployment descriptors.
The example shows the “metadata-complete” attribute set to true.
As an administrator, you will most likely not execute the appc tool because you do not customarily compile
Java EE programs. You will find using appmerge to be a productive tool for making the configuration of
your applications more visible.

Managing Precedence
Remember to use the following options with appmerge to see how WebLogic is interpreting
your deployments:
-writeInferredDescriptors flag metadata-complete attribute
$ java weblogic.appmerge \
-writeInferredDescriptors \
<application
-library jstl \
metadata-complete="true">
-librarydir myLibPath \
...
-plan myPath/plan.xml \
</application>
-output app.debug/app.ear \
MyEAR.ear Command Line application.xml

weblogic.appmerge is a tool that is used to merge libraries into an application, with merged
contents and merged descriptors. It is often used when multiple versions of libraries are required.
WebLogic’s appmerge tool enables you to see how the container views the configuration of your
deployments that include shared libraries. As an administrator, you will find using appmerge to be a
productive tool for seeing how WebLogic processes the configuration properties of your deployments. Note
that now you can include the arguments for shared libraries and a deployment plan. From the Java Servlet
specification:
The web application deployment descriptor contains a metadata-complete attribute on the web-app
element. The metadata-complete attribute defines whether the web.xml descriptor is complete, or
whether other sources of metadata used by the deployment process should be considered. Metadata may
come from the web.xml file, web-fragment.xml files, annotations on class files in WEB-
INF/classes, and annotations on classes in jar files in the WEB-INF/lib directory. If metadata-complete
is set to "true", the deployment tool only examines the web.xml file and must ignore annotations such as
@WebServlet, @WebFilter, and @WebListener present in the class files of the application, and must
also ignore any web-fragment.xml descriptor packaged in a jar file in WEB-INF/lib. If the metadata-
complete attribute is not specified or is set to "false", the deployment tool must examine the class files
and web-fragment.xml files for metadata, as previously specified.

Quiz Q
Developers use Java EE annotations. Why are they important to administrators?
a. Because some annotations are realized as deployment properties
b. Because annotations override deployment descriptor properties
c. Annotations are not important to administrators
d. All of the above

Answer: a

Agenda
• Review
– What is a deployment plan?
– Using deployment plans for different environments
– Deployment plan example
– Staging deployment plans


What Is a Deployment Plan?
A Java EE deployment plan:

• Is an optional XML file associated with an application
• Resides outside an application archive
• Sets or overrides the values in Java EE deployment descriptors and annotations
• Allows easy customization of a single application for deployment to multiple deployment
environments
plan.xml DEPLOY TestServer

QADataSource
MyEJB.jar

ejb-jar.xml
plan.xml
ProdDataSource DEPLOY ProdServer
A deployment plan is an XML document that is used to define an application’s deployment configuration for
a specific Oracle WebLogic Server environment, such as development, test, or production. A deployment
plan resides outside of an application’s archive file and contains deployment properties that override an
application’s existing Java EE and Oracle WebLogic Server deployment descriptors. Use deployment plans
to easily change an application’s Oracle WebLogic Server configuration for a specific environment without
modifying the existing deployment descriptors. Multiple deployment plans can be used to reconfigure a
single application for deployment to multiple, differing Oracle WebLogic Server domains or servers.
Any external resources required by the application are subject to change when the application is deployed
to a different environment. For example, the Java Naming and Directory
Interface (JNDI) names of the data sources that are used in your development environment can be different
from those used in testing or production. Exposing those JNDI names as variables makes it easy for people
deploying applications to use the available resources or create the required resources when deploying the
application.
Certain tuning parameters that are acceptable in a development environment are unacceptable in a
production environment. For example, it may suffice to accept default or minimal values for EJB caching on
a development machine, whereas a production cluster would need higher levels of caching to maintain
acceptable performance. To deploy the application to a new environment, an administrator simply creates or
uses a new deployment plan as necessary.

Using Deployment Plans for Different Environments
MyEJB.jar
contains the deployment descriptor
weblogic-ejb-jar.xml.
1 2 3
Oracle WebLogic Server Oracle WebLogic Server Oracle WebLogic Server
Development Testing Production
uses uses uses
DevDataSource QADataSource GADataSource
QAPlan.xml ProductionPlan.xml
<variable> <variable>
<name> <variable>
<name> <name>
myresource myresource
IdleTimeout

No Plan </name> </name> </name>
<value> <value> <value>
QADataSource GADataSource 200
</value> </value> </value>
</variable> </variable> </variable>
1. Development: A developer develops and creates both Java EE and WebLogic Server deployment
descriptors to configure the application for repeated deployments to the development environment.
The development server uses a simple Derby database for development, named
“DevDataSource,” and the weblogic-ejb-jar.xml descriptor identifies the resources for the
application.
2. Testing: The developer packages the application into an archive file and delivers it to the
administrator in the QA team. The testing environment uses a different data source named
“QADataSource.” At this point, the embedded deployment descriptors provide a configuration that is
valid for the development environment used by the developer, but is not valid for the testing
environment where the application must be deployed for testing. To deploy the application, the
administrator of the testing environment generates a deployment plan QAPlan.xml to override the
data source name configured in the application’s embedded deployment descriptors.
3. Production: Similarly, when the application is released into production, the administrator of the
staging or production environment creates or uses another deployment plan to configure the
application. The production deployment plan ProductionPlan.xml again overrides the
application deployment descriptors to identify a new JDBC data source “GADataSource” that is
used by the production environment. For this environment, the deployment plan also defines tuning
parameters to make better use of the additional resources that are available in the production
domain.

Organizations that have numerous deployment environments that frequently change should use a
configuration workflow with multiple deployment plans. In a multiple deployment plan workflow, each
deployment plan is owned by the deployer of the application rather than the development team. You should
store each deployment plan for a single application in its own plan subdirectory of the application’s root
directory. The multiple deployment plan configuration workflow works in the following way:
1. The development team releases a version of the packaged application deployment files (containing
Java EE and WebLogic Server descriptors). The development team may or may not include a
template deployment plan with exported variables for resource definitions or common tunable
parameters.
2. Before deploying the application, each deployer generates a custom deployment plan to configure the
application for the respective target environment. A custom deployment plan can be created by
starting with a template deployment plan (or no deployment plan) and making changes to the
application’s deployment configuration using the Administration Console.
3. After defining the deployment configuration for the respective environment, each deployer retrieves
the custom deployment plan and maintains it for future deployments of the application. It is

recommended that you store the custom configuration plans in a source control system so that new
versions can be tracked and reverted if necessary.
4. For subsequent releases of the application, each deployer uses the respective customized
deployment plan to configure the application for deployment. Using the customized plan allows
people deploying applications to perform deployments with weblogic.Deployer or automate
deployments using WLST.

Deployment Plan Example
root-element
persistence-unit[name="AuctionPU"]
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="AuctionPU" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/AuctionDB</jta-data-source>
<class>com.oracle.model.Auction</class>
<class>com.oracle.model.Image</class>
<class>com.oracle.model.Bid</class>
<properties> Original value
</properties>
</persistence-unit>
jta-data-source

</persistence> persistence.xml
XPath to value:
/persistence/persistence-unit[name="AuctionPU"]/jta-data-source
This slide shows an example of a deployment descriptor for a Java Persistence API (JPA) component,
called persistence.xml. This file contains the configuration of a data source JNDI name used to access
the database connections required for the related component. The current value contained within the
descriptor that is packaged within the deployed archive is jdbc/AuctionDB.
For those who may not be familiar with XPath, this slide shows the syntax used to pinpoint the element that
contains the value of the JNDI name of the data source in this file. Following from left to right in the XPath
statement, the first element is persistence. The next element is persistence-unit, but it also
contains criteria to distinctly identify which persistence-unit element using [name="AuctionPU"].
The next element is jta-data-source, which contains the target value you want to change.

Deployment Plan Example
<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan
http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">
<application-name>SimpleAuctionWebAppDbSec.war</application-name>
<variable-definition>
<variable>
<name>PersistenceUnit_AuctionPU_jtaDataSource_13620081523747</name>
<value>jdbc/AuctionDBTest</value>
</variable>
</variable-definition>
<module-override>
<module-name>SimpleAuctionWebAppDbSec.war</module-name>
Put this new value
<module-type>war</module-type>
. . .
<module-descriptor external="false">
<root-element>persistence</root-element> Into this element
<uri>WEB-INF/classes/META-INF/persistence.xml</uri>
<variable-assignment>
<name>PersistenceUnit_AuctionPU_jtaDataSource_13620081523747</name>
<xpath>/persistence/persistence-unit[name="AuctionPU"]/jta-data-source</xpath>

<operation>replace</operation>
</variable-assignment>
</module-descriptor>
</module-override>
<config-root>/apps/plan</config-root>
</deployment-plan> Plan.xml
This slide shows a deployment plan that is used to override the jdbc/AuctionDB value set in the original
persistence.xml file shown in the previous slide to jdbc/AuctionDBTest.
The basic elements in a deployment plan serve the following functions:
• deployment-plan: Encapsulates the deployment plan’s contents
• application-name: Corresponds to the deployment name for the application or module
• variable-definition: Defines one or more variable elements. Each variable element defines
the name of a variable that is used in a plan and a value to assign, which can be null. In this
example, the variable is PersistenceUnit_AuctionPU_jtaDataSource_13620081523747
with a value of jdbc/AuctionDBTest, which is the new JNDI name of the data source for the
AuctionPU persistence unit defined in the application's persistence.xml file. The variable name
of this variable is matched with the name of a variable assignment defined in the module-
override section below.

• module-override: Elements that define each module name, type, and deployment descriptor that
the deployment plan overrides. A module-descriptor element can optionally contain a
variable-assignment that identifies a variable name that is used to override a property in the
descriptor and the exact location within the descriptor where the property is overridden. In this
example, the module-descriptor for the persistence.xml file is defined and the elements
are:
– root-element: The name of the root XML element contained in the file specified by the
<uri> element
– uri: The relative path to the descriptor file that this <module-descriptor> element
represents
– variable-assignment: Contains a list of variable assignment definitions used to indicate
which element within the descriptor XML file gets overridden
– name: The name that is matched against the name of the variable-definition
section
– xpath: The XPath syntax used to isolate the exact element to modify within the original

descriptor XML file
– operation: Set to replace or remove. Use replace to override the original value and
remove to remove the original value from the configuration.
• config-root: The path where the deployment plan XML file is located
Note: You can change the generated name
PersistenceUnit_AuctionPU_jtaDataSource_13620081523747 to any name you want. This
name was originally generated by the administration console when creating the initial deployment plan.
The name is insignificant and is only used for matching the variable definition section with the variable
assignment section. It is initially generated so that the name is descriptive enough to indicate which setting
is represented.

Staging Deployment Plans
WebLogic allows you to specify staging for deployment plans:

Staging Description
-planstage Copies the deployment plan to the target server's staging directory
-plannostage Does not copy and instead leaves deployment plan in a fixed location
-planexternal_stage Does not copy and requires a separate copy step prior to deployment
$ java weblogic.Deployer \
-adminurl http://host01.example.com:7001 -username weblogic \
-password Welcome1 -deploy -targets cluster1 \
-plan /plans/prod/plan.xml \
-planstage /deployments/AuctionDbLib.war Command Line

> deploy(appName='MyApp',
path='/apps/MyApp.ear',
targets='cluster1',
planPath='/plans/prod/plan.xml',
planStageMode='stage') WLST Command Line
Planstage is the default if no deployment plan staging options are specified. Deployment plan staging allows
you to specify different staging options for applications and deployment plans.

Quiz Q
Which is NOT true about the deployment plans in WebLogic?
a. Overrides values in application descriptors
b. Can be created by WebLogic during deployment
c. Is packaged within an application archive
d. Is an XML file

Answer: c
Remember that deployment plans are not packaged within an application, so that the same application can
be reused in multiple deployment environments.

Agenda
• Review
• Java EE deployment descriptors
– Creating a deployment plan
– weblogic.PlanGenerator
– Using plan generator

– Administration console

Creating a Deployment Plan
• Tools for creating a deployment plan:

– Administration Console
– WLST
– weblogic.PlanGenerator
– Development tool (for example, JDeveloper or Eclipse)
• Goals for creating a deployment plan:
– To expose the external resource requirements of the application as variables in the
deployment plan
– To expose additional configurable properties, such as tuning parameters as variables
in the deployment plan

• Exporting an application’s deployment configuration is the process of creating a custom deployment

plan that administrators can use for deploying the application to new WebLogic Server
environments. You distribute both the application deployment files and the custom deployment plan
to deployers; for example, testing or production administrators, who use the deployment plan as a
blueprint for configuring the application for their environment.
• An administrator can install both the application and the custom deployment plan by using the
administration console, which validates the deployment plan and indicates when specific
configuration properties must be supplied before deployment.
• weblogic.PlanGenerator creates a template deployment plan with null variables for selected
categories of deployment descriptors. This tool is recommended if you are beginning the export
process and you want to create a template deployment plan with null variables for an entire class of
deployment descriptors. You typically need to modify the deployment plan created by
weblogic.PlanGenerator either manually or by using the administration console to delete
extraneous variable definitions or add variables for individual properties.
• The administration console updates or creates new deployment plans as necessary when you
change the configuration properties for an installed application.
You can use the administration console to generate a new deployment plan or to add or override
variables in an existing plan. The administration console provides greater flexibility than
weblogic.PlanGenerator because it allows you to interactively add or edit individual
deployment descriptor properties in the plan rather than export entire categories of descriptor
properties.

Creating a New Deployment Plan
• WebLogic Server includes tools to accelerate deployment plan creation:

– The administration console:
— Generates a skeleton plan.xml if a plan folder is detected with a newly deployed
application
— Updates the plan.xml when you use the console to modify deployment descriptor
settings
– WLST uses the createPlan option to generate a plan.
– The weblogic.PlanGenerator Java class can also generate a skeleton
plan.xml for an existing application.
– Oracle Enterprise Pack for Eclipse (OEPE) leverages WebLogic tools to create
deployment plans.

Although it is not officially part of WebLogic, OEPE is an Oracle plug-in for Eclipse that leverages WebLogic
tools and the Eclipse framework to create deployment plans for applications. Developers may use OEPE
tools to create plan templates to make it easy for administrators to change settings in their applications.
To create a deployment plan for a deployed application that does not already have a deployment plan, make
a configuration change to the deployed application using the administration console. When you make a
persisted configuration change to a deployed application that does not have an existing deployment plan,
the console automatically creates a deployment plan for you and prompts you for the location in which to
save it.
weblogic.PlanGenerator is a Java-based deployment configuration tool that is intended for developers
who want to export portions of a deployment configuration into a deployment plan. This utility can generate
a brand new plan or can append to an existing one. By default, weblogic.PlanGenerator writes an
application’s deployment plan to a file named Plan.xml in the application’s root directory. The syntax for
invoking weblogic.PlanGenerator is the following: java weblogic.PlanGenerator [options]
[application]

Using the Administration Console to Generate a Deployment Plan
You can generate a deployment plan with the administration console using the following
steps:
1. Prepare the deployment files.
2. Install the application archive.
3. Save configuration changes to a deployment plan.

Before: All
empty
The administration console automatically generates or updates the deployment plan.

Note: You can use the generated deployment plan to configure the application in subsequent deployments,
or you can generate new versions of the deployment plan by repeatedly editing and saving the deployment
properties.
The administration console provides greater flexibility than weblogic.PlanGenerator because it allows
you to interactively add or edit individual deployment descriptor properties in the plan, rather than export
entire categories of descriptor properties.

Modifying and Saving Data to Create a New Plan

2
The application was originally deployed with various parameters (for example, a Session Invalidation
Interval of 60 seconds).
1. Select an installed application that you want to modify, and make a change of the Session Invalidation
Interval setting from 60 to 90.
2. When you click Save, the system prompts you for a new or existing deployment plan into which to
save this.
3. There was no deployment plan originally. So it creates a new one called Plan.xml.

New Deployment Plan Shows Changed Values
After:
Lists the

deployments
After Before
This is a partial snippet of what was created. Notice the session invalidation in particular.
<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan . . .>
<application-name>SimpleAuctionWebAppDbSec.war</application-name>
<variable-definition>
<variable>
<name>SessionDescriptor_invalidationIntervalSecs</name>
<value>90</value>
</variable>
</variable-definition>
<module-override>
<module-name>SimpleAuctionWebAppDbSec.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
<variable-assignment>
<name>SessionDescriptor_invalidationIntervalSecs</name>
:

Using an Existing Deployment Plan to Configure an Application
1. Prepare the application.

2. Place the existing deployment plan in the plan subdirectory of the application root.
– This is optional. The plan.xml file may be located anywhere.
3. Install the application.
– The administration console validates the deployment plan configuration against the
target servers and clusters that are selected during the installation.
4. Use the administration console, weblogic.Deployer, or WLST to identify both the
application and the plan to use for deployment.

The applications that you receive for deployment may come with varying levels of configuration information.
If you have an existing deployment plan for an application, simply prepare the application and place the
deployment plan in the plan subdirectory of the application root. Then install the application. The
administration console automatically uses a deployment plan named plan.xml in the /plan subdirectory
of an application root directory if one is available. If multiple plans are available for your application, they are
placed in their own /plan subdirectories (for example, /plan1 and /plan2), and the administration
console cannot identify them. Therefore, config.xml must specify the plan that you want to use.
After you install a new application and an existing deployment plan, the administration console validates the
deployment plan configuration against the target servers and clusters that were selected during installation.
If the deployment plan contains empty (null) variables, or if any values configured in the deployment plan
are not valid for the target server instances, you must override the deployment plan before you deploy the
application. You can also configure tuning parameters to better suit the target environment in which you are
deploying the application. The changes you make to the application’s configuration are saved to a new
deployment plan.
If you have a valid deployment plan that fully configures an application for the environment in which you are
deploying, you can use either the administration console, weblogic.Deployer, or WLST to deploy an
application with a deployment plan to use for deployment.
Note: A deployment plan that you use with the weblogic.Deployer utility must be complete and valid for
your target servers. weblogic.PlanGenerator does not allow you to set or override individual
deployment properties when it creates a plan.

Using an Existing Deployment Plan
1
2

3
You can use the administration console to specify a deployment plan for your application.
1. In the left pane, click Deployments.
2. In the right pane, select the check box next to the application for which you want to specify a
deployment plan. Click Update.
3. Click Change Path next to “Deployment plan path” to browse to the desired deployment plan. Click
Next, and then click Finish.

WLST createPlan
Example of using the WLST createPlan option:
> deploy(appName='MyApp',
path='/apps/MyApp.ear',
targets='cluster1',
createPlan='true')
WLST Command Line

This example shows WLST deploying an application and creating an initial deployment plan for the
application.

weblogic.PlanGenerator
• Enables you to generate basic WebLogic configuration extensions for applications that
have only Java EE deployment descriptors
• Enables you to:
– Create an initial plan
– Create a new plan based on an existing plan
– Control which components are exported to a plan


Using Plan Generator
The following are examples of using weblogic.PlanGenerator:

• Creating an initial deployment plan in an application's root directory:
$ java weblogic.PlanGenerator -root /appRelease/MyApplication
• Creating a new deployment plan based on an existing plan:
$ java weblogic.PlanGenerator \
-useplan /plans/MyApplication_template.xml \
-root /appRelease/MyApplication

• Controlling which components are exported to a deployment plan:
$ java weblogic.PlanGenerator -root /appRelease/MyApplication –all
The following are examples of using weblogic.PlanGenerator:

• Creating an initial deployment plan in an application’s root directory: In this example, the
plan.xml file is automatically stored in /appRelease/MyApplication/plan.
• Creating a new deployment plan based on an existing plan: This command uses the
/plans/MyApplication_template.xml plan as the basis for creating a new plan in
/appRelease/MyApplication/plan.
• Controlling the components that are exported to a deployment plan: This command exports all
configurable properties to null variables in a template deployment plan.
You can use the -all, -configurables, -dependencies, -declarations, -dynamics, and
-none options to specify the deployment descriptor components that are exported to a template
deployment plan.
For information about weblogic.PlanGenerator, review the weblogic.PlanGenerator Command-Line
Reference section of the Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server
documentation.

Oracle Enterprise Pack for Eclipse

2
Perform the following steps to create a deployment plan for an application in Eclipse:
1. Right-click your application project and select New > Other to open the Select a wizard dialog box.
2. In the dialog box, expand Oracle > WebLogic > Configuration, select Oracle WebLogic Deployment
Plan, and click Next.


3. On the File Name and Location page, select the parent folder location and the file name to use for
the plan file, and click Next.


4. On the Target Application and Options page, make your desired selections to control how your
deployment plan is created. In the example on this slide, you are using
weblogic.PlanGenerator to create your plan and instruct it to only create plan entries for
resources that are part of your application.


5. The plan is created and displayed in Eclipse for editing.

Remember that this is a task that developers are more likely to perform. These steps are only mentioned
here to show you how developers may create the plans that are subsequently included with the applications
that are passed on to administrators for deployment. This process is very similar for JDeveloper as well.

Managing Deployment Plans
Because deployment plans are different for each target environment and stored externally
from application archives:
• Plans should be managed using a source code control system (SCCS). SCCS provides
built-in:
– File versioning
– Change management and file before and after comparisons
• Each plan should be stored separately:
MyEJB.jar MyEJB.jar MyEJB.jar

application application application

to QA to prod
dev_plan.xml qa_plan.xml prod_plan.xml
Deployment plans are different for each environment during the full development life cycle of an application.
Each environment that an application is deployed to requires its own unique deployment plan unless all of
the settings are going to remain identical. Typically, applications are packaged up and deployed as archives
and deployment plans are used as an externally available configuration tool to conveniently modify the
application’s settings. Because of this, deployment plans are not part of the application itself and must be
managed separately.

Summary

• Configure a server’s staging mode
• Create and use deployment plans


Practice 15-1 Overview: Creating and Using a Deployment Plan

• Testing an application in an environment that uses a data source with the JNDI name
jdbc/AuctionDB
• Generating a deployment plan using weblogic.PlanGenerator
• Modifying the deployment plan to use with the application so that when deployed it uses
a new data source with the JNDI name jdbc/AuctionDBTest
• Modifying the AuctionDB data source to use the new JNDI name
• Updating the application to use the deployment plan
• Testing the application


16
WebLogic, Docker, and Kubernetes

Overview

Objectives
After completing this lesson, you should be able to describe:

• Container services
• Docker fundamentals
• Kubernetes basics
• Oracle WebLogic Operator for Kubernetes
• Oracle Linux Container Services


Agenda
• Container Services
• Docker Fundamentals
• Kubernetes Primer


Traditional System Architecture
Host
Cluster
FMW
WebLogic
Back-end
Systems
and
Host
Load FMW Databases
Balancer WebLogic
Web
Clients
FMW

WebLogic
Firewall Host
Corporate Network
A possible system architecture might contain:

• Clients using the World Wide Web to access your applications
• A firewall (hardware or software designed to prevent unauthorized access to or from a private
network by using filtering or blocking ports)
• A cluster proxy of either a hardware load balancer or a web server like OHS
• A cluster of WebLogic Servers on various machines (each one running applications)
• Various back-end systems or databases accessed by the applications running on WebLogic Server
Other common architectural elements not shown:
• Additional firewalls (for example, between the Load Balancer and WebLogic Server or between
WebLogic Server and the database)
• Multiple load balancers, or perhaps hardware load balancers in front of multiple web servers
• Multiple WebLogic Server clusters

History and Multi-Dimensional Evolution of Computing
Development Application Deployment and Application

Process Architecture Packaging Infrastructure
Waterfall Monolithic Physical Server Datacenter
Agile N-Tier Virtual Servers Hosted
DevOps Microservices Containers Cloud

1. Waterfall design and development resulted in creation of monolithic applications that were deployed to
physical servers in specific datacenter(s).
2. Multitier model became available with the advent of Agile development process, it became possible to
deploy to Virtual Machines and the resulting resource consolidation allowed for capital investment
savings and pawed the way to IaaS Cloud model.
3. Containers allow not only consolidation, but standardization of environments and more flexible
deployment capabilities due to sharing of these standard execution environments and features. Provide
for more deployment, distribution, and maintenance flexibility and enable DevOps approach. Suitable to
both on-premises and Cloud-based setups.
Request forwarding for options 1 and 2 was typically by external load-balancing functionality.
With the container model, request routing is also more flexible and may be done using variety of methods.
Ingress controllers are more typical in the latter case.

Container Use Case: Ready to Run Application Stack
• Excellent for Development/Test setups

– Developers build and update, promote the entire built stack to test
– Testers validate and sign-off or return to development
• Deployment in Seconds, not Hours/Days
– Entire stack: OS, software framework, application binaries and customizations are
fully contained in the image
– Separate deployment activities are not needed
– Minimizes errors
• Start Up, Tear Down Quickly
– Tooling to control container lifecycle automates deployment process


Container Use Cases: Microservices and One-Time Jobs
New App Dev & Microservices

• Refactor all or part of legacy applications
• Containers are great for Microservices:
‒ Consider application per container versus multiple applications in one WebLogic Server
domain. Benefits:
‒ More independence
‒ Separate and completely isolated evolution
One-Time Run Jobs and Analytics
• Start the container
• Run the Job

• Analyze and quit

Container Use Cases: Automation and Consolidation
Front-End Application Servers

• Highly horizontally scalable
• Cattle Not Pets – no individual care and feeding needed
• Rolling Deployments
• Optimize lifecycle – Jenkins helps automate building, testing, delivering and deploying
• Traditional Technologies – like MW/Backend provide supporting services
Increased Server Density
• Containers can use dynamic ports
• Run many of the same or different applications on a server

‒ Instead of one per VM

Virtual Machines Versus Containers
Containers
VMs
Virtual Machines Containers

• Each virtual machine (VM) • Containers include the application and all its

includes the application, the dependencies, but share the kernel with other
necessary binaries and containers.
libraries and an entire • Run as an isolated process in user space on the
guest operating system host OS.
• Not tied to any specific infrastructure – containers
run on any computer, infrastructure and cloud.

Agenda


Docker Architecture and Terminology
Docker client – Command Line

Interface (CLI) for interfacing with
the Docker.
Dockerfile – Text file of Docker
instructions used to assemble a
Docker Image.
Image – Hierarchies of files built
from a Dockerfile. Image file is used
as input to the docker build
command.

Container – Running instance of an
Image using the docker run
command.
Registry – Image repository.
Source: Docker docs and https://docs.docker.com/glossary/

Docker Images
An image is a collection of files and some metadata.

• Images use their own Linux kernel namespaces.
• Images comprise multiple layers. Multiple layers
may reference/be based on
another image utilizing Union File System.
• Each image contains software to run.
• Every image contains a base layer.
• Layers are read only
– Standardized

– Shared among containers
Source: Docker docs and https://docs.docker.com/glossary/

Docker Hub
Docker Hub is:

• A Docker Image repository
• Contains public and private images
• Permits images to be shared and moved off or onto a specific computer
• Offers secure access to images
Images can be:
• Pushed – added/replaced in the repository
• Pulled – imported from repository to individual workspace


Why Docker Is Popular?
• Development, testing, hosting of legacy applications

• New application development
• Code agility:
– Continuous Integration/Continuous Delivery – CI/CD pipeline
– Facilitates DevOps
• Promotes adoption of Open Source
• Can be used to develop microservices and cloud-native applications
• Containers are portable
– Managing/running a single container is easy


Agenda


Kubernetes: What Is It?
• Kubernetes is an orchestration framework to organize, control and deploy numerous

containers.
• Is an Open Source project, was initially developed by Google.
• Managed by CNCF – Cloud Native Computing Foundation
– Counts many software and hardware vendors
– Website: https://www.cncf.io
• Oracle contributes to the project.

Kubernetes is Greek for “pilot” or “helmsman of a ship”

Why Kubernetes?
Kubernetes offers means to manage complex combinations of multiple containers.

• Orchestration of containers:
– Dependencies
– Placement
– Persistence
– Networking – Ingress
– Management of Clusters and Worker Nodes
• Automation:
– Rolling deployments

– Scaling
• Provides API, command line and user interfaces

Basic Principles
• Kubernetes coordinates a highly available cluster of connected

computers that work as a single unit (Kubernetes cluster). The Master
abstractions in Kubernetes allow you to deploy Docker Controllers API
Server
containerized applications to a cluster without tying them Scheduler
specifically to individual machines. etcd
• Cluster is managed through web UI or through CLI (kubectl)

• A Kubernetes cluster consists of two types of resources: Node Node Node
– The Master coordinates the cluster Docker Docker Docker
– Nodes are workers that run the containers (application) Kubelet Kubelet Kubelet
• A node is a VM or a physical computer – a worker machine in a

Kubernetes cluster. Each node has a Kubelet – the agent for

managing nodes and communicating with the Kubernetes
master.
• Docker containers run on Nodes.
https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Applications in Kubernetes
• Containerized applications are deployed to

running Kubernetes cluster
• To deploy: create a Kubernetes Deployment
configuration
– The Deployment, written in YAML,
instructs Kubernetes how to create and
update instances of your application.
• Kubernetes master schedules the containers
– application instances – onto individual
Nodes in the cluster after Deployment was

created

Deployments and Pods
Node
• Kubernetes create Pods to host your application instance when Pod0 – IP:10.1.1.1
you create a Deployment Container Volume
•
Container
A Pod is a Kubernetes abstraction
• A Pod represents a group of:
– One or more application containers
– Some shared resources for those containers: storage
resources and a unique network IP Node
• Each Pod is tied to the Node where it is scheduled, and remains Pod1 – IP:10.1.1.2
Container
there until termination (determined by restart policy) or deletion.
– In case of a Node failure, identical Pods are scheduled by

Pod2 – IP:10.1.1.3
the Controller on other available Nodes in the cluster Container Volume
Container

Accessing Applications in Kubernetes
• A Kubernetes Service is an abstraction Node

comprising a logical set of Pods running Pod0 – IP:10.1.1.1
somewhere in your cluster Container Volume
Container Label:
– Each Service is assigned a unique IP Service app : foo
address upon creation – visible outside. IP: 129.144.50.2

selector: app : foo
type: LoadBalancer
– Each Pod has a unique IP address, those
IPs are not exposed outside the cluster.
• Services route traffic to applications: Node
– From other Pods within the cluster. Pod1 – IP:10.1.1.2
– Outside the cluster, for example, from the Container

Internet via a Load Balancer.
Pod2 – IP:10.1.1.3
Container
Volume
Container Label:
app : foo

Other Kubernetes Terminology
• Namespace: A logical isolation method. Most resources are associated with a

namespace.
– Namespace groups similar workloads and enforces different policies.
• Replication Sets: Control count of identical copies of a Pod to be running somewhere in
the cluster.
– Useful feature, when a Pod in each availability domain should be highly available or
scalable to create more Pods.
• Persistent Volume: Volumes setup by the administrator that provide persistent storage
for applications requiring long lived data.
– The deployment would use a Persistent Volume Claim to access a Persistent

Volume.

K8s Dashboard and Kubectl Output Examples


Agenda


Docker WebLogic Domain Image and Configuration Overrides
Domain in WebLogic Docker Image
WebLogic Docker Images containing application,

domain configuration, resources are immutable
• Development
Docker images must be • Testing
portable • Production
Comply with existing CI/CD

process
Need a way to override

For example: Provide data source
specific domain configuration URL and credentials
Docker Image contains entire WebLogic Domain file system – Image cannot be modified directly.
There should be a mechanism to customize domain configuration details without creating a new Docker
Image.
Overrides have to be external.
CI/CD stands for Continuous Integration/Continuous Delivery.

Domain Introspection and Config Override Generation
Introspection Job
WLS Domain Image

Domain
Customer provided • Scanning domain configuration

override templates for topology and to validate
• Generation of final configuration
overrides
Operator

Operator overrides
Oracle WebLogic Operator for Kubernetes allows to externalize image customizations

Supported User Configuration Overrides
Frequently overridden attributes – Supported by Operator
• User names • Network channel public addresses:

• Passwords – For remote RMI clients (T3, JMS,
EJB, JNDI, LDAP)
• SSL properties
– For remote WLST clients
• URLs for:
• Debugging
– JDBC data sources
– JMS
• Tuning
— Bridges – Max Message Size
– HTTP POST timeout

— Foreign servers
— SAF resources – Server start properties
Documentation: https://oracle.github.io/weblogic-kubernetes-operator/userguide/managing-domains/configoverrides
Documentation link: https://oracle.github.io/weblogic-kubernetes-operator/userguide/managing-

domains/configoverrides

Unsupported User Configuration Overrides
The behavior is undefined when using unsupported overrides
• Domain topology: cluster members Should never use custom overrides that:
• Network channel listen address, port, and enabled • Add or remove:
configuration – Servers
• Server home and domain log locations – Clusters
• Node Manager related configuration – Network Access Points – custom channels
• Changing any existing MBean name – Modules
• Adding or removing a module: • Change any of the following:

– JMS – Dynamic cluster size
– JDBC – Default, SSL, and Admin channel Enabled,
listen address, and port
– WLDF
– Network Access Point (custom channel),
listen address, or port

– Server and domain log locations – use the
logHome domain setting instead
– Node Manager access credentials
• Change any existing MBean name – for example, it is
not allowed to change the domain name.

Configuration Overrides
Overriding JDBC data source credentials:

example
• Create a Kubernetes configuration map
containing
– Override templates a.k.a. situational
configuration templates
• Set your domain resource
configOverrides to the name of this
configuration map.
• Create Kubernetes secrets that contain data

source username and password.
• Set your domain configOverrideSecrets
to reference the aforementioned secrets.
• Start or restart your domain.

WebLogic Operator Lifecycle Management
ENTRYPOINT – start WebLogic Server

Liveness probe – check if the
WebLogic server is alive
Readiness probe – query if the
WebLogic server is ready to receive
requests
Shutdown Hook – gracefully shut
down the WebLogic server


WebLogic Lifecycle Management
• WebLogic Operator automatically re-

creates server pods when:
– Properties on the domain resource
affecting server pods change Stop Clustered Manage Server 1
— Image
Edit Domain Custom Resource (CR)
— Volumes
— Environment domain:
spec:
• Users can control lifecycle of WebLogic managedServers:
serverName: "cluster1_server1”
domain/cluster/server by editing Domain serverStartPolicy: ”NEVER" ...
Custom Resource.
– Start/stop/restart

– Initiate a rolling-restart of the domain
• WebLogic Operator reacts and performs Domain Custom Resource
correct lifecycle operation.

Oracle Fusion Middleware Images
Oracle Container Registry includes WebLogic and Coherence Operators.

https://container-registry.oracle.com


Agenda


Oracle Linux Container Services
https://docs.oracle.com/en/operating-systems/oracle-linux/kubernetes
• Oracle Linux 7 may be used to host enterprise Kubernetes environment.
• To simplify Kubernetes, use Oracle provides detailed user documentation about
installing and configuring Kubernetes software:
– Realistic Kubernetes deployment relies upon Kubernetes cluster comprising multiple
nodes.
– Two or more systems running Kubernetes are essential.
– Access to root-level account and use of Linux Yum or OLN subscription are needed.
# yum-config-manager --enable ol7_addons
• Oracle Unbreakable Enterprise Kernel Release 5 is required to run Kubernetes.
– Upgrade running UEK R4 to UEK R5 before you begin.

# yum-config-manager --disable ol7_UEKR4
# yum-config-manager --enable ol7_UEKR5
Version 1.12 adds support for high availability multi-master clusters kubeadm-ha-setup, CoreDNS and other enhancements
At the time this presentation was created, Oracle Linux Container Services for use with Kubernetes
supported release version 1.12 had been current.
Using root-level access on a Linux UEKR5 host run the following commands:
# yum-config-manager --enable ol7_addons
# yum-config-manager --disable ol7_UEKR4
# yum-config-manager --enable ol7_UEKR5
# yum update
Reboot the system after the update before continuing.

Host Resource Requirements
• Nodes in the Kubernetes cluster must have:

– Minimum 2 GB of RAM
– 2 or more CPUs
– Docker engine installed and ready to run.
• Kubernetes identifies each node in the cluster by:
– Unique hostname
– Unique MAC address
– Unique product UUID
— Verify using Linux command: # dmidecode –s system-uuid
• Storage requirements are:

– Minimum 5 GB free disk space mounted as /var/lib/kubelet
– Minimum 5 GB free disk space mounted as /var/lib/docker
Docker installed from ol7_preview repository is not supported by Oracle and must be uninstalled,
ol7_preview repository should be also disabled.
Install Docker using:
# yum install docker-engine
Enable Docker service to start automatically upon system boot; do it prior to configuring Kubernetes:
# systemctl enable docker
# systemctl start docker

Time Synchronization and Request Forwarding for Kubernetes
Hosts running Kubernetes software must use time synchronization.

• To enable time synchronization install and start ntp daemon:
# yum install ntp
# systemctl enable ntpd
# systemctl start ntpd
• Proceed to install Kubernetes tools:
# yum install kubeadm kubectl kubelet
• Kubernetes relies upon request routing using iptables Linux utility, which should not
have rules interfering with Kubernetes:

# iptables –P FORWARD ACCEPT
• You will be notified of any issues when you are configuring Kubernetes

Kubernetes Port Use
• Kubernetes Master Node communicates with all Worker Nodes using predefined ports.
• Worker Nodes access Master Node via TCP port 6443.
• On each node running Kubernetes and running firewalld use following commands:
# firewall-cmd –-add-masquerade –-permanent
# firewall-cmd –-add-port=10250/tcp –-permanent
# firewall-cmd –-add-port=8472/udp –-permanent
• Additional port on Master Node for API server access:
# firewall-cmd –-add-port=6443/tcp –-permanent
• Restart firewall or reboot the systems where these rules were added or modified.

# systemctl restart firewalld

Docker Container Registry
• Kubernetes set up is accomplished using kubeadm-setup.sh

• This script requires images from the Oracle Container Registry
https://container-registry.oracle.com
• Login using your Single Sign-On credentials:
– Accept Oracle Standard Terms and Restrictions for the desired images. May accept a
global agreement for all repositories. Additional acceptance will be needed if newer
repositories are added in the future and to perform upgrades.
– All systems for all Nodes in your Kubernetes cluster should have access to the same
URL.
• Use Docker login command to establish connectivity:

# docker login container-registry.oracle.com
– Login using your Single Sign-On user name and password at the prompt.

Oracle Registry Mirror Servers
Oracle hosts regional mirror servers available both for Oracle Cloud and on-premises users
• Use mirror sites for docker login to improve performance and reduce bandwidth
• Still need to login and accept terms at https://container-registry.oracle.com
Oracle Container Registry Mirror Domain Oracle Container Infrastructure Region

container-registry-phx.oracle.com Phoenix
container-registry-iad.oracle.com Ashburn
container-registry-yyz.oracle.com Toronto
container-registry-lhr.oracle.com London
container-registry-fra.oracle.com Frankfurt

container-registry-icn.oracle.com Seoul
container-registry-nrt.oracle.com Tokyo
https://docs.oracle.com/en/operating-systems/oracle-linux/docker/oracle-registry-server-mirrors.html

Using Private Docker Registry
• Docker registry may be run locally, within your private network: deploy private registry
server – Docker container itself
• Registry listens by default inside container on port 5000.
– Examples below use external/public port 5008.
– Add --restart=always to ensure container starts automatically on system boot.
# docker run -d -p 5008:5000 --name registry-private registry:2
• Internal container port may be changed using parameter HTTP_REGISTRY_ADDR
# docker run -d -p 5008:5000 --name registry-private registry:2
• Registry access is over HTTPS connection by default. Private registry may be secured

with self-signed certificates or accessed over plain HTTP protocol if on local network and
HTTPS is not required.
Details are at: https://docs.docker.com/registry/deploying
and https://docs.docker.com/registry/insecure
Deploying a Plain HTTP Registry

Create or edit the daemon.json file, whose default location is /etc/docker/daemon.json (port 5008 is the
public port # of the container)
{
"insecure-registries" : [“your.registry.host:5008"]
}
Restart docker service after the above.

Local Container Registry
• Systems running Docker behind corporate firewalls may not be able to connect to Oracle
Container Registry or any mirrors directly.
• Set up a local Docker Container Registry on one of your internal hosts as an alternative
– that host must have access to Oracle-managed registry to download latest images.
• Use kubeadm-registry.sh to pull images from an Oracle registry and store/push into
your local one
– Ensure that local registry images have the exact same tags as in Oracle registry.
# kubeadm-registry.sh –-to your.registry.host:5008 --from \
container-registry.oracle.com/kubernetes –-version 1.12.5
• On each host intended to run Docker containers add KUBE_REPO_PREFIX environment

variable for kubeadm-registry.sh script use – add to login profile:.bashrc:
export KUBE_REPO_PREFIX=your.registry.host:5008/kubernetes

Consider Using minikube Tool
Tool minikube helps implementing a local Kubernetes cluster on your host:

• Helps manage local Kubernetes application development with all Kubernetes features.
• Works on Linux, Windows, and macOS.
• Runs latest stable release of Kubernetes and supports:
– Runs in a VM or in your host OS
– LoadBalancer – minikube
tunnel
– Persistent Volumes
– Ingress
– Dashboard – minikube dashboard

– Other useful controls and developer-oriented features
Read more at: https://kubernetes.io/docs/setup/learning-environment/minikube

Summary
In this lesson, you should have learned about:

• Container services
• Docker fundamentals
• Kubernetes basics


A
Production Redeployment

Objectives
After completing this lesson, you should be able to deploy versioned applications
(production redeployment).

Oracle WebLogic Server 12c: Administration II A - 2

Agenda
• HTTP Sessions and Redeployment

• Redeployment Strategies
• Production Redeployment
• Application Versioning
• Requirements and Restrictions


HTTP Sessions and Redeployment
HTTP sessions maintain a client’s state in WebLogic:
Before redeployment: Machine After redeployment:

HTTP session
HTTP session is gone.
Managed server
2 4
1
Existing Web Web
client Application Application
connections MyApp MyApp
REDEPLOY

3
WebLogic maintains the user state for clients that use web applications in HTTP session objects. When the
associated web application is redeployed, the undeployment aspect of the process effectively eliminates the
HTTP sessions associated with that deployment.
1. A client using a web browser is using the MyApp web application and has an associated HTTP
session on the server.
2. The application is redeployed, which involves undeploying the original MyApp application and
replacing it with the updated MyApp application. The associated HTTP session for the existing client
is lost.
3. The client browser makes another request to the application, which is routed to the newly deployed
MyApp application. However, there is no HTTP session for this client and all session state is lost.
4. Depending on the situation, the client may have to start his or her session over to reestablish state
with a new HTTP session that is associated with the newly deployed MyApp web application.

Agenda



Redeployment Strategies
WebLogic provides several different redeployment techniques for applications:
Strategy Description When to Use
In-place Completely replaces the existing application Upgrading applications that can tolerate client
with the new application interruptions
Partial redeploy for static files Immediately replaces files such as HTML, Updating static web files that do not affect
JSP, and images application clients
Partial redeploy of Completely replaces existing modules within Replacing a component of an enterprise
Java EE modules an enterprise application (EAR) application that can tolerate client
interruptions

Production redeployment (side- Deploys a new version of an application Upgrading applications that cannot tolerate
by-side) alongside an existing version client interruptions
Note
Production redeployment is also called side-by-side deployment. This lesson focuses mainly on the last
redeployment strategy; production redeployment.

Agenda

– Application Availability
– What Is Production Redeployment?
– Advantages of Production Redeployment
– Production Redeployment Process
– Application Retirement
– Distributing Versioned Applications

– Administration Mode
– Rolling Back to a Previous Version

Application Availability
What happens when you need to update an existing application deployment?

• Default redeployment occurs in place.
• Redeployment disrupts existing clients.
The newly activated
The existing application application completely
is completely removed. Machine replaces the existing
application.
Managed server
Undeployed Active
MyApp MyApp

Existing REDEPLOY New
client client
connections connections
By default, when an application is redeployed in place:

• It is unavailable to clients for a brief time
• Existing clients lose any conversational state
In a production environment, deployed applications frequently require 247 availability to provide
uninterrupted services to customers and internal clients. In these cases, scheduling maintenance down time
to replace applications is not desirable.
WebLogic uses an in-place redeployment scheme by default. In-place redeployment immediately replaces a
running application’s deployment files with the updated deployment files. In contrast to production
redeployment, in-place redeployment of an application or a stand-alone Java EE module does not
guarantee uninterrupted service to the application’s clients. This is because WebLogic immediately removes
the running class loader for the application and replaces it with a new class loader that loads the
updated application class files.

What Is Production Redeployment?
Production redeployment is the ability to deploy multiple versions of the same application at
the same time to avoid disrupting existing or new users.
The existing version

remains until existing The new version
clients finish their work handles requests
or for a time period. Machine from new clients.
Managed server
Retiring Active
Version 1 Version 2

Existing REDEPLOY New
client client
Production redeployment enables an administrator to redeploy a new version of an application in a

production environment without stopping the deployed application, or interrupting the application’s
availability to clients. Production redeployment works by deploying a new version of an updated application
alongside an older version of the same application. WebLogic automatically manages client connections so
that only new client requests are directed to the new version. Clients that are already connected to the
application during the redeployment continue to use the older, retiring version of the application until they
complete their work.
Production redeployment is supported primarily for applications with a web application entry point (HTTP
clients). WebLogic can automatically manage the HTTP client entry points to isolate connections to the
newer and older application versions. That is, production redeployment is supported for stand-alone web
application modules and for enterprise applications that are accessed via an embedded web application
module.
Production redeployment supports only HTTP clients and RMI clients. Your development and design team
must ensure that applications using production redeployment are not accessed by an unsupported client.
WebLogic does not detect when unsupported clients access the application and does not preserve
unsupported client connections during production redeployment.

Enterprise applications can contain any of the supported Java EE module types. Enterprise applications can
also include application-scoped JMS and JDBC modules.
If an enterprise application includes a JCA resource adapter module, the module:
• Must be JCA 1.5 compliant
• Must implement the weblogic.connector.extensions.Suspendable interface
• Must be used in an application-scoped manner, having enable-access-outside-app set to
false (the default value)
Before the resource adapters in the newer version of the Enterprise Archive (EAR) are deployed, the
resource adapters in the older application version receive a callback. WebLogic then deploys the newer
application version and retires the entire older version of the EAR.
When you are redeploying a new version of an application, the following features cannot change:
• Deployment targets
• Security model

• Persistent store settings

Advantages of Production Redeployment
Completely avoids:
• Scheduling application down time
• Setting up redundant servers to host new application versions
• Managing client access to multiple application versions manually
• Retiring older versions of an application manually


Production Redeployment Process
Machine Managed server
2 3
V1 DEPLOY V1
Weblogic- 9
Application-
Version: V1 7 Existing
1 MANIFEST.MF clients
10
6
4 Application Application
V2 REDEPLOY V2

Weblogic-
Application-
8 New
Version: V2
5 MANIFEST.MF clients
The production redeployment process includes the following:

1. An administrator configures an application with a current version of V1 in the application’s manifest
file.
2. The administrator deploys the application normally. WebLogic recognizes the version information in
the manifest file and deploys the application with that version data.
3. Clients begin to use the V1 version of the application.
4. An update to the application has been developed and is ready to replace the older version in
production.
5. The administrator updates the application’s manifest file to a new version of V2.
6. The administrator deploys the application again. Because the application is already deployed,
WebLogic performs a redeployment. During this process, WebLogic recognizes the updated
application’s version information in the manifest file. WebLogic recognizes that both the existing and
new application deployments have version data associated with them.
7. As a result, WebLogic changes the state of the original application to stop Running, but does not
actually stop it from running unless it is directed to do so.
8. WebLogic deploys the new application along with its version information and changes its state to
Active.
9. Existing clients that were using V1 continue to have WebLogic route their requests to the V1 version
of the application.
10. New clients have WebLogic route their requests to the V2 version of the application.

Application Retirement
Existing application versions are retired depending upon several factors:
Retirement Trigger Description
Graceful client transition Waits for all existing client sessions to end, and then automatically retires the old
version
Timeout Keeps the existing version running for a configured timeout period, and then
automatically retires the old version
Forced An administrator can force work to stop and cause the original application version to
retire. This is the equivalent of doing an
in-place deployment.

During a graceful retirement for an application deployed on a cluster, each cluster member maintains its
own set of HTTP sessions. Client activity is varied across cluster members so some clusters may retire the
old version of the application before others. In the event of a failover scenario, the client fails over to the
server where its secondary HTTP session resides. If the existing version of the application is still active on
that server, the request works normally. If the existing version has already retired on that server, then
failover fails and the client must reestablish its session with the server.

Review: Administration Channel
• Use a dedicated address and/or port for administrative traffic.

• Disable client access points during server maintenance or troubleshooting.
Console host1:8001
Admin
Server
host1:9001
SSL
host2:9001
Managed

SSL Server
host2:8001
While maintaining or troubleshooting a production server, it is often desirable to disable all incoming
application requests. However, a server’s default network configuration implies that all traffic run on the
same port. Therefore, if the port were closed, all remote administration tools, such as the console or WLST,
would also not be able to connect to the server.
WebLogic Server supports a domain in which all servers use a separate SSL port that accepts only
administration requests. The use of dedicated administration ports enables you to:
• Start a server in standby state: This enables you to administer a server while its other network
connections are unavailable to accept client connections.
• Separate administration traffic from application traffic in your domain: In production
environments, separating the two forms of traffic ensures that critical administration operations (such
as starting and stopping servers, changing a server’s configuration, and deploying applications) do
not compete with high-volume application traffic on the same network connection.
• Administer a deadlocked server instance: If you do not configure an administration port,
administrative commands such as THREAD_DUMP and SHUTDOWN will not work on deadlocked server
instances.

Administration Mode
You can deploy applications in administration mode:

• Applications are not available to clients.
• This mode requires a configured administration channel.
• Administrators can test the application before clients use it.


Distributing a Versioned Application
Distributing is an alternative to deploying an application.
Distributing a new version of the Redeploying a new version of an

application makes it available for testing application places the application
before being released for general immediately into use and makes it available
consumption. to new client requests.

Production redeployment can be used with the -distribute command to prepare a new version of an
application for deployment. For more information, refer to Distributing a New Version of a Production
Application.
Distributing an application prepares it for deployment by copying its files to all target servers and validating
the files.
You can start a distributed application in Administration mode. Access to the application is then restricted to
a configured administration channel.

Deploying in Administration Mode
A new version of an application deployed in administration mode for testing:
The existing version The new version

remains until existing handles requests only
clients finish their work from the administration
or for a time period. channel.
Machine
Managed server
Retiring Active
ADMIN
Version 1 Version 2

Existing and REDEPLOY New
new client administrator
WebLogic prepares the new application version, which is deployed in administration mode and made
available via a configured administration channel, for deployment. However, the older version of the
application is not automatically retired by WebLogic when the new version of the application is distributed
and deployed in administration mode. The older version of the application remains active to process both
new and existing client requests.
The new application version can either be undeployed or started after it has been completely tested via an
administration channel. WebLogic routes new client connections to the updated application after starting the
application and begins retiring the older application version.

Rolling Back to the Previous Version
You can roll back a versioned application to the previous version.
The existing version The new version

becomes the active becomes the
version again. retiring version.
Machine
Managed server
Version 1 Version 2
REDEPLOY

Existing New
client client
Note: Rolling back is technically not always an actual rollback procedure. In some cases, it is merely a new
production redeployment task whereby the version and files of the new version are really the same as the
original existing version. WebLogic has no knowledge of whether or not the version information is sequential
or has any meaning. It only requires that the version strings are different.
Rolling an application deployment back to a previous version is possible regardless of the current state of
the side-by-side deployment:
• If the new version is in administration mode, the administrator can stop the new version so the
existing version remains in place.
• If the new version is active and the existing version is retiring, the administrator can redeploy the
existing version, which will cause the two versions to switch places. The new version changes to a
retiring state and the existing version becomes active. The administrator can also force work to stop
for the retiring version to ensure that clients revert to using the original version quickly.
• If the new version is active and the existing version is retired, the administrator can redeploy the
existing version, which will again cause the two versions to switch places.

Quiz Q
How many versions of an application can be deployed simultaneously in WebLogic?
a. 1
b. 2
c. 3
d. 4

Answer: b

Quiz Q
Which types of clients are supported by production redeployment?
a. HTTP
b. RMI
c. Web service
d. All of the above

Answer: d

Agenda

– Configuring Application Versions
– Redeployment Command Examples


Redeployment Process: Overview
1. Verify that only one version of the application is currently deployed.

2. Verify the MANIFEST.MF files to ensure that both applications have different versions.
3. Copy the new version into a suitable directory.
4. Redeploy the new application version and specify the updated deployment files.
5. Verify that both versions are deployed and that new requests are being sent to the new
version.

This slide shows a summary of the tasks required to perform production redeployment on WebLogic.
Note: WebLogic supports deploying only two versions of an application at a time. You must undeploy or
retire a version of an application before deploying a subsequent version.

Configuring Application Deployment Versioning
You configure application version information by using the application’s manifest file or
specifying options during deployment:
This string can

be any value.
Manifest-Version: 1.0
Weblogic-Application-Version: 1.0beta
MANIFEST.MF
$ java weblogic.Deployer -adminurl http://host01.example.com:7001 \

-user weblogic -password Welcome1 –deploy \
Use deploy for the
-name myApp \
-source /prod/deployments/myApp/beta1.0/MyApp.war \ initial deployment.
-targets myCluster -appversion 1.0beta

Command Line
Specify the version here if it is not

configured in the manifest file.
Note: The best practice is to include version data in the manifest file.
You should include version information in the application’s manifest file because it is easier to track and
maintain the versions of your applications. Otherwise, you could deploy an older version of an application
accidentally.

Configuring Application Deployment Versioning
Specifying options using the administration console:

• The administration console does not provide a way to set an application version.
It displays only whatever archive version is configured in the manifest file.
WLST:
> deploy('myApp',
'/prod/deployments/myApp/beta1.0/MyApp.war',
'myCluster',
versionIdentifier='1.0beta')
Command Line

Specify version here
or in the manifest file.

Deploying a New Version of an Application
Configure the manifest file of the updated application with the new version and redeploy the
application:
WebLogic recognizes that
this string is different.
Manifest-Version: 1.0
Weblogic-Application-Version: 1.0
MANIFEST.MF

-user weblogic -password Welcome1 –redeploy \
-name myApp \ Use redeploy when
-source /prod/deployments/myApp/GA1.0/MyApp.war \ deploying a new version.
-targets myCluster \

-retiretimeout 200 Command Line
The application name is the
same, deployment files are
Optional timeout seconds
different, and deployment targets
before retiring application
are the same.
If a timeout is not specified during production redeployment, the default behavior is to gracefully retire the
existing application version after all client work has completed.

Administration console:

This slide and the following slide show an example of redeploying an application using the administration
console. The first image shows that the existing application version is selected and the Update button is
clicked to update the deployment. The second image shows that the Change Path button is clicked to
choose the updated source files for the new application version. Next is clicked to view the application’s
settings, including its version information.

New version
source files
New application
version identifier

Retirement settings for
existing application
The image in the slide shows the version information associated with the new version of the application
before deployment. Clicking Finish completes the process.

WLST:
> redeploy('myApp',
'',
appPath='/prod/deployments/myApp/GA1.0/MyApp.war',
versionIdentifier='1.0GA',
retireGracefully='true')
Command Line

Note
You can also specify adminMode='true' as an option to cause the redeployment to start in Admin mode.

Distributing and Starting a Versioned Application in Administration
Mode
Starting a versioned application in administration mode involves distributing the application,
and then starting it with the -adminmode option:

-user weblogic -password Welcome1 –distribute \
-name myApp \ Use distribute
-source /prod/deployments/myApp/GA1.0/MyApp.war \ instead of redeploy.
-targets myCluster
Command Line

-user weblogic -password Welcome1 -start –adminmode \
-name myApp
Command Line

Mode
Specifying options by using the administration console:

This slide shows using the administration console to start a distributed new version of an application in
Admin mode. The first image shows the state of the two versions of the application before starting the new
version in Admin mode. The second image shows that the existing version of the application is in Active
mode and the new version is in Admin mode.

Mode
Distribute an application:
> distributeApplication('/prod/deployments/myApp/GA1.0/MyApp.war',
'',
'myCluster',
versionIdentifier='1.0GA')
WLST Command Prompt
Specifies the version of this

application deployment
Start the application in administration mode:

> startApplication('myApp',

adminMode='true',
retireGracefully='true') WLST Command Prompt
Starts the application in Admin mode

and tells WebLogic to retire gracefully

Transitioning a Versioned Application from Administration Mode to
Active
Making a versioned application running in administration mode available for client requests
involves using the -start option again without specifying the -adminmode option:

-user weblogic -password Welcome1 –start \
-name myApp
Command Line


Transitioning a Versioned Application from Administration Mode to
Active
Administration console:

WLST:
> startApplication('myApp',
retireGracefully='true') Command Line
This slide shows using the administration console and WLST to move an application from Admin mode to
Active mode. The first image shows the state of the two versions of the application before starting the new
version in Admin mode. The second image shows that the existing version of the application is in Retired
mode and the new version is in Active mode.

Rolling Back a Versioned Application to a Previous Version
To roll back to the retired application version, perform a second -redeploy command and
specify the source files for that version:

-user weblogic -password Welcome1 –redeploy \
-name myApp \
-source /prod/deployments/myApp/beta1.0/MyApp.war \
-targets myCluster \
-retiretimeout 10 Command Line
The source files

You may want a rollback to of the old version
occur quickly if something is
wrong with the new version.

Quiz Q
Why would you deploy a new version of an application in administration mode?
a. To plan a graceful transition to the new version
b. To test the new version before making it live
c. To prepare it before retiring the old version
d. To configure it before making it live

Answer: b

Agenda



Requirements and Restrictions
Production redeployment strategy is supported for:

• Stand-alone WAR modules and EARs whose clients access the application via HTTP
• Enterprise applications that are accessed by inbound JMS messages from a global
JMS destination or from inbound JCA requests
• All types of Web services

Production redeployment supports only HTTP clients and RMI clients. Specific coding is required to handle
the reconnection to the new RMI client version. Your development and design team must ensure that
applications using production redeployment are not accessed by an unsupported client. WebLogic does not
detect when unsupported clients access the application and does not preserve unsupported client
connections during production redeployment.
Production redeployment is not supported for:
• Stand-alone EJB or RAR modules. If you attempt to use production redeployment with such
modules, WebLogic Server rejects the redeployment request. To redeploy such modules, remove
their version identifiers and explicitly redeploy the modules.
• Applications that use Java Transaction Service (JTS) drivers:
- The LoggingLastResource global transaction optimization is not permitted for JDBC
application modules.
- When deploying application-scoped JDBC resources, the EmulateTwoPhaseCommit
feature is not supported for multiple versions.
• Applications that obtain JDBC data sources via the DriverManager API. To use production
redeployment, an application must use JNDI to look up data sources.
• Applications that include EJB 1.1 container-managed persistence (CMP) EJBs. To use production
redeployment with applications that include CMP EJBs, use EJB 2.x CMP instead of EJB 1.1 CMP.

Summary
In this lesson, you should have learned how to deploy versioned applications (production
redeployment).


[Optional] Practice Appendix A-1 Overview: Using Production
Redeployment
• Updating an application to reference a new version of a shared library
• Updating the application to version 2
• Redeploying the updated application
• Observing existing and new clients using the application
• Retiring version 1 of the application
• Rolling back to version 1 of the application


B
WebLogic Optimizations for Exalogic

What Is Exalogic?

CPUs, storage, Optimized Oracle
network software
Exalogic is an integrated hardware and software system designed to provide a complete platform for a wide
range of application types and widely varied workloads. Exalogic is intended for large-scale, performance-
sensitive, mission-critical application deployments. It combines Oracle Fusion Middleware and Sun
hardware to enable a high degree of isolation between concurrently deployed applications, which have
varied security, reliability, and performance requirements. Exalogic enables customers to develop a single
environment that can support end-to-end consolidation of their entire applications portfolio.
Exalogic hardware is preassembled and delivered in standard 19” 42U rack configurations. The main
hardware components of a single Exalogic X3-2 machine Full Rack are the following:
• 30 Sun Server X3-2 (formerly Sun Fire X4170) compute nodes
• One dual controller Sun ZFS Storage 7320 appliance with 20 disks
• Four Sun Network QDR InfiniBand Gateway Switches
• One Sun Datacenter InfiniBand Switch 36
• One 48-port Cisco Catalyst 4948 Ethernet management switch
• Two redundant 24 kVA power distribution units
Oracle WebLogic Server 12c: Administration II B - 2

What Is Exalogic?
Oracle Exalogic:
• Combines Sun storage and x86 servers by using a high-speed InfiniBand network
• Is specifically engineered to host Oracle Fusion Middleware software
• Includes optimizations to Oracle Fusion Middleware software that result in huge
performance gains
• Supports Oracle Enterprise Manager for centralized configuration, monitoring, and
diagnostics
• Provides an integrated IaaS cloud solution

You can connect up to eight Exalogic machines, or a combination of Exalogic machines and Oracle Exadata
database machines, together without the need for any external switches. If more than eight racks are
required to be connected on the same InfiniBand fabric, Oracle offers a choice of several high-capacity data
center switches, which enable the creation of Exalogic clouds comprising hundreds of racks and tens of
thousands of processors.
Exalogic is designed to fully leverage an internal InfiniBand fabric that connects all of the processing,
storage, memory, and external network interfaces within an Exalogic machine to form a single, large
computing device. Each Exalogic machine is connected to the customer's data center networks via 10 GB
Ethernet (external traffic) and 1 GB Ethernet (management traffic) interfaces.
Oracle Enterprise Manager Grid Control with Oracle WebLogic Server Management Pack Enterprise
Edition's capabilities include Exalogic specific management tools to monitor the Oracle software deployed in
the Exalogic environment. If using Solaris as your Exalogic operating system, you can also use Oracle
Enterprise Manager Ops Center to provide configuration and management capabilities for the Exalogic
hardware components.

What Is InfiniBand?
• Distributed systems communicate with one another to:

– Separate application tiers (Web, business logic, caching)
– Provide high availability (“clusters”)
• InfiniBand:
– Is a standard network architecture designed for very high speeds between nodes in
close proximity to each other
– Acts as a “fabric” to connect CPUs and other devices
– Is ideal for supercomputers and data centers
– Delivers 40 Gb/s (4x faster than high speed Ethernet)
– Supports direct application connections that bypass the OS

– Is interoperable with Ethernet for external communication
Moving data between applications over a traditional network can consume a lot of time and drain precious
server resources. With traditional network technologies, data exchanges traverse the operating systems on
both the source and destination servers, resulting in excessive application latency due to operating system
calls, buffer copies, and interrupts.
InfiniBand, which today delivers 40 GB per second connectivity with application-to-application latency as low
as 1 microsecond, has become a dominant fabric for high-performance enterprise clusters. Its ultra-low
latency and near-zero CPU utilization for remote data transfers make InfiniBand ideal for high-performance
clustered applications.
InfiniBand also provides a direct channel from the source application to the destination application,
bypassing the operating systems on both servers. InfiniBand’s channel architecture eliminates the need for
OS intervention in network and storage communication. This frees server memory bandwidth and CPU
cycles for application processing.
In addition to carrying all InfiniBand traffic, the Sun Network QDR InfiniBand Gateway Switch enables all
InfiniBand attached servers to connect to an Ethernet LAN by using standard Ethernet semantics. No
application modifications are required for applications written to use standard Ethernet.

Exalogic Networks
Network Speed Description

• Provides external access to compute nodes via the
Client 10 Gb
intranet/Internet
• Is used to monitor and administer components
Management 1 Gb • Provides access to ILOM and other device management
interfaces
• Is a private, non-routable network

• Connects racks, along with all rack components
Private InfiniBand 40 Gb
• Is used by compute nodes to access shared storage

• Is used for internal application communication
An Exalogic machine includes compute nodes, a Sun ZFS Storage 7320 appliance, as well as equipment to
connect the compute nodes to your network. The network connections allow the servers to be administered
remotely, enable clients to connect to the compute nodes, and enable client access to the storage
appliance. Additional configuration, such as defining multiple virtual local area networks (VLANs) or
enabling routing, may be required for the switches to operate properly in your environment and is beyond
the scope of the installation service.
There are up to five networks for an Exalogic machine. Each network must be on a distinct and separate
subnet from the others. The Exalogic management network connects to your existing management network
and is used for administrative work for all components of the Exalogic machine. It connects ILOM, compute
nodes, server heads in the storage appliance, and switches connected to the Ethernet switch in the Exalogic
machine rack. This management network is in a single subnet. Do not use the management network
interface (ETH0/NET0) on compute nodes for client or application network traffic. Cabling or configuration
changes to these interfaces on Exalogic compute nodes is not permitted.

Exalogic Machine Topology
Clients
Rack
Compute Node
Client Compute Node Mgmt

Network Network
10 Gb 40 Gb
InfiniBand Mgmt 1 Gb
Storage Appliance
Switches Switch
40 Gb

IB
Network
Power Distribution Units (PDUs)
Exalogic hardware is preassembled and delivered in standard 19” 42U rack configurations. Each Exalogic
configuration is a unit of elastic cloud capacity balanced for compute-intensive workloads. Each Exalogic
configuration contains several hot-swappable compute nodes along with a clustered, high-performance disk
storage subsystem. The hardware also includes a high-bandwidth InfiniBand fabric to connect every
individual component within the configuration as well as to externally connect additional Exalogic or Exadata
Database Machine racks. In addition, each configuration includes multiple 10 Gb Ethernet ports for
integration with the data center's service network, along with 1 Gb Ethernet ports used for integration with
the data center’s management network. All Exalogic configurations are fully redundant at every level and
are designed with no single point of failure.
All device management ports are connected to your local data center management network by using a
Cisco Catalyst 4948 switch, which is a built-in component of an Exalogic rack. This switch offers 48 ports of
wire-speed 10/100/1000BASE-T with 4 alternative wired ports that can accommodate optional 1000BASE-X
Small Form-Factor Pluggable (SFP) optics. Reliability and serviceability are delivered with optional internal
AC or DC 1 + 1 hot-swappable power supplies and a hot-swappable fan tray with redundant fans.

InfiniBand Networking Concepts
Network Term Definition Description
Private IPoIB IP over InfiniBand Applications connected by an IB fabric communicate by using

standard IP address semantics.
SDP Socket Direct Applications communicate directly with the IB fabric, bypassing
Protocol the operating system's TCP/IP stack.
Client EoIB Ethernet over Applications within an IB fabric communicate with external
InfiniBand Ethernet networks.

VNIC Virtual Network Software that emulates an Ethernet NIC on the IB network
Interface Card
IP over InfiniBand (IPoIB) enables applications on separate devices to communicate with each other over a
private InfiniBand fabric by using native IB protocols and without the overhead of Ethernet. For example, a
compute node on one Exalogic rack may communicate with a database on an Exadata rack. However,
applications must support the SDP protocol to use IPoIB instead of the default TCP/IP stack of the host
operating system.
The InfiniBand switches also act as gateways to connect to external Ethernet networks. They support eight
10 Gb Ethernet ports. Exalogic compute nodes can communicate through these ports by using Ethernet
over InfiniBand (EoIB). Each port is represented on the compute nodes as a VNIC. This allows that node's
IB connection to appear like any other Ethernet NIC to both the operating system and to the external
Ethernet network.

Default Compute Node Network
Private IB
Network
Compute Node
IPoIB, SDP
IB IB0 bond0
Switches VNICs IB1 bond1 eth0
EoIB
NET3 NET2 NET1 NET0 MGMT

OS, ILOM Ethernet
Client
Network
Mgmt Mgmt
Network Switch
By default, each Exalogic compute node is configured with one bonded EoIB interface for one external LAN
(client network), and is named bond1. The Cisco Ethernet management switch is connected to the NET0
port of compute nodes, the NET0 port of the storage appliance, and also the management ports of the
InfiniBand gateway switches. On the compute nodes, this connection is represented on the operating
system by an “eth” network interface, such as eth0. The compute nodes are configured at the time of
manufacturing to use sideband management only. Therefore, the MGMT (or ILOM) port is not connected,
but ILOM is accessible from NET0.

Recommended FMW Topology on Exalogic
Compute Node
Server Server
Compute Node
Client Private IB
Proxy
Network Network

Admin Server Server
Mgmt
Network
Compute Node

Exalogic Shared Storage Concepts
Term Definition
Pool High availability and replication characteristics for a collection of disks
Project Default administrative and file system settings for a collection of shares
Share A file system mount point, access protocols, access rights, and other settings
Pool

Project Project
Share Share Share Share
The appliance is based on the ZFS file system. ZFS groups the underlying storage devices into pools.
Shared file systems then allocate disk space from these pools. Before creating file systems, you must first
configure storage on the appliance. After a storage pool is configured, you do not have to statically size file
systems, although this behavior can be achieved by using quotas and reservations.
Each storage node can have any number of pools, and each pool can be assigned ownership independently
in a cluster. While an arbitrary number of pools is supported, creating multiple pools with the same
redundancy characteristics owned by the same cluster head is not advised. Doing so results in poor
performance, suboptimal allocation of resources, artificial partitioning of storage, and additional
administrative complexity.
The storage appliance exports file systems as shares, which are managed in this section of the appliance.
All file systems are grouped into projects. A project defines a common administrative control point for
managing shares. All shares within a project can share common settings, and quotas can be enforced at the
project level in addition to the share level. Projects can also be used solely for grouping logically related
shares, so their common attributes (such as accumulated space) can be accessed from a single point.

Recommended FMW Storage on Exalogic
exalogic
FMW12c-1 HR
domains
Middleware
/hrdomain
/wlserver
/jdk
nodemanager
recovery

/jms
/tlog
apps

WebLogic Server Optimizations: Overview
1. Configure WebLogic network channels to use:

– eth0 for default admin communication
– bond0 for cluster replication traffic
– bond1 for client communication (if not using a proxy)
2. Enable these features on replication channels:
– SDP
– Multiple ports
– One-way RMI
3. Enable other domain-wide Exalogic optimizations.

Most Exalogic specific WLS optimizations are not enabled by default. Some require a simple configuration
check box. But others require multiple configuration steps. For example, WLS clusters can be configured to
further improve server-to-server communication. First, you can enable multiple replication channels, which
improve network throughput among cluster members. Second, you can enable InfiniBand support via the
Sockets Direct Protocol, which reduces CPU utilization because network traffic bypasses the TCP stack.

Creating a Cluster Replication Channel
1. Create an internal T3 channel for each member of a cluster.

2. Assign the channel to the cluster (default name is “ReplicationChannel”).

3
When creating a network channel, there is not a specific protocol option available for internal cluster
replication traffic. Instead, you must configure a channel that supports the T3 protocol and specify the name
of that channel as part of a cluster’s replication settings.
1. Click Clusters and then select a cluster.
2. Click the Configuration > Replication tab.
3. Set the Replication Channel to the name of the custom network channel that you created on each
member of the cluster. As a result, these channels will be used for replication traffic instead of the
default channels on each server.

Using SDP for Replication
startWebLogic.sh:

... 3
. ${DOMAIN_HOME}/bin/setDomainEnv.sh $*
JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.net.preferIPv4Stack=true"
WLS can use SDP to bypass the operating system and communicate directly with the InfiniBand fabric for
session replication.

Using Multiple Ports for Replication
• A single replication channel cannot use the available bandwidth on the IB network.
• For convenience, simply specify a port range and multiple channels will be created and
used automatically.

3
When members of a cluster need to communicate and replicate HTTP session data for high availability, they
use an internal Java protocol called T3. Because Exalogic uses InfiniBand, establishing individual T3
connections does not take full advantage of the available bandwidth. Instead, WLS uses parallel or
“multiplexed” connections for this inter-cluster communication.
Multiple replication channels do not need to be configured on each clustered server instance. Only one
replication channel with explicit IP-Address needs to be configured for each server and replication. Port
range can be specified for each server. For example, the range 7001-7010 will create 10 replication
channels with ports 7001 to 7010 for the given server. These channels inherit all the properties of the
configured replication channel except the listen port. Names of these channels will be derived from the
name of the configured replication channel. A numeric suffix (1,2,3) will be added to each name. If you
specify a range of 10 ports, 10 additional channels will be created. Public ports are the same as the listen
port for these additional channels.

Other Replication Optimizations

As replicated Java objects are passed across the InfiniBand network, they must be serialized and
deserialized by WLS. To avoid unnecessary processing, WLS deserializes a replicated object only if the
server from which it originated has failed.

Oracle Exabus
• Is a collection of proprietary software libraries included in Exalogic base OS images

• Allows direct access to InfiniBand hardware while bypassing the kernel, including SDP
• Enables Remote Direct Memory Access (RDMA), which reduces buffer copying between
apps, kernel, and drivers.
• Is used by FMW to greatly increase performance and throughput, while also reducing
latency

Exabus consists of unique software, firmware, and device drivers, and is built on Oracle's QDR InfiniBand
technology. It includes a low-level Java API for the network communications layer that is specifically
optimized for Exalogic. The Exabus implementation uses RDMA (direct memory I/O) and other optimizations
for low latency communications.

Other WebLogic Optimizations
Subsystem Description
Threading Create more threads to take advantage of the compute node’s processing
power.
Network I/O • Use Exabus for tighter integration with native IB libraries
• Use larger packet sizes to take advantage of the IB throughput.
File I/O Use larger buffers to take advantage of the IB connection to the storage
appliance.

Traditional I/O employs the use of buffers to read and write data, and as this data is transferred between
operating system memory, JVM memory, and WLS memory (heap), it must be copied from buffer to buffer.
On Exalogic, this file I/O buffering is significantly reduced or eliminated.
InfiniBand supports much higher throughput rates compared to standard Ethernet, so WebLogic
automatically uses larger packet sizes to communicate with the InfiniBand fabric on Exalogic. This includes
external network communication as well as communication with other servers on other compute nodes.

Enabling Other Optimizations
Optimizations can be turned on and off:

• Collectively by using a domain-wide flag
• Individually by using command-line server arguments

Enabled for all servers
in this domain
To enable all general optimizations on all servers in a domain, perform the following steps:
1. Access the WebLogic Server console.
2. In the Domain Structure panel, click the name of the domain.
3. In the right panel, select the Enable Exalogic Optimizations check box.
Refer to the Deployment Guide for a complete list of server startup arguments that individually enable or
disable specific enhancements. Here are some examples:
• -Dweblogic.ScatteredReadsEnabled=true/false
• -Dweblogic.GatheredWritesEnabled=true/false
• -Dweblogic.replication.enableLazyDeserialization=true/false

What Is Exadata?
The Oracle Exadata solution:

• Combines Sun hardware and optimized Oracle software, similar to Exalogic
• Is engineered to run very large Oracle DB deployments
• Uses an InfiniBand fabric to connect nodes or “cells”
• Dedicates separate hardware to computational-intensive processing and data-intensive
processing
• Helps standardize and consolidate your data warehouse and transaction processing

The Oracle Exadata Database Machine is an easy-to-deploy solution for hosting Oracle Database that
delivers the highest levels of database performance. The Exadata Database Machine is composed of
database servers, Oracle Exadata Storage Servers, and an InfiniBand fabric for networking all the
components. It delivers outstanding I/O and SQL processing performance for online transaction processing
(OLTP) and data warehousing.
There are two versions of the Exadata Database Machine. The Exadata Database Machine X2-2 expands
from two 12-core database servers with 192 GB of memory and three Exadata Storage Servers to eight 12-
core database servers with 768 GB of memory and 14 Exadata Storage Servers, all in a single rack. The
Exadata Database Machine X2-8 comprises two
64-core database servers with 2 TB of memory and 14 Exadata Storage Servers in a single rack.
Exadata Smart Flash Cache dramatically accelerates Oracle Database processing by speeding I/O
operations. The Flash provides intelligent caching of database objects to avoid physical I/O operations. The
Oracle database on the Database Machine is the first Flash-enabled database. Exadata storage uses an
advanced compression technology, Exadata Hybrid Columnar Compression, that typically provides 10 times
and higher levels of data compression than a traditional database server.

Exadata InfiniBand Connectivity
Applications on Exalogic and databases on Exadata can:

• Share the same IB fabric
• Directly communicate with each other by using IPoIB
• Enable SDP
Exalogic Exadata
Compute Node
IPoIB, SDP
Application

DB
Application
It is possible to connect as many as eight full racks of Exalogic hardware (or any combination of Exalogic
and Exadata configurations) without the need for any external switches. In cases where more than eight
racks of Exalogic or Exadata hardware are required, Oracle offers a choice of several high-capacity data
center switches that enable the creation of Exalogic clouds comprising hundreds of racks and tens of
thousands of processors.

Enabling SDP for Exadata Connectivity
Edit the default data source configuration and change all occurrences of “TCP” to “SDP” in
the URL.
startWebLogic.sh:

...
. ${DOMAIN_HOME}/bin/setDomainEnv.sh $*
JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.net.preferIPv4Stack=true
–Doracle.net.SDP=true"
Oracle Net Services provides support for the Sockets Direct Protocol (SDP) for InfiniBand high-speed
networks. For example, InfiniBand can be used to connect an Exalogic machine to an Exadata machine.
SDP is characterized by short-distance, high-performance communications between multiple server
systems.
Simply connecting the machines with InfiniBand cables is not sufficient—WebLogic and RAC will still
communicate by using TCP (IPoIB). First, configure an SDP address in the listener.ora file on the
database server. Then edit your GridLink data source by using the WLS console. On the Configuration >
Connection Pool tab, locate the URL field. Replace all instances of the text PROTOCOL=TCP with
PROTOCOL=SDP. Finally, use the Control tab to restart the data source.
Note that in order to use SDP, you will also need to add a command-line argument when starting your
WebLogic Servers: -Djava.net.preferIPv4Stack=true. For example, edit startWebLogic.sh.

C
Oracle Cloud
An Overview

Agenda
1 What is Cloud Computing?

2 Cloud Evolution
3 Components of Cloud Computing
4 Characteristics and Benefits of Cloud
5 Cloud Deployment Models
6 Cloud Service Models
7 Oracle Cloud Services

Oracle WebLogic Server 12c: Administration II C - 2

What Is Cloud?
The term Cloud refers to a network or the Internet.
It is a means to access any software that is available remotely.


What Is Cloud Computing?
• It is a means to access any software that is available remotely.

• Refers to the practice of using remote servers hosted on the Internet to store, manage
and process data
• When you store your photos online instead of on your
home computer, or use webmail or a social networking
site, you are using a “cloud computing” service.


History – Cloud Evolution
Cloud Computing
SaaS Computing
Next generation
Utility Computing Internet
Grid Computing Network-based computing and
Offering subscription to next generation
Silos Computing computing applications data centers
Solving large resources as a
problems with metered
Basic computing service
parallel
with dedicated
computing
physical
hardware


Components of Cloud Computing
Client Computers Distributed Servers Data Centers
Data

Devices by which end Often servers are in Collection of servers
users interact with cloud. geographically different where an application is
Types of client: thick, places, but server acts as placed and is accessed via
thin (most popular), mobile if they are next to each the Internet
other.

Characteristics of Cloud
Description
• Allows users to use the service on demand
On Demand
Rapid Self Service
Ubiquitous
• Anywhere, Anytime and Any Device
Elasticity Network Access
• Draw from a pool of computing resources,
usually in remote data centers
Measured Resource • Request and manage own computing
Service Pooling
resources
• Service is measured and customers are billed
Pay as you Virtualization accordingly
use
Application • Select a configuration of CPU, Memory and

Programming
Interface storage
• Services can be scaled larger or smaller

Cloud Deployment Models
Deployment models define the type of access to the Cloud.
• The platform for cloud

• Type of cloud hosting in which computing is implemented on
the cloud services are a cloud-based secure
delivered over a network which environment, safeguarded by
is open for public usage a firewall that is under the
Public Private governance of the IT
Cloud Cloud department that belongs to
the particular organization.
Hybrid Community
Cloud Cloud
• It is an arrangement of two or
more cloud servers, i.e. •Type of cloud hosting in which

private, public or community the setup is mutually shared
cloud that is bound together between many organizations
but remain individual entities.

Cloud Service Models
All three tiers of computing delivered as Service via global network

• Applications: Software as a Service - SaaS
• Platform: Database, Middleware, Analytics, Integration as a Service – Platform as a
Service - PaaS
• Infrastructure: Storage, Compute, and Network as a service – Infrastructure as a
Service - IaaS

SaaS PaaS IaaS

• Provides computer hardware (servers, networking technology,

storage and data center space) as a web based service.
• Virtual machines with pre-installed operating system
• Target: Administrators
IT Professional
Customizations • “Ready to Rent”
Consumer
Application
Platform
Provider

IaaS

• Provides platform to develop and deploy applications

• Up to date software
• Target: Application developers
• “Ready to Use”
Developer
Customizations
Consumer
Application

Provider
PaaS

• Allows usage of the software remotely as a web based

service
• Software are automatically upgraded and updated
Business End User • All users are running the same version of the software
Consumer
Customizations
• Target: End users
• “Ready to Wear”
Provider

SaaS

Industry Shifting from On-Premises to the Cloud
Transition to the Cloud is driven by a desire for:

• Agility - Self-service provisioning – deploy a database in minutes
• Elasticity - Scale on demand
• Lower cost - Reduction in management and total cost – pay for what is used
• Back to core business – Focus on core activities
• More mobility – Access from any device



Oracle IaaS Overview IaaS
Designed for large enterprises, which allow them to scale up their computing, networking, and storage
systems into the cloud, rather than expanding their physical infrastructure.
• Allows large businesses and organizations to run their workloads, replicate their network, and
back up their data in the cloud


Oracle PaaS Overview PaaS
• Develop, deploy, integrate and manage applications on cloud.

• Seamless integration across PaaS and SaaS Applications.


Oracle SaaS Overview SaaS
Delivers modern cloud applications that connect business processes across the enterprise.
• Only Cloud integrating ERP, HCM, EPM, SCM
• Seamless co-existence with Oracle’s On-Premise Applications


Summary
In this lesson, you should have learned to:

• Provide an overview of Cloud computing, its characteristics, history and technology
• Describe the various components, deployment models, and service models of Cloud
computing
• Describe the Oracle Cloud Services


D
Oracle Java Cloud Service Overview

Objectives

• Get an overview of Java Cloud Service
• Describe the features of Java Cloud Service

Oracle WebLogic Server 12c: Administration II D - 2

Introducing Java Cloud Service Key Oracle Cloud
component
Your platform for running business applications in the cloud
• Self-service application platform with advanced cloud
tools
• Save time and cost with simplified provisioning
• Reduce down time: automated patching, backup,
recovery
• Increase data and processing capacity on demand to
scale for new business needs
• Optionally enable Oracle Coherence for caching and data
grid functions and Oracle Traffic Director for load
balancing JAVA CLOUD SERVICE

• Pre-configured for Database and Developer Cloud
Services for complete cloud application management

Java Cloud Service: Three Options
JAVA CLOUD SERVICE

SAAS EXTENSION
• Easy to enrich Oracle SaaS apps

• Tailored-made WebLogic Server for
rapid extension deployment
• Ready marketplace with pre-built
extensions, automated deployment
JAVA CLOUD SERVICE

JAVA CLOUD SERVICE
Full-featured Service VIRTUAL IMAGE
• Simple, hosted WebLogic instance

• Oracle controlled, updated

Java Cloud Service Main Use Cases
Dev/Test in the New App Development Migrate Apps to Cloud Strategic Outsourcing
Cloud Recapture


Java Cloud Service Feature: Provisioning
• Can pick shape/size – no
complexity
• Choose from popular versions:
11g or 12c
• Meet evolving technical and
budgetary needs with popular
Edition choices: Standard,
Enterprise, Suite


Java Cloud Service Feature: Patching
• Patching made simple –

Oracle handles the details
• You control patch timing -
on demand or scheduled
• Includes unified patching of
JDK, WLS, JRF/ADF
• Supports rolling patching
• Supports Patchset Updates
(PSUs), Patchsets (PS),
Upgrades

• Don’t mess with backups!
Full backup created before
patching

Java Cloud Service Feature: Backup / Restore
• Coordinated backups with database and

whole cloud stack - holistic backups
• You choose - scheduled or on demand
• Multiple depths supported:

configuration/apps, logs, binaries, and
database
• Configurable: Seven-day backup on local
disk, older backups pushed to storage
service

Java Cloud Service Feature: Scaling
• Fully-automated, on-
demand – do it yourself
without IT!
• Each managed server on
separate virtual machine
• Zero downtime during
scaling – keep customers
happy
• Scale data capacity and
processing up/down on
demand

• Rules to trigger scaling
based on current workload

Oracle Coherence Option: Data Caching & Scaling
• Scaling applications’ caching/data grid

capacity in-memory to support growth
• Offload and protect shared cloud services
and databases
• Delivery of data to cloud apps in real time
• Transparency and high-availability in the
+ cloud’s data grid tier

JAVA CLOUD SERVICE

Oracle Coherence Option: Your Cloud Data Grid
Scalable, fault-tolerant cloud infrastructure
• Reliable In-Memory key-value store
• Dynamically scalable
• Scale processing with data
• Entries can be:
– Reliably processed in-place
– Queried
– Aggregated
• Integration with Database and Developer Cloud
Services


How You Interact with Java Cloud Service
• New Cloud Portal

FMW Control/
WebLogic Admin Console • WebLogic Admin Console
• Fusion Middleware Control
Oracle Cloud Portal WLS
T
• Traffic Director Admin Console
• Public REST APIs
• Command Line Interface
• SSH or VNC to VM
JAVA CLOUD
REST API
• Standard IDEs
SERVICE


Speaking of Dev Environments… Developer Cloud Service
• Complete, Integrated Development Platform - as a Service

• Application Lifecycle Management
• Team Management
• Entitlement with Java Cloud Service


Java Cloud Service On-Premises!
• If you want to use public cloud, but can’t

• Geography, political, other reasons
• Same public experience, but on-premises
• Runs on Oracle Cloud Machine in your data
center
JAVA CLOUD SERVICE
JAVA CLOUD

SERVICE

Summary
In this lesson, you should have learned to:

• Provide an overview of Java Cloud Service
• Describe the features of Java Cloud Service

D80153GC30 sg2

Uploaded by

Copyright:

Available Formats

D80153GC30 sg2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D80153GC30 sg2

Uploaded by

Copyright:

Available Formats

Oracle Internal & Oracle Academy Use Only

Oracle WebLogic Server 12c:

Student Guide – Volume II

Learn more from Oracle University at education.oracle.com

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

2 WebLogic Server Review

3 Upgrading WebLogic Server

Oracle Internal & Oracle Academy Use Only

4 Creating and Using Domain Templates

5 WebLogic Server Startup and Crash Recovery

Oracle Internal & Oracle Academy Use Only

6 WebLogic Scripting Tool (WLST)

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

7 RESTFul Management Services

8 Secure Sockets Layer (SSL)

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

10 Working with the Security Realm

Oracle Internal & Oracle Academy Use Only

11 Disaster Recovery and Migration

Oracle Internal & Oracle Academy Use Only

12 Managing Data Sources

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

14 WebLogic and Coherence Integration

15 Application Staging and Deployment Plans

Oracle Internal & Oracle Academy Use Only

16 WebLogic, Docker, and Kubernetes

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

B WebLogic Optimizations for Exalogic

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Disaster Recovery and Migration

Oracle Internal & Oracle Academy Use Only

After completing this lesson, you should be able to:

Oracle Internal & Oracle Academy Use Only

Oracle WebLogic Server 12c: Administration II 11 - 2

• Disaster Recovery (DR)

Oracle Internal & Oracle Academy Use Only

Oracle WebLogic Server 12c: Administration II 11 - 3

Oracle Internal & Oracle Academy Use Only

Oracle WebLogic Server 12c: Administration II 11 - 4

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates. All rights reserved.

Oracle WebLogic Server 12c: Administration II 11 - 5

Oracle recommends symmetric configurations, because they:

Standby Type Description

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates. All rights reserved.

Oracle WebLogic Server 12c: Administration II 11 - 6

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates. All rights reserved.

Oracle WebLogic Server 12c: Administration II 11 - 7

Oracle Internal & Oracle Academy Use Only

Oracle WebLogic Server 12c: Administration II 11 - 8

10.100.1.50 hradmin-prod.mycompany.com hradmin.mycompany.com