D56082GC10 sg3

Oracle University and African Legend Indigo (PTY) LTD use only
Oracle WebLogic Server 10g R3:

System Administration
Volume III Student Guide
D56082GC10
Edition 1.0
March 2009
D58926
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
COMPUTER IS STRICTLY PROHIBITED
Author Copyright 2009, Oracle. All rights reserved.
Vishal Parashar Disclaimer
This document contains proprietary information and is protected by copyright and

Technical Contributors 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 in
and Reviewers any way. Except where your use constitutes "fair use" under copyright law, you may
not use, share, download, upload, copy, print, display, perform, reproduce, publish,
Ken Cooper
license, post, transmit, or distribute this document in whole or in part without the
Steve Friedberg express authorization of Oracle.
Balamurali Kothandaraman
The information contained in this document is subject to change without notice. If you
Robert Lavallie find any problems in the document, please report them in writing to: Oracle University,
Thomas Palazzolo 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
warranted to be error-free.
Editors Restricted Rights Notice
Vijayalakshmi Narasimhan If this documentation is delivered to the United States Government or anyone using
Joyce Raftery the documentation on behalf of the United States Government, the following notice is
applicable:
Graphic Designer U.S. GOVERNMENT RIGHTS

The U.S. Governments rights to use, modify, reproduce, release, perform, display, or
Priya Saxena disclose these training materials are restricted by the terms of the applicable Oracle
license agreement and/or the applicable U.S. Government contract.
Publishers Trademark Notice
Sujatha Nagendra Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other
names may be trademarks of their respective owners.
Joseph Fernandez
Veena Narasimhan
Contents
Preface
1 Installing Oracle WebLogic Server Environment
Objectives 1-2
Road Map 1-3
Distributed Systems 1-4
How Standards Help 1-6
The J2EE Standard 1-7
The J2EE Architecture 1-8
Java Servlets 1-9
JavaServer Pages (JSPs) 1-10
Enterprise JavaBeans (EJBs) 1-11
Java Database Connectivity (JDBC) 1-12
Java Naming and Directory Interface (JNDI) 1-13
Java Transaction API (JTA) 1-14
Java Message Service (JMS) 1-15
Java Authentication and Authorization 1-16
Java Management Extensions (JMX) 1-17
Client Application 1-18
Web Client 1-19
Proxy Server 1-20
Firewalls 1-21
Web Server 1-22
Application Servers 1-23
Web Application Server Configuration 1-24
Application Server Configuration 1-25
Domain 1-26
Why Use Domains 1-28
Domain Restrictions 1-30
Server 1-31
Administration Server 1-32
Managed Server 1-34
Interaction Between the Administration Server and the Managed Server 1-35
Machine 1-36
Cluster 1-37
iii
Cluster Guidelines 1-39
Node Manager 1-40
Road Map 1-43
Oracle WebLogic Server Installation 1-44
GUI Mode Installation 1-46
Choosing an Installation Type and Products 1-47
Choosing the JDK and Product Directory 1-48
Installation and Summary 1-49
Console and Silent Mode Installations 1-51
Postinstallation: Oracle Home 1-52
Oracle WebLogic Server Directory Structure 1-53
Samples Directory Structure 1-55
Setting Environment Variables 1-56
Quiz 1-57
Summary 1-65
2 Configuring Oracle WebLogic Server Environment

Objectives 2-2
Road Map 2-3
Domain Overview 2-4
Domain Diagram 2-6
Configuring a Domain 2-7
Starting the Domain Configuration Wizard 2-8
Flow Chart to Create a Domain Using the Domain Configuration Wizard 2-9
Creating a New WebLogic Domain and Selecting the Domain Source 2-10
Configuring Administrator Settings, Start Mode, and JDK 2-11
Customizing the Environment and RDBMS Security Store 2-12
Configuring the Administration and Managed Servers 2-14
Configuring Clusters and Assigning Servers to Clusters 2-15
Creating an HTTP Proxy Application and Configuring Machines 2-17
Assigning Servers to Machines and Configuring JDBC Data Sources 2-19
Configuring JDBC Data Sources 2-20
Testing Data Source Connections and Running Database Scripts 2-23
Configuring the JMS File Store and Reviewing the WebLogic Domain 2-25
Creating the WebLogic Domain 2-27
Domain Directory Structure 2-28
JVM Run-Time Arguments 2-30
Oracle WebLogic Server Dependencies 2-31
Configuring CLASSPATH 2-32
Starting Oracle WebLogic Administration Server 2-34
iv
Starting Administration Server Using the
java weblogic.Server Command 2-36
Starting Administration Server Using startWebLogic.sh 2-37
Road Map 2-39
Configuring Managed Servers 2-40
Configuring Machines 2-42
Starting Oracle WebLogic Managed Servers 2-43
Starting a Managed Server Using the java weblogic.Server Command 2-44
Starting a Managed Server Using startManagedWebLogic.sh 2-46
Starting a Managed Server Using the Administration Console 2-48
Creating a Boot Identity File 2-49
Demonstration 2-51
Managed Server Independence (MSI) 2-52
When the Administration Server Is Down 2-55
Restarting an Administration Server on a New Machine 2-56
Running Multiple WLS Instances 2-57
Road Map 2-58
Custom Domain Templates 2-59
Domain Template Builder 2-61
Creating a Domain Template 2-62
Selecting the Template Domain Source and Describing the Template 2-63
Adding Files and SQL Scripts to the Template 2-64
Configuring the Administration Server, Username, and Password 2-66
Configuring Users, Groups, and Roles 2-67
Assigning Users to Groups and Assigning Groups to Groups 2-69
Assigning Users and Groups to Global Roles 2-70
Start Menu Entries for Windows and Prepare Scripts and Files with Replacement
Variables 2-71
Reviewing the WebLogic Domain Template and Creating a Template 2-73
Successful Template Creation 2-74
Road Map 2-75
Using the Administration Console 2-76
Accessing the Console 2-77
Console Login 2-78
Basic Navigation 2-79
General Console Preferences 2-80
Advanced Console Options 2-81
Setting Basic Properties 2-82
Shutting Down a Server 2-83
XML Schema for config.xml 2-84
v
Configuration Change Management 2-86
Console Change Center 2-87
Domain Configuration Repository 2-88
Configuration Change Process 2-89
Predictable Distribution of Domain Configuration Changes 2-90
Configuration Management Architecture 2-91
WebLogic Scripting Tool (WLST) 2-93
Jython 2-94
Using Jython 2-95
WLST Modes 2-96
WLST Example 2-97
WLST Command Requirements 2-98
Running WLST Scripts 2-99
Importing WLST as a Jython Module 2-100
General WLST Commands 2-101
Offline WLST Commands 2-102
Creating a Domain: Example 2-103
Online WLST Commands 2-104
WebLogic JMX: Overview 2-105
Navigating JMX MBeans 2-106
Creating a Server: Example 2-103
Generating a WLST Script 2-108
Quiz 2-109
Summary 2-127
3 Managing and Monitoring the Oracle WebLogic Server Environment

Objectives 3-2
Road Map 3-3
Node Manager 3-4
What Node Manager Can Do 3-5
Node Manager Architecture 3-7
How Node Manager Starts an Administration Server 3-8
How Node Manager Starts a Managed Server 3-9
How Node Manager Restarts an Administration Server 3-10
How Node Manager Restarts a Managed Server 3-11
How Node Manager Shuts Down a Server Instance 3-12
Versions of Node Manager 3-13
Node Manager Configuration 3-15
Node Manager Default Behaviors 3-16
Configuring Java-Based Node Manager 3-17
Starting Node Manager at System Startup 3-19
vi
Configuring Node Manager as a Windows Service 3-20
Daemonizing Node Manager for UNIX Systems 3-21
Starting Oracle WebLogic Server at Boot 3-23
Oracle WebLogic Server as a Windows Service 3-24
Setting up Windows Service 3-25
Oracle WebLogic Server as a Unix Daemon 3-27
Oracle WebLogic Server at Boot 3-28
Example rc Scripts 3-29
Configuring Java-Based Node Manager Security 3-31
Administration Console Node Manager Security 3-33
Remote Server Start Security for the Java-Based Node Manager 3-34
Reviewing nodemanager.properties 3-35
Configuring Node Manager on Multiple Machines 3-37
Configuring Script-Based Node Manager 3-39
Creating a Node Manager User 3-40
Configuring Script-Based Node Manager Security 3-41
Additional Configuration Information 3-43
Configuring a Machine to Use Node Manager 3-44
Configuring the nodemanager.domains File 3-45
Configuring Remote Startup Arguments 3-46
Ensuring that the Administration Server Address Is Defined 3-48
Setting Node Manager Environment Variables 3-49
Node Manager Configuration and Log Files 3-50
Road Map 3-53
Oracle WebLogic Server Logs 3-54
Server and Domain Logs 3-56
Configuring Server Logging 3-57
Viewing Logs with the Console 3-59
Message Attributes 3-60
Message Severity 3-61
Message Catalog 3-62
Log Filters 3-64
Creating a Log Filter 3-65
Applying a Log Filter 3-66
Console Monitoring 3-67
Monitoring All Servers 3-68
Customizing the View for All Servers 3-70
Monitoring Individual Servers 3-71
Road Map 3-72
Network Addressing Features 3-73
vii
Network Channels 3-75
Configuring Network Channels 3-76
Using Channels: Example 1 3-77
Using Channels: Example 2 3-78
Administration Port 3-79
Overriding the Administration Port 3-83
Quiz 3-84
Summary 3-87
4 Basic Deployment
Objectives 4-2
Road Map 4-3
The Role of Web Servers 4-4
A Typical Web Interaction 4-5
MIME Types 4-7
HTTP Status Codes 4-8
Static Content 4-9
Dynamic Content 4-10
Road Map 4-11
Java EE Web Applications 4-12
Packaging Web Applications 4-14
Web Application Structure 4-15
Configuring Web Applications 4-18
web.xml 4-20
weblogic.xml 4-21
The weblogic.xml Deployment Descriptor 4-22
Web Application Archive 4-23
URLs and Web Applications 4-25
Web Service Applications 4-26
Virtual Directory Mappings 4-27
Virtual Directory Mapping: Example 4-28
Archive Versus Expanded Directory 4-29
Road Map 4-30
EJB Applications 4-31
Types of EJBs 4-32
weblogic-ejb-jar.xml 4-35
EJB Administrator Tasks with WLS 4-36
Road Map 4-37
What Is an Enterprise Application? 4-38
A Typical Java EE System 4-39
viii
J2EE Enterprise Application 4-40
Java EE Enterprise Applications 4-41
Why Enterprise Applications? 4-42
Enterprise Application Structure 4-43
weblogic-application.xml 4-44
Configuring WLS-Specific Features 4-45
WLS Application Classloader 4-46
EAR Class Libraries 4-47
J2EE Library Support 4-48
WebLogic Shared Java EE Libraries 4-49
Shared Library References 4-50
Road Map 4-51
Deployment Process: Overview 4-52
Deployment Methods 4-53
Deployment Tools 4-54
Auto-Deployment Copying Files 4-55
Auto-Deployment 4-56
FastSwap and On-Demand Deployment 4-57
Development Versus Production Modes 4-59
Production Mode Flag 4-60
Console Deployment Method 4-61
Preparing a New Application 4-63
Deploying or Undeploying Applications 4-65
Redeploying an Application 4-66
Console Deployment 4-67
Editing Deployment Descriptors 4-69
Monitoring an Application 4-70
Application Testing 4-71
Application Update and Delete 4-72
Command-Line Deployment 4-75
Deployment with weblogic.Deployer 4-76
weblogic.Deployer: Examples 4-77
Deploying Applications with WLST 4-78
Deploying an Application with WLST 4-79
Deployment with WLST 4-80
Quiz 4-81
Summary 4-84
ix
5 Understanding JNDI
Objectives 5-2
Road Map 5-3
What Is JNDI? 5-4
Why JNDI? 5-5
JNDI Structure 5-6
Naming Service 5-7
JNDI Tree 5-8
Contexts and Subcontexts 5-10
JNDI for Administrators 5-11
Viewing the JNDI Tree 5-12
Listing the JNDI Contents 5-13
Summary 5-14
6 Setting Up JDBC
Objectives 6-2
Road Map 6-3
What Is JDBC? 6-4
JDBC Review 6-5
JDBC Data Sources 6-6
Data Source Scope 6-7
Two-Tier Architecture 6-8
Multi-Tier Architecture 6-9
JDBC Architecture 6-10
Type 1 Driver 6-11
Type 2 Driver 6-12
Type 3 Drivers 6-13
Type 4 Drivers 6-15
WebLogic JDBC Drivers 6-16
Choosing the Correct Driver 6-18
Road Map 6-19
What Is a Data Source? 6-20
What Is a Connection Pool? 6-21
Benefits of Data Sources and Connection Pools 6-22
JDBC Data Source Architecture 6-23
Modular Configuration and Deployment of JDBC Resources 6-24
How Data Sources Are Used 6-25
Creating a Data Source 6-26
Connection Pool Configuration 6-28
Targeting a Data Source 6-29
Viewing the Server JNDI Tree 6-30
x
Demonstration 6-31
Connection Pool Checklist 6-32
JDBC URLs 6-33
JDBC URL Examples 6-34
Connection Properties 6-35
Multi Data Sources 6-37
Road Map 6-39
Monitoring and Testing a Data Source 6-40
Quiz 6-41
Summary 6-44
7 Setting Up Java Message Service (JMS) Applications

Objectives 7-2
Road Map 7-3
Message-Oriented Middleware 7-4
Point-to-Point Queue 7-5
Publish-Subscribe Topics 7-6
Oracle WebLogic Server JMS Features 7-7
JMS Architecture: Connecting 7-9
JMS Architecture: Sending Messages 7-10
Transacted Messaging 7-11
Administrative Tasks 7-12
Oracle WLS JMS Server 7-13
Creating a JMS Server 7-14
Targeting a JMS Server 7-15
Configuring a JMS Server 7-16
JMS Resources 7-17
Modular JMS Resource Configuration and Deployment 7-19
Connection Factories 7-21
Creating a Connection Factory 7-23
Configuring a Connection Factory 7-24
Destination 7-25
Queue Destinations 7-26
Topic Destinations 7-27
Creating a Destination 7-28
Creating a Queue Destination 7-30
Threshold and Quota 7-32
Configuring Thresholds and Quotas 7-33
Road Map 7-34
Durable Subscribers and Subscriptions 7-35
When to Use Persistent Messaging 7-36
xi
How a Durable Subscription Works 7-37
Configuring a Durable Subscription 7-38
Persistent Messaging 7-39
Creating a JMS Store 7-40
Creating a JMS JDBC Store 7-41
Assigning a Store to a JMS Server 7-43
Persistent Connection Factory 7-44
Configuring a Persistent Destination 7-45
Road Map 7-46
Statistics for JMS Objects 7-47
Monitoring JMS Servers 7-48
Monitoring and Managing Destinations 7-49
Quiz 7-50
Summary 7-52
8 Managing Transactions
Objectives 8-2
Road Map 8-3
What Is a Transaction? 8-4
ACID Properties of a Transaction 8-5
Transaction Management 8-6
Transferring Without Transactions 8-7
Successful Transfer with Transactions 8-8
Unsuccessful Transfer with Transactions 8-9
Types of Transactions 8-10
The Two-Phase Commit Protocol 8-12
Extended Architecture Protocol 8-13
Transaction and Resource Managers 8-14
Successful Two-Phase Commit 8-16
Unsuccessful Two-Phase Commit 8-17
Java Transaction API (JTA) 8-18
Configuring Transactions 8-19
Configuring the Transaction Log 8-20
JTA Configuration Options 8-23
Creating XA Resources 8-27
Creating Non-XA Resources 8-28
Logging Last Resource 8-30
Transacted Messaging 8-31
Inter-Domain Transactions 8-32
Enabling Trust Among Different Domains 8-34
Monitoring Transactions 8-35
xii
Monitoring Transactions by Resource 8-37
Viewing Transaction Statistics for XA Resources 8-38
Summary 8-40
9 Securing WLS Resources and Applications

Objectives 9-2
Road Map 9-3
Architecture Goals 9-4
Security Architecture 9-5
Process Architecture 9-6
Security Services 9-7
Authentication Providers 9-8
Authorization Providers 9-10
Confidentiality 9-12
Credential Mapping 9-13
Auditing 9-14
Road Map 9-15
Security Realms 9-16
What Is LDAP? 9-17
Embedded LDAP Server 9-18
Configuring Embedded LDAP 9-19
Connecting Using an External LDAP Browser 9-21
Users and Groups 9-22
Configuring New Users 9-23
Groups 9-24
Configuring New Groups 9-25
Adding Groups to Users 9-26
Roles 9-27
Configuring New Roles 9-29
Migrating Security Data 9-30
Exporting the WLS Default Authenticator Provider 9-31
Importing into a Different Domain 9-32
Demonstration 9-33
Road Map 9-34
J2EE Declarative Security 9-35
Using Deployment Descriptors 9-36
Protecting Web Applications 9-37
Defining Security Roles 9-38
Determining Protected Resources 9-39
Mapping Roles to Resources 9-40
Mapping Roles to Users in Realms 9-42
xiii
Setup Authentication 9-43
Authentication Examples 9-44
Policies and Roles 9-45
Defining Policies and Roles for Web Resources 9-47
Defining Policies and Roles for Other Resources 9-48
Road Map 9-50
What Is SSL? 9-51
Trust and Identity 9-52
Using an SSL Connection 9-53
Enabling Secure Communication 9-55
Oracle WebLogic Server SSL Requirements 9-57
keytool Utility 9-58
Obtaining a Digital Certificate: keytool Examples 9-59
Configuring SSL for an Oracle WebLogic Server 9-61
Configuring Keystores 9-62
Road Map 9-63
Protecting Against Attacks 9-64
Man-in-the-Middle Attacks 9-65
Man-in-the-Middle Countermeasures 9-66
Configuring Hostname Verifier 9-68
Denial of Service Attacks 9-69
DoS Countermeasures 9-70
Filtering Network Connections 9-71
Connection Filter 9-72
Consuming WLS Resources 9-73
Large Buffer Attacks 9-74
Connection Starvation 9-76
User Lockout 9-78
Configuring User Lockout 9-79
Unlocking Users 9-80
Protecting the Administration Console 9-81
Summary 9-83
10 Advanced Deployment
Objectives 10-2
Road Map 10-3
What Is a Deployment Plan? 10-4
Deployment Plans 10-5
Deployment Plan: Advantages 10-6
Configuring an Application for Multiple Deployment Environments 10-7
Sample Deployment Plan 10-9
xiv
Creating a Deployment Plan 10-10
Creating a New Deployment Plan 10-12
weblogic.PlanGenerator 10-13
Using the Administration Console to Generate a Deployment Plan 10-14
Using an Existing Deployment Plan to Configure an Application 10-15
Using an Existing Deployment Plan 10-17
Generic File Loading Overrides 10-18
Directory Structure for Easier Production Deployment 10-19
Sanity Checking in Production Without Disruption to Clients 10-21
Road Map 10-22
Staged Deployment 10-23
Road Map 10-24
Production Redeployment 10-25
Application Availability 10-27
WebLogic Production Redeployment 10-28
Advantages of Production Redeployment 10-31
Requirements and Restrictions for Production Redeployment 10-32
Redeploying a New Application Version 10-34
Redeploying Versus Distributing 10-35
Distributing a New Version of the Production Application 10-36
Distributing a New Application Version 10-38
Quiz 10-41
Summary 10-44
11 Introduction to Clustering
Objectives 11-2
Road Map 11-3
Definition: Clustering 11-4
What Is a Cluster? 11-5
Benefits of Clustering 11-7
Key Capabilities 11-9
Cluster Architecture 11-11
Deciding on a Cluster Architecture 11-12
Basic Cluster Architecture 11-13
Multitier Cluster Architecture 11-15
Basic Cluster Architecture: Advantages and Disadvantages 11-16
Multitier Advantages and Disadvantages 11-18
Proxy Servers 11-20
Basic Cluster Proxy Architecture 11-21
xv
Multitier Cluster Proxy Architecture 11-22
WLS HttpClusterServlet 11-23
WLS Plug-Ins 11-24
Proxy Plug-In Versus Load Balancer 11-27
Architecture Recommendations 11-28
Road Map 11-29
Cluster in Networks 11-30
Local Area Networks 11-31
Metropolitan Area Networks 11-32
Wide Area Networks 11-33
Road Map 11-34
Server Communication in a Cluster 11-35
Cluster Communication 11-37
Detecting a Failure 11-39
One-to-Many Communications 11-40
Peer-to-Peer Communications 11-42
Multitier Communications 11-43
Communication in a WAN 11-44
Summary 11-45
12 Configuring a Cluster
Objectives 12-2
Road Map 12-3
Preparing Your Environment 12-4
Cluster Architecture 12-5
Network and Security Topology 12-6
Security Options for Cluster Architectures 12-8
Hardware 12-9
Clustering on One Piece of Hardware 12-10
Names and Addresses 12-11
Cluster Address 12-12
Road Map 12-13
Configuration Options 12-14
Creating a Cluster 12-15
Adding Cluster Members: Option 1 12-16
Adding Cluster Members: Option 2 12-17
Creating a Cluster by Using the Administration Console 12-18
Configuring Cluster Communication 12-21
Adding Servers 12-22
Creating a Cluster with the Configuration Wizard 12-24
Clusters and the Configuration Wizard 12-25
xvi
Using the Cluster MBean 12-26
Clusters and WLST 12-27
Starting Servers in a Cluster 12-28
Road Map 12-30
High Availability for HTTP Clients 12-31
WebLogic Proxy Servers 12-33
Creating the WebLogic Proxy Server with the Configuration Wizard 12-34
Creating the WebLogic Proxy Server Manually 12-35
Configuring HttpClusterServlet 12-36
Specifying Initial Parameters 12-37
Servlet Mapping 12-38
HttpClusterServlet Initialization Parameters 12-39
Web Server Plug-Ins 12-41
Installing the Apache Plug-In 12-42
Configuring the Apache Plug-In 12-43
General Plug-In Parameters 12-48
Apache Plug-In and SSL 12-49
Configuring Apache Plug-In SSL 12-50
Quiz 12-51
Summary 12-54
13 Managing Clusters
Objectives 13-2
Road Map 13-3
Packaging Applications 13-4
Two-Phase Deployment 13-5
Deploying Applications to a Cluster 13-6
Production Redeployment in a Cluster 13-7
Deploying Applications to a Cluster 13-8
Road Map 13-11
HTTP Session Failover 13-12
HTTP Session State Replication 13-13
Machines 13-14
Replication Groups 13-15
Configuring Replication Groups 13-17
Secondary Ranking 13-18
In-Memory Replication 13-19
In-Memory Replication and Proxy Servers 13-20
In-Memory Replication: Example 13-21
In-Memory Replication 13-22
Failover with Load balancer 13-24
xvii
Requirements for In-Memory Replication 13-25
Configuring In-Memory Replication 13-26
JDBC Replication 13-28
Persistent JDBC Replication 13-29
Configuring JDBC Replication 13-30
JDBC Persistent Table Configuration 13-31
File Replication 13-33
File Persistence 13-34
Configuring File Replication 13-35
Cross-Cluster Replication 13-37
MAN and WAN Replication 13-38
Configuring Cross-Cluster Replication 13-39
State Management Best Practices 13-40
Road Map 13-41
Server Version 13-42
Multicast 13-43
Test Multicast: Example 13-44
CLASSPATH 13-46
Garbage Collection 13-47
Quiz 13-48
Summary 13-51
14 Clustering EJB Objects

Objectives 14-2
Road Map 14-3
Oracle WebLogic Server EJB Clustering Capabilities 14-4
High Availability for EJBs 14-5
Levels of Clustering for EJB 14-7
Load-Balancing Clustered EJB Objects 14-8
Road Map 14-10
Stateless Session Bean: Load Balancing and Failover 14-11
Configuring EJB Clustering 14-12
Configuring Clusterable Stateless Session EJBs 14-14
Configuring Stateless Session Clusterable EJBs 14-15
Stateful Session Beans 14-16
Configuring Clusterable Stateful Session EJBs 14-17
Road Map 14-18
Read-Write Versus Read-Only 14-19
Entity Bean Cluster-Aware Home Stubs 14-20
EJB Best Practices 14-21
Summary 14-22
xviii
15 Clustering Services
Objectives 15-2
Road Map 15-3
Services That Can Be Clustered 15-4
Service Failover 15-6
Service-Level Migration 15-7
Server-Level Migration 15-9
Road Map 15-10
JNDI Clustering Support 15-11
Clusterwide JNDI Service 15-13
JNDI Naming Conflicts 15-14
Road Map 15-15
JDBC Clustering 15-16
Clustering Versus Multi Data Sources 15-17
Targeting a DataSource to a Cluster 15-18
Road Map 15-20
Transaction Recovery After Failure 15-21
Transaction Recovery Service 15-22
Recovering JTA Without a Cluster 15-24
Recovering Transactions in a Cluster 15-25
Recovering Transactions for a Failed Clustered Server (Manually) 15-26
Migrating JTA 15-28
Configuring JTA Service Migration 15-29
Manually Migrating the JTA to Another Server in a Cluster 15-30
Configuring Automatic Migration of the JTA Transaction 15-31
Configuring Automatic Migration of the JTA Transaction 15-33
Automatic Failback of the Transaction Recovery Service Back
to the Original Server 15-34
JTA Migration Limitations 15-35
Road Map 15-37
JMS Clustering Support 15-38
JMS Connection Factory Clustering 15-39
Distributed Destination 15-41
Distributed Queues 15-42
Distributed Topics 15-43
Creating a Distributed Topic 15-44
Distributed Destination Threshold and Quota 15-47
Server Affinity 15-48
Zero Consumers 15-49
Load Balancing 15-51
xix
Location Transparency 15-52
Failover 15-53
JMS Server Migration 15-54
Performing Migration 15-55
JMS Migratable Targets 15-56
Migrating JMS Data 15-58
Migration Configuration 15-59
Configuring a Migratable Target 15-60
Targeting JMS Server to a Migratable Target 15-61
Migrating Services 15-62
Summary 15-63
Appendix A: Practices and Solutions
Appendix B: Virtual Host

Objectives B-2
Understanding Virtual Hosts B-3
The Big Picture of Virtual Hosting B-4
Configuring Virtual Hosts B-5
Creating Virtual Hosts B-6
Targeting Virtual Hosts to Servers B-7
Targeting Applications to a Virtual Host B-8
Configuring Virtual Host Logging B-9
Summary B-10
Appendix C: Getting Started with BEA Guardian

Road Map C-3
Guardian Architecture C-4
Road Map C-5
Installation C-6
Guardian Workspace C-7
Updating Guardian C-8
Deploying the Agent C-9
Road Map C-10
Activate a Domain C-11
Explorer Views C-12
Domain Inventory C-14
Evaluation Summary C-15
Comparing Evaluations C-17
Submitting Support Case C-18
Guardian Security C-21
xx
Using a Proxy Server C-23
Guardian from the Command Line C-24
Summary C-25
Index
xxi
Managing Clusters
Copyright 2009, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the

following:
Deploy applications to a cluster
Manage session state in a cluster
Troubleshoot a cluster
Oracle WebLogic Server 10g R3: System Administration 13 - 2
Road Map
Deploying Applications to Clusters

Packaging Applications
Two-Phase Deployment and Production Redeployment
Session Management
Troubleshooting a Cluster
Packaging Applications
When you deploy applications to a single Managed Server,

you can deploy the applications in an exploded format.
Oracle recommends deploying packaged applications to a
cluster of Managed Servers as .war, .ear, or .jar file
Two-Phase Deployment
Applications are deployed using two-phase deployment

(TPD).
Applications are copied to the cluster and activated in two
phases:
Phase 1: Application components and modules are
distributed to the server.
Phase 2: The application is deployed if phase 1 is successful
and client access is permitted.
This ensures that an application is available and active on
each node before clients can access it.
Two-Phase Deployment
WebLogic clusters use the concept of two-phase deployment. Applications are deployed in two
phases:
Phase 1: During the first phase of deployment, application components are distributed to
the target server instances and the planned deployment is validated to ensure that the
application components are successfully deployed. During this phase, user requests to the
application being deployed are not allowed.
Phase 2: After the application components are distributed to targets and validated, they are
fully deployed on the target server instances, and the deployed application is made
available to the clients.
If a failure occurs during this process, deployment to that server instance is canceled. However,
a failure on one Managed Server does not prevent successful deployment on other clustered
server instances.
If a cluster member fails to deploy an application, it fails at startup in order to ensure cluster
consistency, because any failure of a cluster-deployed application on a Managed Server causes
the Managed Server to abort its startup.
You would want to avoid situations in which an application is successfully deployed on one
node and not on the other; otherwise the clients would access partially deployed applications.
Two-phase deployment prevents this.
Deploying Applications to a Cluster
All nodes must be running before an application is

deployed to a cluster.
If phase 2 of the two-phase deployment fails, the
application is still deployed to other nodes in the cluster.
WebLogic allows partial deployment of applications to a
partitioned server.
Session replication for deployed applications may fail if a
node is partitioned at the time of deployment.
Avoid this by using the enforceClusterConstraints tag
with weblogic.Deployer.
Or select the Enable Cluster Constraints check box in the
console.
Do not change cluster membership while deploying
applications to the cluster.

All nodes in the cluster must be running before an application is deployed to the cluster. It is
possible that even though the application is running, it cannot be reached by the admin server;
this is called a partitioned server. If a server is unavailable when the application is deployed,
WebLogic switches to a relaxed deployment model. In this model, deployments continue to all
other nodes. Deployment completes on the partitioned server after it becomes reachable.
One potential problem with partial deployment is that during the synchronization period, while
other clustered Managed Servers reestablish communications with the previously partitioned
server instance, the user requests to the deployed applications and the attempts to create
secondary sessions on that server instance will fail possibly causing inconsistencies in cached
objects. To avoid this, you can instruct Oracle WebLogic Server never to allow relaxed or partial
deployments by using the enforceClusterConstraints tag with weblogic.Deployer.
Production Redeployment in a Cluster
When you use production redeployment of an application

in a cluster, each server instance in the cluster retires the
old version when the work is complete on that server.
Therefore, different servers may be running different
versions for a period of time.
Application (Version 1)
Deployed Server A
Application
(Version 2)
Server B
Cluster
Production Redeployment in a Cluster

Server A and Server B both initially run Version 1 of the application. When a second version of
the application is deployed to the cluster, it is deployed to both servers in the cluster.
However, because different clients are using the application on different servers, Version 1 may
be retired at different points. If the clients have completed using the application on Server A, any
new requests are to Version 2 of the application. On Server B, the client may still be interacting
with Version 1.
Targeting a cluster
instead of a single server

Regardless of the deployment tool that you use, when you initiate the deployment process, you
specify the components to be deployed and the targets to which they will be deployedyour
cluster or the individual server instances within the cluster or domain.
In Oracle WebLogic Server, applications are deployed in two phases. During the first phase of
deployment, application components are distributed to the target server instances, and the
planned deployment is validated to ensure that the application components are successfully
deployed. During this phase, user requests to the application being deployed are not allowed.
Failures encountered during the distribution and validation processes result in the deployment
being aborted on all server instances, including those on which the validation succeeded. Files
that have been staged are not removed; however, container-side changes performed during the
preparation are reverted.
After the application components are distributed to targets and validated, they are fully deployed
on the target server instances, and the deployed application is made available to clients. When a
failure is encountered during the second phase of deployment, the application that failed to
deploy is made unavailable.
Ideally, all Managed Servers in a cluster should be running and available during the deployment
process. Deploying applications when some members of the cluster are unavailable is not
recommended.
Deploying Applications to a Cluster (continued)

Applications and clusterable services can be targeted to a cluster, instead of individual servers.
Deploying Applications to a Cluster (continued)

Make sure that you opt to deploy to All servers in the cluster to benefit from clustering
support.
Road Map

Session Management
HTTP Session Failover
Replication Groups
In-Memory Replication
Persistent Replication
Replication Within a MAN or WAN
Web applications use HTTP sessions to track information

in server memory for each client.
By default, when a client fails over to another server in the
cluster, its session information is lost.
Oracle WebLogic Server supports several Session
Replication strategies to recover sessions from failed
servers:
In-memory replication
JDBC replication
File replication
Replication is configured for each Web application within
its weblogic.xml file.
Similar options are available for stateful EJB applications.

Web application components, such as servlets and JavaServer Pages (JSPs), maintain data on
behalf of clients using an HttpSession instance that is available on a per-client basis. To
provide high availability of Web applications, shared access to one HttpSession object must
be provided. HttpSession objects can be replicated within Oracle WebLogic Server by
storing their data using in-memory replication, file system persistence, or in a database.
For clusters that use a supported load-balancing hardware solution, the load-balancing hardware
redirects the client requests to any available server in the Oracle WebLogic Server cluster. The
cluster itself obtains a replica of the clients HTTP session state from a secondary server in the
cluster.
In clusters that use Web servers with WebLogic proxy plug-ins, the proxy plug-in handles the
failover transparently to the client. If a server fails, the plug-in locates the replicated HTTP
session state on a secondary server and accordingly redirects the clients request.
HTTP Session State Replication
Oracle WebLogic Server provides clustering support for

JSPs and servlets by replicating the HTTP session state.
To benefit from HTTP session state clustering, you must
ensure that the session state is persistent, by configuring:
In-memory replication
JDBC replication
File system replication
You must also access the cluster via a collection of Web
servers with identically configured proxy plug-ins or load-
balancing hardware.
Session persistence is configured using the <session-
descriptor> element in the weblogic.xml deployment
descriptor file.
Each persistence method has its own set of configurable
parameters.
HTTP Session State Replication

Load balancing for Servlet and JSP HTTP session states can be accomplished using separate
load-balancing hardware or by using the built-in load-balancing capabilities of a WebLogic
proxy plug-in; this also includes the use of HTTPClusterServlet.
For clusters that use a bank of Web servers and WebLogic proxy plug-ins, the proxy plug-ins
provide only a round-robin algorithm for distributing requests to the Servlets and JSPs in a
cluster.
Clusters that use a hardware load-balancing solution can use any load-balancing algorithm that
the hardware supports, including advanced load-based balancing strategies that monitor the
utilization of individual machines.
Note: This release of Oracle WebLogic Server provides Asynchronous HTTP Session
Replication (AsyncRep) to improve cluster performance.
AsyncRep gives you the option to choose asynchronous session replication to the secondary
server. It also provides the ability to throttle the maximum size of the queue that batches up
session objects before the batched replication takes place.
AsyncRep is used to specify the asynchronous replication of data between a primary server and a
secondary server. In addition, this option enables the asynchronous replication of data between a
primary server and a remote secondary server located in a different cluster according to the
THESE cluster topologyARE
eKIT MATERIALS of MAN.
FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
Machines
In Oracle WebLogic Server, machine names are used to

indicate that a Managed Server runs on a particular piece
of hardware.
Machine definition is one of the factors that WebLogic
takes into account when it chooses another server as its
backup for session information.
Replication Groups
A replication group is a logical grouping of related servers

in a cluster.
WLS enables you to determine where to put backup
objects using replication groups.
WLS attempts to:
Send backup objects to a preferred secondary replication
group, if it is configured
Send backup objects to a different machine
Avoid sending backup objects to servers in the same
replication group
Replication Groups
By default, Oracle WebLogic Server attempts to create replicas of certain services on a machine
other than the one that hosts the primary service.
Oracle WebLogic Server enables you to further control where the secondary states are placed by
using replication groups. A replication group is a preferred list of clustered instances to use for
storing session state replicas. When you configure a server instance that participates in a cluster,
you can assign the server instance membership in a replication group. You can also assign a
preferred secondary replication group to be considered for replicas of the primary HTTP session
states that reside on the server.
When a client attaches to a cluster and creates an instance of a service that is automatically
replicated in Oracle WebLogic Server (such as an HttpSession or a stateful session EJB),
the Oracle WebLogic Server instance that hosts the primary object ranks other servers in the
cluster to determine which server hosts the secondary. Server ranks are assigned using the
servers locality (whether it resides on the same machine as the primary) and participation in a
replication group.
An administrator can configure replication groups to operate such that secondary objects for
replicated services always reside on different hardware. In earlier versions of Oracle WebLogic
Server, the cluster would ensure that a replicated service exists on a different machine. However,
because one computer can host multiple IP addresses and thus multiple machines, a replicated
instance might not be protected from a general hardware failure. The creation of replication
THESE groups solves this
eKIT MATERIALS issue.
ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
Replication Groups
Replication groups:
Represent a subset of servers within a cluster
Help to determine the placement of secondary sessions
(avoid replicating within the same room, for example)
Are not explicitly defined in the console-like machines and
clusters
WLS attempts to:
Send secondary sessions to servers that are assigned to the
preferred secondary replication group of the primary server
Avoid sending secondary sessions to servers that are
assigned to the same replication group as the primary server
Replication Groups (continued)

By default, Oracle WebLogic Server attempts to create session state replicas on a machine other
than the one that hosts the primary session state. You can further control where secondary states
are placed using replication groups. A replication group is a preferred list of clustered servers to
be used for storing session state replicas.
Using the Oracle WebLogic Server Console, you can define unique names for machines that
host individual server instances. These machine names can be associated with the new Oracle
WebLogic Server instances to identify where the servers reside in your system.
Machine names are used to indicate servers that run on the same machine. For example, you
would assign the same machine name to all server instances that run on the same machine or the
same server hardware.
If you are not running multiple Oracle WebLogic Server instances on a single machine, you
need not specify the Oracle WebLogic Server machine names. Servers without a machine name
are treated as though they reside on separate machines.
When you configure a clustered server instance, you can assign the server to a replication group
and a preferred secondary replication group for hosting replicas of the primary HTTP session
states that are created on the server.
Configuring Replication Groups
Select each server in a cluster and assign each a pair of

replication groups.
Configuring Replication Groups

If a cluster hosts servlets or stateful session EJBs, you might want to create replication groups of
the Oracle WebLogic Server instances to host the session state replicas.
Replication Group: The name of the replication group to which the server belongs. It is
recommended that you group together all servers that have a relationship with one another
(for example, servers that run on the same machine). For greater flexibility, you can define
a different replication group for each server.
Preferred Secondary Group: The name of the replication group to use to host the
replicated HTTP session states for the server. You should select a secondary group in
which all servers run on a different machine than the replication groups servers. For
greater flexibility, you can select a secondary replication group that contains a single
server running on a different machine.
Secondary Ranking
The distribution of secondary sessions across cluster members

can be controlled by using:
Machine definitions
Replication group assignments
Does the server reside Is the server part of a Secondary

on a different machine? preferred secondary Server Rank
replication group?
Yes Yes 1
Yes No 2
No Yes 3
No No 4
Secondary Ranking
When a client attaches to a server in the cluster and creates a primary session state, the server
that hosts the primary state ranks other servers in the cluster to determine which server should
host the secondary. Server ranks are assigned using a combination of the servers location
(whether or not it resides on the same machine as the primary server) and its participation in the
primary servers preferred replication group. Using these rules, the primary Oracle WebLogic
Server ranks other members of the cluster and chooses the highest-ranked server to host the
secondary session state.
Each users session always exists on two servers:

Primary
Secondary
Every update to the primary session is automatically
replicated on the secondary server, either:
Synchronously (default)
Asynchronously (batch)
Cluster
Server Server Server
Primary Secondary
Using in-memory replication, Oracle WebLogic Server copies a session state from one server
instance to another. The primary server creates a primary session state on the server to which the
client first connects and a secondary replica on another Oracle WebLogic Server instance in the
cluster. The replica is kept up-to-date so that it can be used if the server that hosts the Web
application fails.
In-Memory Replication and Proxy Servers
Oracle WebLogic Server uses nonpersistent cookies to

track the primary and secondary servers for each client.
Subsequent requests from the same client must be
directed to the same primary server by the proxy.
WLS Web server plug-ins support both cookie values
There is one cookie with a value that contains the JVMID of
the primary and secondary servers
Network hardware that does not support the secondary
cookie still functions effectively:
The server that is being failed over to automatically assumes
the role of the primary server.
In-Memory Replication and Proxy Servers

To use in-memory replication for HTTP session states, you must access the Oracle WebLogic
Server cluster using either a collection of Web servers with identically configured WebLogic
proxy plug-ins or a load-balancing hardware.
The WebLogic proxy plug-in maintains a list of Oracle WebLogic Server instances that host a
clustered servlet or JSP, and forwards HTTP requests to these instances using a round-robin
strategy. The plug-in also provides the logic necessary to locate the replica of a clients HTTP
session state if an Oracle WebLogic Server instance fails.
In its default configuration, Oracle WebLogic Server uses client-side cookies to keep track of
the primary and secondary servers that host the clients servlet session state. If client browsers
have disabled the cookie usage, Oracle WebLogic Server can also keep track of the primary and
secondary servers using URL rewriting. With URL rewriting, both locations of the client session
state are embedded into the URLs that are passed between the client and the proxy server. To
support this feature, you must ensure that URL rewriting is enabled on the Oracle WebLogic
Server cluster.
To support direct client access via the load-balancing hardware, the Oracle WebLogic Server
replication system allows clients to use secondary session states regardless of the server to which
the client fails over. Oracle WebLogic Server uses client-side cookies or URL rewriting to
record the primary and secondary server locations. However, this information is used only as a
history of the servlet session state location. When accessing a cluster via the load-balancing
THESE hardware, clientsARE
eKIT MATERIALS do FOR
not use theUSE
YOUR cookie information
IN THIS to actively
CLASSROOM locate a server
ONLY. COPYING after a failure.
eKIT MATERIALS FROM THIS
In-Memory Replication: Example
Primary = A Primary = B
3 Secondary 4 Secondary = C
=B
Client Client
Proxy Proxy
1 3
ServerA ServerB ServerC ServerA ServerB ServerC
2 2
1
Primary Secondary Primary Secondary
In-Memory Replication: Example

The graphic in the slide depicts a client accessing a Web application that is hosted in a cluster.
All client requests are forwarded to the Oracle WebLogic Server cluster via a proxy, such as
HttpClusterServlet or a Web server plug-in.
To provide failover services for the Web application, the primary server replicates the clients
session state to a secondary Oracle WebLogic Server in the cluster. This ensures that a replica of
the session state exists even if the primary server fails (for example, due to a network failure). In
the example in the slide, Server B is selected as the secondary server.
If the primary server fails, the proxy uses the clients cookie information to determine the
location of the secondary Oracle WebLogic Server that hosts the replica of the session state. The
proxy automatically redirects the clients next HTTP request to the secondary server, and the
failover is transparent to the client.
After the failure, Oracle WebLogic Server B becomes the primary server that hosts the session
state, and a new secondary is created (Server C, in this example). In the HTTP response, the
proxy updates the clients cookie to reflect the new primary and secondary servers to account for
the possibility of subsequent failovers.
WLS can replicate: Server 1

HttpSession objects Primary
Stateful session EJBs
Session objects exist on only two
Server 2
servers.
Secondary
Secondary:
The server is determined by the
replication group and machine Primary
definition.
The object is created immediately Server 3
after the primary object is created.
Secondary
Primary failure makes the backup
object the primary object. Cluster
Web application components, such as servlets and JSPs, maintain data on behalf of clients using
an HttpSession instance that is available on a per-client basis.
To provide high availability of Web applications, shared access to one HttpSession object
must be provided. HttpSession objects can be replicated within Oracle WebLogic Server by
storing their data with in-memory replication, file system persistence, or in a database.
With in-memory replication, replicated objects are not accessible on all server instances in the
cluster. Rather, when an object is created, it is called the primary object. On another server
instance, a backup object is created. In the event of a failure of the primary object, the backup
object is promoted as the primary object. If a failover occurs, another backup object is created.
This is optimal because replication of object data must occur only between the primary and
backup objects (rather than the entire cluster).
Server 1 Server 1
Primary Primary
Server 2 Server 2
Secondary Primary
Server 3 Server 3
Secondary
Cluster Cluster
Before After
Failover with Load balancer
domain
machine 1
server A
servlet
primary
state
Load
Balancer
machine 2
server B server C
servlet servlet
client primary secondary
state state
Firewall
Cluster
Cookie
Primary: server A
Secondary: server B
Failover with Load balancer

When the client first makes a request, it is sent to server A. Because the application uses either
an HTTP session or a stateful session bean, the client becomes pinned to a server. A cookie is
written to the client machine stating that the primary state is stored on server A and the
secondary on server B. Where the secondary state is stored is chosen based on machines and
replication groups.
When server A fails, requests from the client go to the server that maintains the state. This server
then becomes the primary server and another server is chosen to maintain the backup of the
session state.
Requirements for In-Memory Replication
Subsequent requests from the same client must have

access to the same primary object.
To use in-memory replication for the HTTP session state,
clients must access the cluster using either:
The load-balancing hardware (WLS aware)
A collection of Web servers, or a single Web server, with
WebLogic proxy plug-ins (configured identically)
Oracle WebLogic Server configured with
HTTPClusterServlet
Requirements for In-Memory Replication

Proxy Requirements
The WebLogic proxy plug-ins maintain a list of Oracle WebLogic Server instances that host a
clustered servlet or JSP and forward HTTP requests to these instances by using a simple round-
robin strategy. The proxy also provides the logic that is required to locate the replica of a clients
HTTP session state if an Oracle WebLogic Server instance fails.
The supported Web server and proxy software includes:
Oracle WebLogic Server with the HttpClusterServlet
Netscape Enterprise Server with the Netscape (proxy) plug-in
Apache with the Apache Server (proxy) plug-in
Microsoft Internet Information Server with the Microsoft-IIS (proxy) plug-in
Load Balancer Requirements
If you choose to use load-balancing hardware instead of a proxy plug-in, you must use hardware
that supports secure sockets layer (SSL) persistence and passive cookie persistence. Passive
cookie persistence enables Oracle WebLogic Server to write cookies (containing information
about the location of the replicated HTTP session states) through the load balancer to the client.
The load balancer, in turn, interprets an identifier in the clients cookie to maintain the
relationship between the client and the primary Oracle WebLogic Server that hosts the HTTP
THESE session state. ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
eKIT MATERIALS
Configuring In-Memory Replication
1. Configure the proxy server (if applicable).

2. Optionally define replication groups and/or machines.
3. Specify the persistence type in the weblogic.xml
deployment descriptor; the options include:
replicated
replicated_if_clustered
async-replication-across-cluster
...
<session-descriptor>
<persistent-store-type>replicated</persistent-store-type>
</session-descriptor>
...
Configuring In-Memory Replication

Sets the persistent store method to one of the following options:
memory: Disables persistent session storage
replicated: Same as memory, but session data is replicated across the clustered servers
replicated_if_clustered: If the Web application is deployed on a clustered server, the in-
effect persistent-store-type is replicated. Otherwise, memory is the default.
async-replicated: Enables asynchronous session replication in an application or Web
application. See Configuring Session Persistence.
async-replicated-if-clustered: Enables asynchronous session replication in an application
or Web application when deployed to a cluster environment. If deployed to a single server
environment, the session persistence/replication defaults to in-memory. This allows testing
on a single server without deployment errors.
file: Uses file-based persistence. (See also persistent-store-dir.)
async-jdbc: Enables asynchronous JDBC persistence for HTTP sessions in an application
or Web application. See Configuring Session Persistence.
jdbc: Uses a database to store persistent sessions. (See also persistent-store-pool.)
Cookie: All session data is stored in a cookie in the users browser.
Configuring In-Memory Replication (continued)
Cookie-based session persistence provides a stateless solution for session persistence by storing
all session data in a cookie in the users browser. Cookie-based session persistence is most
useful when you do not need to store large amounts of data in the session. Cookie-based session
persistence can simplify management of your Oracle WebLogic Server installation because
clustering failover logic is not required. Because the session is stored in the browser, and not on
the server, you can start and stop Oracle WebLogic Servers without losing sessions.
Note that cookies can persist only string data and that there is no security on data because
cookies are passed to and from the browser in clear text.
In the <session-param> element of weblogic.xml, set the PersistentStoreType
attribute to cookie. Optionally, set a name for the cookie using the
PersistentStoreCookieName attribute. The default is WLCOOKIE.
JDBC Replication
HTTP sessions are persisted to a database using a

common JDBC data source.
The required data definition language (DDL) file is
available in the documentation.
All members of the cluster have access to any clients
session for failover purposes (no primary or secondary).
Cluster
Server
Database
Proxy Server
Server
JDBC Replication
With persistent Java Database Connectivity (JDBC) replication, a database is configured for
storing HttpSession objects. After the database is configured, each server instance in a
cluster uses an identical connection pool to share access to the database.
Whenever a Web application creates or uses a session object, the WebLogic Web container
stores the session data persistently in the database. When a subsequent client request enters the
cluster, any server in the cluster can handle the request. Each server in the cluster has identical
access to the persistent store where it can look up the information needed to satisfy the clients
request. This technique provides good failover capability because any server in the cluster can
resolve a clients request, but there is a significant performance reduction due to the many
database synchronizations required in a large Web-based system.
Persistent JDBC Replication
Cluster
All server instances Common access
obtained via
have access to all Server 1 identical
Servlet1
sessions. connection pools
Subsequent requests Servlet2
from the same client
can be handled by any Server 2
server. Servlet1
Great failover capability
Servlet2
Significant performance
reduction Database
Server 3
Changing session
Servlet1
objects causes (slow) HttpSession objects
database Servlet2 stored in database
synchronization.
Persistent JDBC Replication

Whenever a servlet creates or uses a session object, the servlet stores the session data
persistently in the database. When a subsequent client request enters the cluster, any server in
the cluster can handle the request. Each server in the cluster has identical access to the persistent
store where it can look up the information needed to satisfy the clients request. This technique
provides for good failover capability because any server in the cluster can resolve a clients
request, but there is a significant performance reduction due to the many database
synchronizations required in a large Web-based system.
Session persistence is not used for storing long-term data between sessions. That is, you should
not rely on a session still being active when a client returns to a site at some later date. Instead,
your application should record long-term or important information in a database.
You should not attempt to store long term or limited term client data in a session. Instead, your
application should create and set its own cookies on the browser. Examples of this include an
auto-login feature where the cookie lives for a long period or an auto-logout feature where the
cookie expires after a short period of time. Here, you should not attempt to use HTTP sessions;
instead you should write your own application-specific logic.
Note that even though it is legal (according to the HTTP Servlet specification) to place any Java
object in a session, only those objects that are serializable are stored persistently by Oracle
WebLogic Server.
Configuring JDBC Replication
1. Create the required table in the database.

2. Create a JDBC data source that has read/write privileges
for your database.
3. Configure JDBC session persistence in the
weblogic.xml deployment descriptor.
...
<persistent-store-type>jdbc</persistent-store-type>
<persistent-store-pool>MyDataSource</persistent-store-pool>
...
Configuring JDBC Replication

Set up a database table named wl_servlet_sessions for JDBC-based persistence. The
connection pool that connects to the database needs to have read/write access for this table.
Create indexes on wl_id and wl_context_path if the database does not create them
automatically. Some databases create indexes automatically for primary keys.
Set the persistent-store-type parameter in the session-descriptor element in
the weblogic.xml deployment descriptor file to jdbc.
Set a JDBC connection pool to be used for persistence storage with the persistent-
store-pool parameter in the session-descriptor element in the weblogic.xml
deployment descriptor file. Use the name of a connection pool that is defined in the Oracle
WebLogic Server Administration Console.
You can use the jdbc-connection-timeout-secs parameter to configure the maximum
duration that the JDBC session persistence should wait for a JDBC connection from the
connection pool, before failing to load the session data.
To prevent multiple database queries, Oracle WebLogic Server caches recently used sessions.
Recently used sessions are not refreshed from the database for every request. The number of
sessions in cache is governed by the cache-size parameter in the session-descriptor
element of the Oracle WebLogic Serverspecific deployment descriptor, weblogic.xml.
JDBC Persistent Table Configuration
A database table named WL_SERVLET_SESSIONS must exist

with read/write access:
Column Head Column Data Type
WL_ID char, 100 variable width char

Prim.
Key WL_CONTEXT_PATH
WL_CREATE_TIME numeric, 20 digits
WL_IS_VALID char, 1 character
WL_SESSION_VALUES BLOB, very large
WL_ACCESS_TIME numeric, 20 digits
WL_IS_NEW numeric, 20 digits
JDBC Persistent Table Configuration

In the database that is mapped to the session persistence connection pool, you must configure a
single table, WL_SERVLET_SESSIONS, which will hold the values of all active session
objects. The user specified with access to this table needs read/write/insert/delete access on the
table to effectively manage the objects. The table requires the following eight columns:
WL_ID: The session ID is used as database primary key along with WL_CONTEXT_PATH.
This is a variable-width alphanumeric data type of up to 100 characters.
WL_CONTEXT_PATH: This is the context. This column is used with WL_ID as the
primary key. This is a variable-width alphanumeric data type of up to 100 characters.
WL_IS_NEW: This value is true as long as the session is classified in the new state by
the Servlet engine. This is a single char column.
WL_CREATE_TIME: This is the time when the session was originally created. This is a
numeric column, 20 digits.
WL_IS_VALID: This parameter is true when the session is available to be accessed by a
servlet. It is used for concurrency purposes. This is a single char column.
WL_SESSION_VALUES: This is the actual session data. It is a BLOB column.
WL_ACCESS_TIME: This indicates the time when the session was last accessed. This is a
numeric column, 20 digits.
WL_MAX_INACTIVE_INTERVAL: This indicates the number of seconds between client
requests before the session is invalidated. A negative time value indicates that the session
should never
THESE eKIT MATERIALS AREtimeout. ThisUSE
FOR YOUR is an integer
IN THIS column. ONLY. COPYING eKIT MATERIALS FROM THIS
CLASSROOM
JDBC Persistent Table Configuration (continued)
The following is an example SQL statement to create this table, for Oracle Database:
create table wl_servlet_sessions ( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL, wl_is_new CHAR(1),
wl_create_time NUMBER(20), wl_is_valid CHAR(1), wl_session_values
LONG RAW, wl_access_time NUMBER(20), wl_max_inactive_interval
INTEGER, PRIMARY KEY (wl_id, wl_context_path) );
File Replication
File replication is similar to JDBC replication, but it persists

sessions to a highly available file system.
Cluster
Server
File System
Proxy Server
Server
File Persistence
Session state may also be stored in a file.

For file-based persistence:
You must create the directory in which to store the file
The file must have the appropriate access privileges
Configuring File Replication
1. Create a folder shared by all servers on the cluster on a

highly available file system.
2. Assign read/write privileges to the folder.
3. Configure file session persistence in the weblogic.xml
deployment descriptor.
...
<persistent-store-type>file</persistent-store-type>
<persistent-store-dir>/mnt/wls_share</persistent-store-dir>
...
Configuring File Replication

In the weblogic.xml deployment descriptor file, set the persistent-store-type
parameter in the session-descriptor element to file.
Set the directory where Oracle WebLogic Server stores the sessions using the persistent-
store-dir parameter. You must create this directory and make sure that appropriate access
privileges are assigned to the directory.
Ensure that you have enough disk space to store the number of valid sessions multiplied by the
size of each session. You can find the size of a session by looking at the files created in the
location indicated by the persistent-store-dir parameter. Note that the size of each
session can vary as the size of serialized session data changes.
Each server instance has a default persistent file store that requires no configuration. Therefore,
if no directory is specified, a default store is automatically created in the <server-
name>\data\store\default directory. However, the default store is not shareable
among clustered servers.
Other options for <persistent-store-type>:
memory: When you use memory-based storage, all session information is stored in memory and
is lost when you stop and restart Oracle WebLogic Server. To use memory-based, single-server,
nonreplicated persistent storage, set the PersistentStoreType attribute in the
THESE <session-param>
eKIT MATERIALS ARE FOR element of weblogic.xml
YOUR USE IN THIS CLASSROOM fileONLY.
to memory.
COPYING eKIT MATERIALS FROM THIS
Configuring File Replication (continued)
cookie: Cookie-based session persistence provides a stateless solution for session persistence
by storing all session data in a cookie in the users browser. Cookie-based session persistence is
most useful when you do not need to store large amounts of data in the session.
Cookie-based session persistence can simplify management of your Oracle WebLogic Server
installation because clustering failover logic is not required. Because the session is stored in the
browser, and not on the server, you can start and stop Oracle WebLogic Servers without losing
sessions. But remember that cookies can persist only string data and that there is no security on
the data as cookies are passed to and from the browser in clear text.
To set up cookie-based session persistence, perform the following:
In the <session-param> element of weblogic.xml, set the
PersistentStoreType attribute to cookie.
Optionally, set a name for the cookie using the PersistentStoreCookieName
attribute. The default is WLCOOKIE.
Cross-Cluster Replication
WebLogic provides the ability to replicate HTTP sessions

across two clusters in separate domains:
This is most applicable to clusters that are distributed
geographically.
Configure a global proxy to direct clients back to the same
cluster (cluster affinity).
Configure a specific network channel for cross-cluster
communication.
Local
ClusterA
Proxy
Global Replication
Client Channel
Proxy
Local
ClusterB
Proxy
Cross-Cluster Replication
In addition to providing HTTP session state replication across servers within a cluster, Oracle
WebLogic Server provides the ability to replicate HTTP session state across multiple clusters.
This improves high availability and fault tolerance by allowing clusters to be spread across
multiple geographic regions, power grids, and Internet service providers.
In a network configuration that supports cross-cluster replication, the global load balancer is
responsible for balancing HTTP requests across clusters. When a request comes in, the global
load balancer determines which cluster to send it to based on the current number of requests
being handled by each cluster. Then the request is passed to the local load balancer for the
chosen cluster. The local load balancer is responsible for balancing HTTP requests across
servers within the cluster.
When a server within a cluster fails, the local load balancer is responsible for transferring the
request to other servers within the cluster. When the entire cluster fails, the local load balancer
returns the HTTP requests to the global load balancer. The global load balancer then redirects
this request to the other local load balancer.
To replicate session data from one cluster to another, a replication channel must be configured to
communicate session state information from the primary to the secondary cluster. The specific
method used to replicate session information depends on the type of cross-cluster replication that
you have configured: MAN or WAN. You must ensure that the replication channel is created on
all cluster members and has the same name. The channel should be used only for replication.
THESE Other types of network
eKIT MATERIALS ARE FORtraffic
YOURshould
USE INbe directed
THIS to otherONLY.
CLASSROOM network channels.
COPYING eKIT MATERIALS FROM THIS
MAN and WAN Replication
Select from two cross-cluster replication strategies:

Metropolitan Area Network (MAN)
Low latency network
Synchronous in-memory replication to secondary server
within another cluster
Wide Area Network (WAN)
High latency network
Synchronous in-memory replication to secondary server
within the same cluster
Asynchronous JDBC replication for availability in remote
clusters
MAN and WAN Replication

Resources within a metropolitan area network (MAN) are often in physically separate locations,
but geographically close enough that network latency is not an issue. Network communication in
a MAN generally has low latency and fast interconnect. Clusters within a MAN can be installed
in physically separate locations, which improves availability. However, you should use this
method only if the network latency between the clusters is tolerable.
To provide failover within a MAN, Oracle WebLogic Server provides an in-memory mechanism
that works between two separate clusters. This allows session state to be replicated
synchronously from one cluster to another, provided that the network latency is a few
milliseconds. The advantage of using a synchronous method is that reliability of in-memory
replication is guaranteed.
Resources in a wide area network (WAN) are frequently spread across geographical regions. In
addition to requiring network traffic to cross long distances, these resources are often separated
by multiple routers and other network bottlenecks. Network communication in a WAN generally
has higher latency and slower interconnect.
Slower network performance within a WAN makes it difficult to use a synchronous replication
mechanism like the one used within a MAN. Oracle WebLogic Server provides failover across
clusters in a WAN by using an asynchronous data replication scheme. To enable cross-cluster
replication within a WAN environment, you must create a JDBC data source that points to the
THESE database where the
eKIT MATERIALS AREsession stateUSE
FOR YOUR information is stored. ONLY. COPYING eKIT MATERIALS FROM THIS
IN THIS CLASSROOM
Configuring Cross-Cluster Replication
1
Location of servers
in remote cluster
Required only for WAN
Configuring Cross-Cluster Replication

Before configuring cross-cluster replication using the Administration Console, you must set up
your network environment, including the hardware load balancers, Oracle WebLogic Server
instances, and clusters. If you use cross-cluster replication within a WAN environment, you
must also create and configure a data source.
1. In the Administration Console, expand Environment and select Clusters. Click the name of
the cluster for which you want to configure the cross-cluster replication.
2. Click the Replication tab.
3. Select the type of cross-cluster replication that you want to implement: MAN or WAN.
4. Enter values for the following:
- Remote Cluster Address: Addresses used to communicate with the secondary
cluster. For multiple addresses, use a comma as the delimiter.
- Replication Channel: The name of the existing network channel used to
communicate with the secondary cluster. This network channel should be targeted to
the entire cluster.
Both these settings should be configured so that communication between the primary
and secondary cluster is not routed through the hardware load balancers.
5. If you configure cross-cluster replication in a WAN environment, select Data Source for
Session Persistence.
State Management Best Practices
Create WLS machines if you are replicating the state

across servers on different physical machines.
Use Replication Groups to define failover strategy.
Choose the most appropriate replication strategy
depending on the application needs and architecture.
Use the ServerDebugConfig MBean to track session
replication problems.
Ensure that objects placed in replicated sessions are
serializable.
Road Map

Session Management
Server Version
Multicast
CLASSPATH
Thread Count
Garbage Collection
Server Version
All servers in a cluster must have the same major version

number.
Servers can have different minor version numbers and
service packs.
The Administration Server should also have the same
major version number.
Multicast
If there is an IP multicast problem, WLS starts but does not

join a cluster.
To verify that multicast is working, run the
utils.MulticastTest utility.
Valid IP Multicast Addresses:

224.0.0.0 to 239.255.255.255
IP Multicast Test Utility:
java utils.MulticastTest -N <name> -A <multicastAddress>
Multicast
Several problems can occur with IP multicast: Oracle WebLogic Server might be unable to
create a socket, read from a socket, or send to a socket. These communication errors are
typically caused by an incorrect or bad multicast address.
Serialization errors can also indicate an incorrectly configured multicast. Each operating system
has specific configuration requirements for configuring multicast; to correct these problems,
check your operating system documentation.
The MulticastTest helps you to debug multicast problems when configuring an Oracle
WebLogic Server cluster. The utility sends out multicast packets and returns information about
how the multicast is working on your network.
Test Multicast: Example
Test Multicast: Example

You can verify that multicast is working by running utils.MulticastTest from one of
the Managed Servers.
The MulticastTest utility helps you to debug multicast problems when configuring an
Oracle WebLogic Server cluster. The utility sends out multicast packets and returns information
about how effectively the multicast is working on your network. Specifically,
MulticastTest displays the following types of information via standard output:
1. A confirmation and sequence ID for each message sent out by the current server
2. The sequence and sender ID of each message received from any clustered server, including
the current server
3. A missed-sequenced warning when a message is received out of sequence
4. A missed-message warning when an expected message is not received
To use MulticastTest, start one copy of the utility on each node on which you want to test
the multicast traffic.
Warning: Do not run the MulticastTest utility by specifying the same multicast address
(the -a parameter) as that of a currently running Oracle WebLogic Server cluster. The utility is
intended to verify that the multicast is functioning properly before your clustered Oracle
WebLogic Servers are started.
Test Multicast: Example (continued)
Syntax
$ java utils.MulticastTest -n name -a address [-p portnumber]
[-t timeout] [-s send]
-n name (required): A name that identifies the sender of the sequenced messages. Use a
different name for each test process that you start.
-a address: The multicast address on which: (a) the sequenced messages should be
broadcast; and (b) the servers in the clusters are communicating with each other. (The
default is 237.0.0.1.)
-p portnumber (optional): The multicast port on which all the servers in the cluster are
communicating. (The multicast port is the same as the listen port that is set for Oracle
WebLogic Server, which defaults to 7001 if unset.)
-t timeout (optional): Idle timeout, in seconds, if no multicast messages are received.
If unset, the default is 600 seconds (10 minutes). If a timeout is exceeded, a positive
confirmation of the timeout is sent to stdout.
-s send (optional): Interval, in seconds, between sends. If unset, the default is 2
seconds. A positive confirmation of each message that is sent out is sent to stdout.
CLASSPATH
The CLASSPATH value must be the same on all Managed

Servers in the cluster.
CLASSPATH is set by the setDomainEnv, setWLSEnv,
and commEnv scripts when the
startManagedWebLogic file is run.
CLASSPATH
Make sure that the value of CLASSPATH is the same on all Managed Servers in the cluster.
CLASSPATH is set by the setDomainEnv, setWLSEnv, and commEnv scripts, which run
when you run startManagedWebLogic to start the Managed Servers.
By default, the value for CLASSPATH (as represented on Windows systems) is set as shown
below:
set WL_HOME=C:\oracle\wlserver_10.3
set JAVA_HOME=C:\oracle\jdk160
.
.
set CLASSPATH=%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;
%WL_HOME%\server\lib\weblogic.jar;
%CLASSPATH%
If you change the value of CLASSPATH on one Managed Server, or change how the three
scripts sets the CLASSPATH, you must change it on all Managed Servers in the cluster.
Garbage Collection
The frequency and length of the garbage collection can

affect a cluster.
If garbage collection takes too long, the servers will not be
able to make the heartbeat signals.
Heap allocation can be tuned to adjust the length of the
garbage collection.
This can be changed using the Xms and Xmx parameters
in the server startup script.
Garbage Collection
If you experience problems in the cluster, you should also check the garbage collection on the
Managed Servers. If garbage collection takes too long, the servers will not be able to make the
frequent heartbeat signals that tell other cluster members that they are running and available.
If garbage collection (either first or second generation) takes 10 or more seconds, you need to
tune heap allocation (the msmx parameter) on your system.
Quiz
Select all valid values for the persistent store type element in
weblogic.xml?
1. file
2. replicated
3. unicast
4. async-replication-across-cluster
5. jdbc
6. async-wan
Answer: 1, 2, 4, 5
Quiz
Which two Oracle WebLogic Server features can be used to

control the destination servers that are used for in-memory
replication?
1. Web Service
2. Replication Group
3. Data Source
4. Node Manager
5. Machine
Answer: 2, 5
Remember that clustered servers use machine and replication group boundaries to select
destinations for replicated sessions.
Quiz
Which of the following terms is NOT associated with in-memory

replication?
1. Cookie
2. Secondary
3. Session
4. Schema
5. Primary
6. Synchronous
Answer: 4
By default, in-memory replication involves both the synchronous creation of secondary copies of
primary sessions, and the tracking of these primary and secondary copies with cookies.
Summary
In this lesson, you should have learned how to:

Deploy applications to a cluster
Manage and configure session state in a cluster
Troubleshoot common issues in a cluster
Clustering EJB Objects
Objectives

following:
Describe the clustering capabilities of EJBs
Configure clusterable EJBs
Describe EJB clustering best practices
Road Map
EJB Clustering Capabilities

Levels of Clustering
Load Balancing Algorithms
Clustering Session EJBs
Clustering Entity EJBs
Oracle WebLogic Server EJB
Clustering Capabilities
Oracle WebLogic Server allows load balancing and failover
of EJBs.
EJB clustering is transparent to:
The Bean developer
The client application developer
WLS EJBs can be clustered by configuring them in the
weblogic-ejb-jar.xml file.
High Availability for EJBs
WebLogic provides the EJB client applications with

cluster-aware stubs that transparently perform load
balancing and failover.
You can enable and configure clustering for each EJB
using the application deployment descriptor weblogic-
ejb-jar.xml. Cluster
Server
EJB
Client Server
Stub EJB
Server
EJB
High Availability for EJBs

For clustered EJBs, failover is accomplished using the objects replica-aware stub. When a client
makes a call through a replica-aware stub to a service that fails, the stub detects the failure and
retries the call on another replica.
With clustered objects, automatic failover generally occurs only in cases where the object is
idempotent. An object is idempotent if any method can be called multiple times with no
different effect than calling the method once. This is always true for methods that have no
permanent side effects. However, methods that have side effects have to be written with
idempotence in mind.
Method-level failover for a stateful service requires state replication. Oracle WebLogic Server
satisfies this requirement by replicating the state of the primary bean instance to a secondary
server instance, using a replication scheme similar to that used for HTTP session state.
Oracle WebLogic Server uses the round-robin algorithm as the default load-balancing strategy
for clustered object stubs when no algorithm is specified. Weight-based load balancing improves
on the round-robin algorithm by taking into account a pre-assigned weight for each server. You
can use the Server > Configuration > Cluster tab in the Administration Console to assign each
server in the cluster a numerical weight between 1 and 100, in the Cluster Weight field. This
value determines what proportion of the load the server will bear relative to other servers.
High Availability for EJBs (continued)
Oracle WebLogic Server provides three load-balancing algorithms for EJBs that provide server
affinity. Server affinity turns off load balancing for external client connections. Instead, the
client considers its existing connections to the Oracle WebLogic Server instances when choosing
the server instance on which to access an object. If an object is configured for server affinity, the
client-side stub attempts to choose a server instance to which it is already connected, and
continues to use the same server instance for method calls.
Levels of Clustering for EJB
Load balancing determines which server:

Processes the initial lookup
Is used to create or locate an EJB
Is used for calling the business methods
Failover:
For a home skeleton, it determines how method calls are
routed in a cluster.
For a remote skeleton, it determines whether to re-execute a
business operation on a different server.
Load-Balancing Clustered EJB Objects
Oracle WebLogic Server clusters support several

algorithms for load-balancing clustered EJB objects:
Round-robin
Weight-based
Random
Parameter-based routing (programmatic)
Server affinity minimizes the number of IP sockets that are
opened between the clients and servers in a cluster.
Load Balancing Clustered EJB Objects

The load-balancing algorithm for an object is maintained in the replica-aware stub that is
obtained for a clustered object.
By default, an Oracle WebLogic Server cluster uses round-robin load balancing. You can
configure a different default load balancing method for the cluster by using the Administration
Console to set weblogic.cluster.defaultLoadAlgorithm. A load-balancing algorithm that you
configure for an object overrides the default load-balancing algorithm for the cluster. In addition
to the standard load-balancing algorithms, Oracle WebLogic Server supports custom parameter-
based routing.
Round-Robin (default): The round-robin algorithm is the default load-balancing strategy
for clustered object stubs, when no algorithm is specified.
Weight-Based: The weight-based algorithm takes into account a preassigned weight for
each server. Each server in the cluster is assigned a weight in the range 1100. This is a
declaration of what proportion of the load this server will bear relative to the other servers.
Suppose that A is 4, B is 2, and C is 1; the usage is ABCABAA.
Load Balancing Clustered EJB Objects (continued)
Random: This algorithm chooses the next replica at random. This tends to distribute calls
evenly among the replicas. It is recommended only in a cluster in which each server has
the same power and hosts the same services. The advantages are that it is simple and
relatively cheap. The primary disadvantage is that there is a small cost to generating a
random number on every request, and there is a probability that the load will not be evenly
balanced over a small number of runs.
Parameter-Based Routing: It is also possible to have a finer grain of control over load
balancing. Any clustered object can be assigned a CallRouter. This is a class that is called
before each invocation with the parameters of the call. The CallRouter is free to examine
the parameters and return the name of the server to which the call should be routed. This is
usually handled by the developer, so we will not cover it here.
Server affinity minimizes the number of IP sockets opened between the external Java clients and
the server instances in a cluster. This is accomplished by causing method calls on objects to
stick to an existing connection, instead of being load balanced among the available server
instances. With server affinity algorithms, the less costly server-to-server connections are still
load balanced according to the configured load balancing algorithm; load balancing is disabled
only for external client connections.
Road Map

Stateless Session EJBs
Stateful Session EJBs
Stateless Session Bean: Load
Balancing and Failover
Stateless session beans of the same type are identical and
they hold no state:
Beans in different servers are still the same.
Separate method invocations can be sent to different
servers.
This does not apply to the stateless session bean methods
that fail during execution.
Stateless Session Bean: Load Balancing and Failover

The main point in this slide is the difference between load balancing and failover. Load
balancing can occur between method invocations. This means that a client calls a method, that
method is sent to a server, that method fully completes, and then the client invokes a second
method after the first is completed. Load balancing can occur on the second method with the
home stub or the remote stub sending the second method invocation to another server, if
appropriate.
Imagine a method that if called fails halfway through its execution. Now, the server and the
stubs have to deal with a failure situation. After all, if the method failed on one server, it may
fail on another server.
Configuring EJB Clustering
2
1
Default for all EJBs, if
not overridden
Optionally override the

default server addresses
and ports used by stubs
Required only if Address

is a single DNS name

To configure the default EJB cluster settings for your domain, perform the following:
1. Select Environment > Clusters within the Domain Structure panel of the console. Then
select a specific cluster.
2. On the General tab, update any of the fields described as follows.
Default Load Algorithm: The algorithm used for load balancing between replicated
services, such as EJBs, if none is specified for a particular service. The round-robin
algorithm cycles through a list of Oracle WebLogic Server instances in order.
Weight-based load balancing improves on the round-robin algorithm by taking into
account a pre-assigned weight for each server. In random load balancing, requests are
routed to servers at random.
Cluster Address: The address used by EJB clients to connect to this cluster. This
address may be either a DNS host name that maps to multiple IP addresses or a
comma-separated list of single address host names or IP addresses.
Number Of Servers In Cluster Address: The number of servers listed from this
cluster when generating a cluster address automatically
weblogic-ejb-jar.xml:
...
<stateless-clustering>
<stateless-bean-is-clusterable>True
</stateless-bean-is-clusterable>
<stateless-bean-load-algorithm>random
</stateless-bean-load-algorithm>
...
</stateless-clustering>
...
Configuring EJB Clustering (continued)

WebLogic administrators should always discuss with their EJB development team the impact of
the clustering features before modifying the EJB deployment descriptors. Some clustering
parameters can affect application design and/or implementation.
EJBs that are based on the 3.0 specification also support all 2.x WebLogicspecific EJB
features. However, the features that are configured in the weblogic-ejb-jar.xml or
weblogic-cmp-rdbms-jar.xml deployment descriptor files must continue to be
configured as per the 2.x WebLogicspecific EJB features because currently they do not have
any annotation equivalent.
You can define stateless-bean-load-algorithm as one of the following values:
round-robin, random, weight-based, round-robin-affinity, weight-based-affinity, and random-
affinity.
Optionally, when home-is-clusterable is True, the EJB can be deployed from multiple
Oracle WebLogic Servers in a cluster. Calls to the home stub are load-balanced between the
servers on which this bean is deployed, and if a server that hosts the bean is unreachable, the call
automatically fails over to another server that hosts the bean.
Configuring Clusterable Stateless Session EJBs
The WLS-specific deployment descriptor has a tag for

configuring stateless session EJB clustering parameters.
Snippet from META-INF\weblogic-ejb-jar.xml:
<!- Other Tags As Appropriate Here -->
<stateless-session-descriptor>
<stateless-clustering>
<stateless-bean-is-clusterable>True</stateless-bean-is-
clusterable>
<stateless-bean-load-algorithm>random</stateless-bean-load-
algorithm>
<stateless-bean-call-router-class-
name>beanRouter</stateless-bean-call-router-class-name>
<stateless-bean-methods-are-idempotent>True</stateless-
bean-methods-are-idempotent>
</stateless-clustering>
Configuring Clusterable Stateless Session EJBs

The <stateless-clustering> tag specifies options that determine how Oracle WebLogic
Server replicates the stateless session EJB instances in a cluster.
When <stateless-bean-is-clusterable> is True, the EJB can be deployed from
multiple Oracle WebLogic Servers in a cluster. Calls to the home stub are load-balanced
between the servers on which this bean is deployed, and if a server that hosts the bean is
unreachable, the call fails over to another server that hosts the bean.
The <stateless-bean-call-router-class-name> tag specifies the name of a
custom class to use for routing bean method calls. This class must implement
weblogic.rmi.cluster.CallRouter(). If specified, an instance of this class is called
before each method call. The router class has the opportunity to choose a server to route to based
on the method parameters. The class returns either a server name or null, which indicates that the
current load algorithm should select the server.
Set <stateless-bean-methods-are-idempotent> to True only if the bean is
written such that repeated calls to the same method with the same arguments have exactly the
same effect as a single call. This allows the failover handler to retry a failed call without
knowing whether the call actually completed on the failed server. Setting this property to True
makes it possible for the bean stub to recover from any failure as long as another server that
hosts the bean can be reached.
Configuring Stateless Session Clusterable EJBs
Example of a clustered stateless session EJB:
<!- LAST TAG inside <weblogic-ejb-jar> -->
<idempotent-methods>
<method> <!- can be repeated -->
<ejb-name>exampleSession</ejb-name>
<method-intf>Remote</method-intf>
<method-name>processUser</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
</idempotent-methods>
</weblogic-ejb-jar>
Configuring Stateless Session Clusterable EJBs

Note the usage of the <method> tag. A quick review of the <method> tag syntax is as
follows:
<ejb-name> specifies the name of the EJB that hosts the methods.
<method-intf> is optional. It specifies the single interface where the methods are
located. The value could be either Home, Remote, Local, or LocalHome. If it is skipped,
the methods of all interfaces are specified.
<method-name> is either a single method name or a * (all methods).
<method-params> is optional and contains a list of <method-param> tags. If
multiple methods have the same name with different parameters, you can specify the
method signature. This cannot be used with the *.
Stateful Session Beans
Each stateful session EJB is unique.

All calls on a remote stub must be directed to the server
that contains the EJB.
A stateful session EJB is pinned to
the server that it is created on. Its
remote stub must also be pinned to the
same server.
Configuring Clusterable Stateful Session EJBs
The WLS-specific deployment descriptor has a tag for

configuring the stateful session EJB clustering parameters.
A snippet from META-INF\weblogic-ejb-jar.xml:
<stateful-session-descriptor>
<stateful-session-clustering>
<home-is-clusterable> true
</home-is-clusterable>
<home-load-algorithm> random
</home-load-algorithm>
<home-call-router-class-name> common.QARouter
</home-call-router-class-name>
<replication-type> InMemory
</replication-type>
</stateful-session-clustering>
Configuring Clusterable Stateful Session EJBs

All the tags in <stateful-session-clustering> are optional.
Because an instance of a stateful session EJB is connected to a single client, invocations can be
sent only to a single server, not a cluster. But the home stub invocations are stateless and thus,
can be clustered.
<home-is-clusterable> indicates whether the home stub is clustered.
<home-load-algorithm> declares which load-balancing algorithm to use.
The tag <home-call-router-class-name> here is similar to the tag
<stateless-bean-call-router-class-name> shown on page 14, except that
the router class acts only on the home stub.
The <replication-type> tag is used to indicate whether or not your stateful session
EJB is replicated to a secondary server in the cluster. The value of the <replication-
type> tag can be InMemory or None.
Road Map

Cluster Aware Home Stubs
Load Balancing
Best Practices
Read-Write Versus Read-Only
There are two types of entity beans to consider:

Read-write
Read-only
For read-write entity beans, load balancing and failover
occur only at the home level.
For read-only entity beans, the replica-aware stub:
Load balances on every call
Does not automatically fail over in the event of a recoverable
call failure
Read-Write Versus Read-Only

There are two types of entity beans to consider: read-write entities and read-only entities.
Read-Write Entities: When a home finds or creates a read-write entity bean, it obtains an
instance on the local server and returns a stub pinned to that server. Load balancing and
failover occur only at the home level. Because it is possible for multiple instances of the
entity bean to exist in the cluster, each instance must read from the database before each
transaction and write on each commit.
Read-Only Entities: When a home finds or creates a read-only entity bean, it returns a
replica-aware stub. This stub load-balances on every call but does not automatically fail
over in the event of a recoverable call failure. Read-only beans are also cached on every
server to avoid database reads.
Entity Bean Cluster-Aware Home Stubs
Entity beans can have cluster-aware home stubs that have

knowledge of the EJB Home objects on all WLS instances
in the cluster.
The home-is-clusterable deployment element in the
weblogic-ejb-jar.xml file determines whether a
home stub is cluster-aware.
An example of setting an entity EJB home stub as cluster-
aware:
<entity-clustering>
<home-is-clusterable>True</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
<home-call-router-class-name>beanRouter
</home-call-router-class-name>
</entity-clustering>
Entity Bean Cluster-Aware Home Stubs

In an Oracle WebLogic Server cluster, the server-side representation of the Home object can be
replaced by a cluster-aware stub. The cluster-aware home stub has knowledge of the EJB
Home objects on all the Oracle WebLogic Servers in the cluster. The clustered home stub
provides load balancing by distributing EJB lookup requests to available servers. It can also
provide failover support for lookup requests, because it routes those requests to available servers
when other servers have failed.
All EJB typesstateless session, stateful session, and entity EJBscan have cluster-aware
home stubs. Whether or not a cluster-aware home stub is created is determined by the home-
is-clusterable deployment element in weblogic-ejb-jar.xml.
When home-is-clusterable is true, the EJB can be deployed from multiple Oracle
WebLogic Servers in a cluster. Calls to the home stub are load-balanced between the servers on
which this bean is deployed. If a server that hosts the bean is unreachable, the call automatically
fails over to another server that hosts the bean.
EJB Best Practices
Set pool and cache sizes in accordance with anticipated

load and execute threads per server.
Understand that cache sizes equally affect all nodes in the
cluster.
Mark bean methods that can be called multiple times with
impunity, as idempotent in their deployment descriptors.
EJB Best Practices

Design Idempotent Methods: It is not always possible to determine when a server instance
failed with respect to the work it was doing at the time of failure. For instance, if a server
instance fails after handling a client request but before returning the response, there is no way to
tell that the request was handled. A user that does not get a response retries, resulting in an
additional request.
Failover for Remote Method Invocation (RMI) objects requires that methods be idempotent. An
idempotent method is one that can be repeated with no negative side-effects.
To configure idempotence, at bean level, set stateless-bean-methods-are-
idempotent in weblogic-ejb-jar.xml to true. At method level, set idempotent-
methods in weblogic-ejb-jar.xml.
Summary
In this lesson, you should have learned to:

Describe how EJBs interact with clusters
Configure clusterable session EJBs
Configure clusterable entity EJBs
Describe EJB clustering best practices
Clustering Services
Objectives

following:
Set up whole server migration
Describe JNDI clustering
Describe JDBC clustering
Migrate a JMS server
Migrate transactions
Road Map
Clustering Services
Clusterable Services
Service Level Migration
Server Level Migration
JNDI
JDBC
Transactions
JMS
Services That Can Be Clustered
A clustered service is an API or interface that is available

on multiple servers in a cluster.
Oracle WebLogic Server provides clustering services for:
Web applications
EJB and RMI objects
JNDI tree
Oracle WebLogic Server provides limited clustering
services for:
JDBC connections
JMS destinations
Services That Can Be Clustered

Oracle WebLogic Server provides clustering support for servlets and JavaServer Pages (JSPs) by
replicating the HTTP session state of clients that access the clustered servlets of JSPs. To benefit
from HTTP session state clustering, you must ensure that the session state is persistent. You can
configure persistence by configuring in-memory replication, file system persistence, or JDBC
persistence.
Load balancing and failover for EJBs and Remote Method Invocation (RMI) objects are handled
by using special, replica-aware stubs, which can locate instances of the object throughout the
cluster. You create replica-aware stubs for EJBs and RMI objects by specifying the appropriate
deployment descriptors, or by providing command-line options to rmic. When you deploy a
clustered object, you deploy it to all the server instances in the cluster (this is known as
homogeneous deployment).
Oracle WebLogic Server provides limited load-balancing support for managing JDBC
connections in a cluster. If you create an identical JDBC DataSource in each server instance
and configure the DataSources to use different connection pools, the cluster can support load
balancing for JDBC connections.
Oracle WebLogic Server does not provide special load-balancing policies for accessing
connection pools. If one connection pool runs out of JDBC connections, the load-balancing
algorithm can direct connection requests to an empty JDBC connection pool.
Services That Can Be Clustered (continued)
The WebLogic JMS architecture implements clustering of JMS servers by supporting cluster-
wide, transparent access to destinations from any server in the cluster. Although Oracle
WebLogic Server supports distributing JMS destinations and connection factories throughout a
cluster, JMS queues and topics are managed by individual Oracle WebLogic Server instances in
the cluster. Each of these topics is discussed in detail in this lesson.
Service Failover
The services that are deployed to all the servers in a

cluster automatically have transparent failover.
JMS and JTA cannot be deployed to all the servers in a
cluster.
They are pinned services.
There are two ways to handle JMS and JTA failover:
Service-level migration
Server-level migration
Service Failover
In an Oracle WebLogic Server cluster, most services are deployed homogeneously on all the
server instances in the cluster, thus enabling transparent failover from one server to another. In
contrast, pinned services such as Java Message Service (JMS) and the Java Transaction API
(JTA) transaction recovery system are targeted at individual server instances within a cluster
for these services, Oracle WebLogic Server supports failure recovery through migration, as
opposed to failover.
Migration in Oracle WebLogic Server is the process of moving a clustered Oracle WebLogic
Server instance or a component, which is running on a clustered instance, elsewhere in the event
of failure. In the case of whole server migration, the server instance is migrated to a different
physical machine upon failure. In the case of service-level migration, the services are moved to a
different server instance within the cluster.
Oracle WebLogic Server provides a feature for making JMS and the JTA transaction system
highly available: migratable servers. Migratable servers provide for both automatic and manual
migration at the server level, rather than at the service level.
When a migratable server becomes unavailable for any reasonfor example, if it hangs, loses
network connectivity, or its host machine failsmigration 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
THESE addition, an administrator
eKIT MATERIALS can manually
ARE FOR YOUR initiate
USE IN THIS the migration
CLASSROOM ONLY. of a servereKIT
COPYING instance.
MATERIALS FROM THIS
Service-Level Migration
Service-level migration is performed manually.

Pinned services are moved from the failed server to a new
server.
The new server takes over and processes any data that is
left over when the server failed, and then takes over any
future processing.
A migratable service is accessed by clients by using a
migration-aware RMI stub.
Oracle WebLogic Server supports the automatic migration
of user-defined singleton services.
Service-Level Migration
The RMI stub keeps track of which server currently hosts the pinned service and it accordingly
directs the client requests.
In an Oracle WebLogic Server cluster, most subsystem services are hosted homogeneously on
all the server instances in the cluster, thus enabling transparent failover from one server to
another. In contrast, pinned services such as JMS-related services, the JTA Transaction
Recovery Service, and user-defined singleton services are hosted on individual server instances
within a clusterfor these services, the Oracle WebLogic Server migration framework supports
failure recovery with service migration as opposed to failover.
Service-level migration in Oracle WebLogic Server is the process of moving the pinned services
from one server instance to a different available server instance within the cluster. Service
migration is controlled by a logical migratable target, which serves as a grouping of services
that is hosted only on one physical server in a cluster. You can select a migratable target in place
of a server or cluster when targeting certain pinned services. 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.
Service-Level Migration (continued)
The migration framework provides tools and infrastructure for configuring and migrating
targets, and in the case of automatic service migration, it leverages the Oracle WebLogic
Servers health monitoring subsystem to monitor the health of the services that are hosted by a
migratable target.
Migratable Services
Oracle WebLogic Server supports service-level migration for JMS-related services, the JTA
Transaction Recovery Service, and user-defined singleton services. These are referred to as
migratable services, because you can move them from one server to another within a cluster.
The following migratable services can be configured for automatic or manual migration: JMS-
related Services, JTA Transaction Recovery Service, user-defined singleton services.
Server-Level Migration
Server-level migration moves the whole clustered server

instance in its entirety.
It is an alternative to service-level migration.
Service-level migration and server-level migration should not
be used together.
Server-level migration is:
Supported using the Java-based Node Manager. This is
supported from 9.2 MP2 and 10.x.
Supported on Windows (with the wlsifconfig.cmd script)
You can perform server-level migration both manually and
automatically.
When a migratable server fails:
The server is restarted on the same machine
If it cannot be started on the same machine, it moves to
another machine
Server-Level Migration
For UNIX and Linux systems, Oracle WebLogic Server provides a script-based version of Node
Manager. This script is based on UNIX shell scripts, but uses Secure Shell (SSH) for increased
security. SSH uses user IDbased security.
Road Map
Clustering Services
JNDI
Clusterwide JNDI Server
JNDI Naming Conflicts
JDBC
Transactions
JMS
JNDI Clustering Support
The JNDI tree contains factory objects for accessing the

following items:
JDBC DataSources
EJBs, RMI objects
JMS connection factories
Oracle WebLogic Server replicates clusterable objects to
all the servers on a cluster, transparently.
JNDI Clustering Support

If a clusterable object is bound to the JNDI tree, WLS automatically replicates the object to each
server in the cluster. This way, JNDI access is always fast. Typical clusterable objects include
Java Database Connectivity (JDBC) connection pools and DataSources, EJB and RMI objects,
and JMS connection factories.
The server instances in a cluster use a cluster-wide JNDI tree, which is similar to one server
instance JNDI tree, in that the tree contains a list of available services. In addition, a cluster-
wide JNDI tree stores the services offered by clustered objects (EJBs and RMI classes) from
other server instances in the cluster.
Clients of a nonclustered Oracle WebLogic Server server instance access objects and services by
using a JNDI-compliant naming service. The JNDI naming service contains a list of public
services that the server instance offers, organized in a tree structure. An Oracle WebLogic
Server instance offers a new service by binding into the JNDI tree a name that represents the
service. Clients obtain the service by connecting to the server instance and looking up the bound
name of the service.
JNDI Clustering Support (continued)
Server instances in a cluster use a cluster-wide JNDI tree. A cluster-wide JNDI tree is similar to
a single server instance JNDI tree, insofar as the tree contains a list of available services. In
addition to storing the names of local services, however, the cluster-wide JNDI tree stores the
services offered by clustered objects (EJBs and RMI classes) from other server instances in the
cluster. Each Oracle WebLogic Server instance in a cluster creates and maintains a local copy of
the logical cluster-wide JNDI tree. The following sections describe how the cluster-wide JNDI
tree is maintained and how to avoid naming conflicts that can occur in a clustered environment.
Clusterwide JNDI Service
Each WLS server issues messages

that announce the following events:
A new object bound into the
naming tree JNDI
An object removed from the server A

naming tree
An object rebound (updated) into
the naming tree
JNDI
server B
Cluster
Clusterwide JNDI Service

Every Oracle WebLogic Server server that participates in a cluster issues messages that are sent
out over the IP multicast channel. The content of the message is a whats new list of changes
in the naming service of the server.
Any new, deleted, or modified objects are broadcast across the servers in the cluster. Because
each server has a local JNDI tree, receiving a notification of what is modified is enough
information for it to keep synchronized. Because most primary programmatic objects are
accessed through the naming service, most application clients are guaranteed a simple interface
across all the servers in the cluster. Application clients do not necessarily have to be concerned
about which server they connect to because all local JNDI trees will host a complete list of
objects. This allows load balancing and other directory technologies to apply balancing, load,
and other business rules for routing; this allows for a more robust scenario.
A naming conflict generally occurs when a server instance

attempts to bind a service to the JNDI when that name
already exists.
The services are nonclustered.
In a cluster, a naming conflict can occur when the server
tries to bind a clustered object with the same name as a
nonclustered object.
The object will be bound to the JNDI locally.
Other servers will not bind the replica-aware stub.
To avoid naming conflicts:
Deploy all clusterable objects to all the servers in the cluster.
Deploy to the cluster itself, not the individual servers.

Simple JNDI naming conflicts occur when a server instance attempts to bind a nonclustered
service that uses the same name as a nonclustered service that is already bound in the JNDI tree.
Cluster-level JNDI conflicts occur when a server instance attempts to bind a clustered object that
uses the name of a nonclustered object that is already bound in the JNDI tree.
Oracle WebLogic Server detects simple naming conflicts (of nonclustered services) when those
services are bound to the local JNDI tree. Cluster-level JNDI conflicts may occur when new
services are advertised over multicast or unicast. For example, if you deploy a pinned RMI
object on one server instance in the cluster, you cannot deploy a replica-aware version of the
same object on another server instance.
If two server instances in a cluster attempt to bind different clustered objects using the same
name, both will succeed in binding the object locally. However, each server instance will refuse
to bind the other server instances replica-aware stub onto the JNDI tree, due to the JNDI
naming conflict. A conflict of this type remains until one of the two server instances is shut
down, or until one of the server instances undeploys the clustered object. This conflict can also
occur if both server instances attempt to deploy a pinned object with the same name.
Road Map
Clustering Services
JNDI
JDBC
JDBC Clustering
Clustering Versus Multi Data Sources
Targeting a Data Source to a Cluster
Transactions
JMS
JDBC Clustering
The following JDBC objects are clusterable:

Data sources
Multi data sources
When you target a JDBC data source, a new instance of
the data source is created on the target.
Single server target A data source instance is created on
the server.
Cluster target A data source instance is created on all
member servers in the cluster.
Clustering your JDBC objects does not enable failover of
connections but it can ease the process of reconnection
when a connection fails.
JDBC Clustering
Multi data sources provide failover and load balancing for connection requests between two or
more data sources. Before you create a multi data source, you should create the data sources that
the multi data source will manage, and deploy them to the same targets that you want to deploy
the multi data source to. Note that the underlying databases must have some kind of data
synchronization or replication. Oracle WebLogic Server does not handle that replication.
Feature Cluster Multi Data Source
Failover None On the same server (High-
Availability Algorithm only)
Load Balance None On the same server (Load-

Balance Algorithm only)

Clustering a JDBC data source allows a client to reconnect to the database via a secondary
server when the primary server it was connected to fails. Though clustering provides load
balancing for the initial request from the client, it does not provide load balancing for the actual
JDBC connections. A multi data source allows for failover and load balancing between different
nodes in a highly available database system.
Targeting a DataSource to a Cluster
2

Locate and select your data source.
Targeting a DataSource to a Cluster (continued)

Click the Targets tab to target to the cluster.
Road Map
Clustering Services
JNDI
JDBC
Transactions
Transaction Recovery Service
Migrating JTA
JMS
Transaction Recovery After Failure
Transaction Manager (TM) makes every effort to resolve

prepared transactions even after multiple crashes.
TM uses the Transaction Recovery Service (TRS) which:
Automatically attempts to recover transactions on system
startup
Owns the transaction log for a server
Parses all log files on startup for incomplete transactions and
completes them
Transaction Recovery After Failure

The Oracle WebLogic Server Transaction Manager is designed to recover from system crashes
with minimal user intervention. Transaction Manager makes every effort to resolve the
transaction branches that are prepared by resource managers with a commit or roll back, even
after multiple crashes.
To facilitate recovery after a crash, Oracle WebLogic Server provides the Transaction Recovery
Service, which automatically attempts to recover transactions on system startup. The
Transaction Recovery Service owns the transaction log for a server. On startup, the Transaction
Recovery Service parses all log files for incomplete transactions and completes them as
described in the following slides.
Because the Transaction Recovery Service is designed to gracefully handle transaction recovery
after a crash, you should attempt to restart a crashed server and allow the Transaction Recovery
Service to handle incomplete transactions.
If a server crashes and you do not expect to be able to restart it within a reasonable period of
time, you may need to take action. Procedures for recovering transactions after a server failure
differ based on your Oracle WebLogic Server environment. For a nonclustered server, you can
manually move the server (with transaction log files) to another system (machine) to recover the
transactions. For a server in a cluster, you can manually migrate the Transaction Recovery
Service to another server in the same cluster.
When a server restarts after a crash or if the JTA is migrated,

the TRS attempts to:
Resolve prepared transactions in T-Logs
Maintain consistency across resources
Persist in achieving transaction resolution
Report heuristic completions
Domain
Server A App Shared Disk
TRSa TMa
Admin
Server TRS
App Persistent
Store
TRSa TMa
Server B TMb

When you restart a server after a crash or when you migrate the Transaction Recovery Service to
a backup server, the Transaction Recovery Service attempts to do the following:
Resolve prepared transactions: After Transaction Manager prepares a transaction with a
Resource Manager, the TRS must call XAResource.recover() during crash recovery
for that Resource Manager and eventually resolve (by calling the commit(), rollback(),
or forget() methods) all the transaction IDs that are returned by recover().
Maintain consistency across resources: The Transaction Recovery Service handles
transaction recovery in a consistent, predictable manner: For a transaction that is
committed before a crash, and XAResource.recover() returns the transaction ID, the
Transaction Recovery Service consistently calls XAResource.commit(); for a
transaction that is not committed before a crash, and XAResource.recover() returns its
transaction ID, the Transaction Recovery Service consistently calls
XAResource.rollback(). With consistent, predictable transaction recovery, a
Transaction Manager crash by itself cannot cause a mixed heuristic completion where
some branches are committed and some are rolled back.
Transaction Recovery Service (continued)
Persist in achieving transaction resolution: If a Resource Manager crashes, the
Transaction Recovery Service must eventually call commit() or rollback() for each
prepared transaction until it gets a successful return from commit() or rollback(). The
attempts to resolve a transaction can be limited by setting the AbandonTimeoutSeconds
configuration attribute.
Report heuristic completions: If a Resource Manager reports a heuristic commit or
heuristic rollback, the Transaction Recovery Service records the heuristic commit or
rollback in the server log and calls forget() if the Forget Heuristics configuration
attribute is enabled. If the Forget Heuristics configuration attribute is not enabled, refer to
your database vendors documentation for information about resolving heuristic
completions.
Recovering JTA Without a Cluster
To recover transactions from a nonclustered server,

perform the following:
Make the persistent store for the failed server available to the
new server.
Set the path for the default persistent store to the path to the
data file.
Start the new server.
The TRS searches all transaction log files for incomplete
transactions.
Recovering JTA Without a Cluster

When you move transaction log records after a server failure, make all the transaction log
records available on the new machine before you start the server there. Otherwise, transactions
in the process of being committed at the time of a crash might not be resolved correctly,
resulting in application data inconsistencies. You can accomplish this by storing the persistent
store data files on a dual-ported disk that is available to both machines. As in the case of a
planned migration, update the default file store directory attribute with the new path before
starting the server if the path name is different on the new machine.
Note: The Transaction Recovery Service is designed to gracefully handle transaction recovery
after a crash. You should attempt to restart a crashed server and allow the Transaction Recovery
Service to handle incomplete transactions, rather than move the server to a new machine.
Recovering Transactions in a Cluster
When you recover transactions in a clustered server, you have

two options:
Transaction Recovery Service migration
The TRS on the backup server takes ownership of the
transaction log from the crashed server.
The TRS searches all the transaction log files from the failed
server and attempts to complete in-flight transactions.
If the TRS on the backup server successfully completes all
the incomplete transactions, the server releases ownership
of the TRS.
Whole Server migration
The server is migrated in its entirety, along with the services
that it hosts.
Recovering Transactions in a Cluster

Server Migration
For clustered servers, WebLogic Server enables you to migrate a failing server to a new
machine, including the Transaction Recovery Service. When the server migrates to another
machine, it must be able to locate the transaction log records to complete or recover transactions.
Transaction log records are stored in the default persistent store for the server. If you plan to
migrate clustered servers in the event of a failure, you must set up the default persistent store so
that it stores records in a shared storage system that is accessible to any potential machine to
which a failed migratable server might be migrated. For highest reliability, use a shared storage
solution that is itself highly availablefor example, a storage area network (SAN). For
information about Whole Server migration, visit
http://e-docs.bea.com/wls/docs103/cluster/migration.html.
Manual Transaction Recovery Service Migration
When a clustered server crashes, you can manually migrate the Transaction Recovery Service
from the crashed server to another server in the same cluster using the Administration Console
or the command-line interface.
Recovering Transactions for a Failed Clustered
Server (Manually)
Manually migrate the TRS from the crashed server to another
server in the cluster by using the Administration Console or the
command-line interface:
The TRS on the backup server takes ownership of the
transaction log from the failed server.
The TRS searches the transaction log files from the failed
server for incomplete transactions and completes them.
If the TRS on the backup server successfully completes all
the incomplete transactions from the failed server, it
releases ownership of the TRS (including the transaction
log files) for the failed server, so that the failed server can
reclaim it upon restart.
Recovering Transactions for a Failed Clustered Server (Manually)

When manual service migration takes place, the following events occur:
1. The Transaction Recovery Service on the backup server takes ownership of the transaction
log from the crashed server.
2. The Transaction Recovery Service searches all transaction log records from the failed
server for incomplete transactions and completes them.
3. If the Transaction Recovery Service on the backup server successfully completes all the
incomplete transactions from the failed server, the server releases ownership of the TRS
for the failed server, so that the failed server can reclaim it upon restart.
A server can perform transaction recovery for multiple failed servers. While recovering
transactions for other servers, the backup server continues to process and recover its own
transactions. If the backup server fails during recovery, you can migrate the Transaction
Recovery Service to yet another server, which continues the transaction recovery. You can also
manually migrate the Transaction Recovery Service back to the original failed server using the
Administration Console or the command-line interface.
Recovering Transactions for a Failed Clustered Server (Manually) (continued)
When a backup server completes transaction recovery for a server, it releases ownership of the
Transaction Recovery Service for the failed server. When you restart a failed server, it attempts
to reclaim ownership of its Transaction Recovery Service. If a backup server is in the process of
recovering transactions when you restart the failed server, the backup server stops recovering
transactions, performs some internal cleanup, and releases ownership of the Transaction
Recovery service so that the failed server can reclaim it and start properly. The failed server then
completes its own transaction recovery.
If a backup server still owns the Transaction Recovery Service for a failed server and the backup
server is inactive when you attempt to restart the failed server, the failed server will not start
because the backup server cannot release ownership of the Transaction Recovery Service. This
is also true if the failback mechanism fails or if the backup server cannot communicate with the
Administration Server. You can manually migrate the Transaction Recovery by using the
Administration Console or the command-line interface.
Migrating JTA
Migrating JTA can be done in two ways:

Manual
Automatic
Configuring JTA Service Migration
Before you manually migrate JTA, you define which

servers are available for migration.
To set up the candidate servers, use:
Environment > Servers > Configuration > Migration
Configuring JTA Service Migration

To migrate the Transaction Recovery Service from a failed server in a cluster, make sure that the
failed server is not running.
Note: The Transaction Recovery Service is designed to gracefully handle transaction recovery
after a crash. It is recommended that you attempt to restart a crashed server and allow the
Transaction Recovery Service to handle incomplete transactions, rather than migrating the
Transaction Recovery Service to another server.
Manually Migrating the JTA to Another
Server in a Cluster
When you need to migrate transactions from a failed server to a
working server, use:
Environment > Servers > Control > Migration
Manually Migrating the JTA to Another Server in a Cluster

After you save and activate your changes, the new server will have access to the transaction
persistent store from the failed server.
Configuring Automatic Migration of
the JTA Transaction
To configure automatic migration of the Transaction Recovery
Service for a migratable target within a cluster:
Configure the Managed Servers and Node Manager:
Create the Managed Servers.
Create and configure the machines.
Configure Node Manager.
Configure the Migration Basis.
On the Cluster > Configuration > Migration page, configure
the clusters Migration Basis" according to your data
persistence environment configuration (use either Database
leasing or Consensus leasing).
Enable Automatic JTA Migration.
Configuring Automatic Migration of the JTA Transaction

The JTA Transaction Recovery Service is designed to gracefully handle transaction recovery
after a crash. You can specify to have the Transaction Recovery Service automatically migrated
from an unhealthy server instance to a healthy server instance with the help of the server health
monitoring services. This way, the backup server can complete the transaction work for the
failed server.
Configure the Managed Servers and Node Manager: Configure the Managed Servers in the
cluster for migration, including assigning Managed Servers to a machine. Node Manager must
also be running and configured to allow automatic server migration. Node Manager is required
to get liveliness information about the servers involved.
Configure the Migration Basis: On the Cluster > Configuration > Migration page, configure
the clusters Migration Basis according to how your data persistence environment is
configured, using either Database leasing or Consensus leasing.
Enable Automatic JTA Migration: In the JTA Migration Configuration section on the
Server > Configuration > Migration page, do the following:
Select the Automatic JTA Migration check box.
Use the JTA Candidate Servers box to select the servers that you want to use as the JTA TRS
server backup and move them to the Chosen list.
Configuring Automatic Migration of the JTA Transaction (continued)
Note: You should select candidate servers that have access to the current servers transaction log
files (stored in the default WebLogic file store). If no candidate servers are chosen, any server
within the cluster can be chosen as a candidate server.
Optionally, specify whether you are providing pre-migration and post-migration scripts to
perform any dismounting and mounting of the shared storage, as needed:
Pre-Migration Script Path: The path to the pre-migration script to run before a
migratable target is actually activated
Post-Migration Script Path: The path to the post-migration script to run after a
migratable target is fully deactivated
Post-Migration Script Failure Cancels Automatic Migration: Specifies whether or not
a failure during execution of the post-deactivation script is fatal to the migration
Allow Post-Migration Script To Run On a Different Machine: Specifies whether or not
the post-deactivation script is allowed to run on a different machine
The pre- or post-migration scripts must be located in the
BEA_HOME/user_projects/domains/mydomain/bin/service_migration
directory, where mydomain is a domain-specific directory with the same name as the domain.
For your convenience, sample pre-migration and post-migrations scripts are provided in this
directory.
Configuring Automatic Migration
of the JTA Transaction
Configure the default persistent store for the migration of
the Transaction Recovery Service.
Restart the Administration Server and Managed Servers
with modified migration policies.
Configuring Automatic Migration of the JTA Transaction (continued)

Configure the default persistent store for the migration of the Transaction Recovery Service:
Transaction Manager uses the default persistent store-to-store transaction log files. To enable
migration of the Transaction Recovery Service, you must configure the default persistent store
so that it stores its data files on a persistent storage solution that is available to other servers in
the cluster if the original server fails.
Restart the Administration Server and Managed Servers with modified migration policies:
You must restart the Administration Server after configuring the JTA Transaction Recovery
Service for automatic service migration.
You must also restart any Managed Servers whose migration policies were modified.
Automatic Failback of the Transaction Recovery
Service Back to the Original Server
There are two scenarios for automatic failback of the
Transaction Recovery Service to the primary server:
Automatic failback after recovery is complete:
If the backup server finishes recovering the TLOG
transactions before the primary server is restarted, it initiates
an implicit migration of the Transaction Recovery Service
back to the primary server.
For both manual and automatic migration, the post-
deactivation script would be executed automatically.
Automatic failback before recovery is complete:
If the backup server is still recovering the TLOG transactions
when the primary server is started, during the Transaction
Recovery Service initialization of the primary server startup,
it initiates an implicit migration of the Transaction Recovery
Service from the backup server.
Automatic Failback of the Transaction Recovery Service Back to the Original

Server
After completing transaction recovery for a failed server, a backup server releases ownership of
the Transaction Recovery Service so that the original server can reclaim it when the server is
restarted. If the backup server stops (crashes) for any reason before it completes transaction
recovery, its lease expires. This way, when the primary server starts up, it can reclaim ownership
successfully.
JTA Migration Limitations
Migrating the JTA has the following limitations:

The JTA cannot be migrated to a backup server from a
running server.
The server must be stopped before migrating the JTA.
The backup server processes only incomplete
transactions.
The backup server does not accept new transaction work for
the failed server.
The backup server does not process heuristic log files.
JTA Migration Limitations

When migrating the Transaction Recovery Service, the following limitations apply:
You cannot migrate the Transaction Recovery Service to a backup server from a server
that is running. You must stop the server before migrating the Transactions Recovery
Service.
The backup server does not accept new transaction work for the failed server. It processes
only incomplete transactions.
The backup server does not process heuristic log files.
The backup server processes only the log records written by Oracle WebLogic Server. It
does not process the log records written by gateway implementations, including Oracle
WebLogic Tuxedo Connector.
To migrate the Transaction Recovery Service from a failed server in a cluster to another server
(backup server) in the same cluster, the backup server must have access to the transaction log
files from the failed server. Therefore, you must store the transaction log files on persistent
storage that is available to both (or more) servers. You should store transaction log files on a
Storage Area Network (SAN) device or a dual-ported disk; do not use an NFS file system to
store transaction log files. Because of the caching scheme in NFS, the transaction log files may
not always be current. Using the transaction log files that are stored on an NFS device for
recovery may cause data errors.
JTA Migration Limitations (continued)
When migrating the Transaction Recovery Service from a server, you must stop the failing or
the failed server before actually migrating the Transaction Recovery Service. If the original
server is still running, you cannot migrate the Transaction Recovery Service from it.
Road Map
Clustering Services
JNDI
JDBC
Transactions
JMS
Clustering JMS
Distributed Destinations
JMS Failover
JMS Clustering Support
Oracle WebLogic Server supports targeting JMS

connection factories to a cluster.
Oracle WebLogic Server supports the distribution of JMS
destinations throughout a cluster (distributed destinations).
JMS queues and topics are still managed by a single server
instance in the cluster.
Oracle WebLogic Server provides failover for JMS
messages through:
Distributed destinations
Server-level automatic migration
JMS Clustering Support

The WebLogic JMS architecture implements clustering of multiple JMS servers by supporting
cluster-wide, transparent access to destinations from any server in the cluster. Oracle WebLogic
Server supports the distribution of JMS destinations and connection factories throughout a
cluster. JMS topics and queues are managed by individual Oracle WebLogic Server instances in
the cluster.
Load balancing is supported for JMS. To enable load balancing, you must specify targets for the
JMS servers during cluster configuration.
JMS Connection Factory Clustering

Locate and click connection factory.
JMS Connection Factory Clustering (continued)

Click the Targets tab to target the connection factory to the cluster.
Distributed Destination
A distributed destination has the following properties:

It defines multiple destinations as part of one distributed
destination.
It is looked up as a regular destination via JNDI.
Its member availability is dynamically updated.
Producers and consumers can send and receive
messages through a distributed destination.
WebLogic JMS distributes the load across the available
physical destinations within the distributed destination.
Distributed Destination
WebLogic JMS offers a level of redundancy, and therefore service continuity, in the event of the
failure of one Oracle WebLogic Server by enabling you to configure multiple physical
destinations (queues and topics) as part of one distributed destination set. Producers and
consumers can send messages to and receive messages from the distributed destination.
WebLogic JMS distributes the load across all available physical destinations within the
distributed destination.
The Load Balancing Enabled attribute on JMS Connection Factory defines whether the
nonanonymous producers created through a connection factory are load-balanced on a per-call
basis.
For applications that use distributed destinations to distribute or balance their producers and
consumers across multiple physical destinations, but do not make a load-balancing decision each
time a message is produced, turn off the Load Balancing Enabled attribute.
The Server Affinity Enabled attribute on JMS Connection Factory defines whether an Oracle
WebLogic Server that load balances consumers or producers across multiple physical
destinations in a distributed destination set will first attempt to load balance across any other
physical destinations that are also running on the same Oracle WebLogic Server.
For more information, see Configuring Distributed Destinations at
THESE http://e-docs.bea.com/wls/docs103/jms_admin/advance_config.html#wp1079177.
eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
Distributed Queues
Oracle WebLogic Server 1
Senders
JMS ServerA
s1 s3
...
m9 m8 m3 queue
Q
s2 Receivers
JMS ServerB r1
Dest3 ... r2
m7 m5 m4 queue
Q
r3
JNDI Tree r4
Dest1 JMS ServerC
Dest2
Dest3 ...
Dest4 m6 m2 m1 queue
Q
Distributed Queues
A distributed destination is a set of physical destinations, queues, or topics that are called under
one JNDI name so that they appear to be one logical destination to a client. The members of the
set are actually distributed across multiple servers within a cluster. Each destination member
belongs to a separate JMS server.
By enabling you to configure multiple physical queues and topics as members of a distributed
destination, WebLogic JMS supports high availability and load balancing of the physical
destinations within a cluster.
After it is configured, producers and consumers can send and receive messages through the
distributed destination. WebLogic JMS balances the messaging load across all available
members of the distributed destination. If one member becomes unavailable due a server failure,
traffic is redirected toward other available destination members in the set.
Distributed Topics
Publishers Persistent
JMS ServerA Storage
p1 p3
...
m3 m2 m1 topicT
p2 Subscribers
JMS ServerB s1
Dest3 ... s2
m3 m2 m1 topicT
s3
JNDI Tree s4
Dest1 JMS ServerC
Dest2
Dest3 ...
Dest4 m32 m2 m1 topicT
Creating a Distributed Topic

To create a distributed topic, perform the following:
1. In the Administration Console, expand Services > Messaging and select JMS Modules.
2. In the JMS Modules table, click the name of the JMS module in which to configure the
topic resource.
3. On the modules Settings page, click New in the Summary of Resources table.
4. On the Create a New JMS System Module Resource page, select the Distributed Topic
option from the options that are available.
5. Click Next.
Creating a Distributed Topic (continued)

In Oracle WebLogic Server 10.3, you can create a uniform distributed destination that
automatically creates uniformly configured destination members on selected JMS servers or on
all JMS servers on a target server or cluster.
Distributed Destination Threshold and Quota
Server Affinity
WebLogic tries to establish new connections to the same

servers as existing connections.
Server Affinity applies only to distributed destinations.
For a new JMS connection, a distributed destination:
Attempts to create a connection on the same server as the
JNDI initial context, which is the original client connection
server instance
Attempts to create a connection to a server with which the
client already has a connection, JMS or non-JMS. This may
be dependent on the JTA or JMS transaction.
Creates the connection on any server
Server Affinity
Scenario 1 happens if there is a member of this distributed JMS destination on the same server
where the client is using a JNDI connection to discover the distributed destination.
When the client already interacts with Transaction Manager on one of the servers for JTA or
other JMS purposes and tries to connect to the distributed destination, the client connection
would be created on the same server instance where other transaction work is being managed.
This is done to simplify transaction coordination by Transaction Manager.
Scenario 3 takes place when the client cannot access a member of the distributed destination on
the current server because it is not available on this particular server and the client has not yet
done any work with the other servers that host members of the desired distributed destination.
Queue senders are preferably routed to the member destinations with the existing queue
receivers.
Topic Publishers will have their messages fan out to all active member Topics whether the
member Topic has any Subscriber connected or not.
Zero Consumers
Server affinity favors members on the same server as the

client.
Transaction affinity favors members that are already
involved in a transaction.
A zero consumer is a member that has no consumers; it is
used as follows:
A producer avoids a zero consumer.
A consumer searches for a zero consumer.
Persistent messages are put in a backing store.
Zero Consumers
Server Affinity
When the Server Affinity option is enabled for distributed destinations before an Oracle
WebLogic Server instance attempts to load balance consumers or producers across all the
members of a distributed destination in a domain, it attempts to load balance across the local
members that are running on the same Oracle WebLogic Server instance.
Transaction Affinity
When producing multiple messages within a transacted session, the system attempts to send all
the messages that are produced to the same Oracle WebLogic Server. If a session sends multiple
messages to one distributed destination, all the messages are routed to the same physical
destination. If a session sends multiple messages to multiple distributed destinations, the system
attempts to select a set of physical destinations that are served by the same Oracle WebLogic
Server.
Queues with Zero Consumers
When you are load-balancing consumers across multiple remote physical queues, if one or more
queues have zero consumers, those queues alone are considered for balancing the load. When all
the physical queues in the set have at least one consumer, the standard algorithms apply. When
producers send messages, queues with zero consumers are not considered for message
production, unless all the instances of the queue have zero consumers.
Zero Consumers
JMS ServerA
...
s1 s3
m6 m3 m2 queue
Q
s2
JMS ServerB
r1
Dest3
queueQ
r3
JNDI Tree
Dest1 JMS ServerC r4
Dest2
Dest3 ...
Dest4 m5 m4 m1 queue
Q
Load Balancing
If the destination is not distributed:

All production is directed at one destination
The consumer uses that destination
Load balancing does not occur
If the destination is distributed:
Production is replicated across member topics and queues
Load balancing is either round-robin or random
The consumer is pinned to one member destination, which is
selected at creation time
Location Transparency
Standard destinations can be replicated in the clusterwide

JNDI service.
Select the Replicate JNDI Name in Cluster field in the
Administration Console.
Use the isJNDINameReplicated() method in
JMSQueueMBean or JMSTopicMBean.
Clients look up a destination on any server and receive a
connection on the actual server.
Location Transparency
The isJNDINameReplicated() method is inherited from the JMSDestinationMBean
interface that both JMSQueueMBean and JMSTopicMBean extend.
The distributed JMS destination tries to minimize inter-server communications and uses server
affinity (discussed later) if it is allowed.
Server affinity is enabled by appropriately selecting the respective check box on the JMS
connection factory level.
Failover
Failover is both automatic and manual.

A manual failover includes migrating these elements:
An entire JMS server
A persistent store
A transaction log
WLS provides a migratable JMS service that attempts to
deliver outstanding JMS messages.
Failover
JMS offers level service continuity in the event of the failure of one Oracle WebLogic Server by
enabling you to configure multiple physical destinations (queues and topics) in one distributed
destination set. Implementing the Migratable Service feature ensures that pinned exactly-once
services, such as JMS, do not introduce one point of failure for dependent applications in the
cluster.
If a failure occurs, you can invoke the migration process manually. You must migrate a JDBC
store or file store only if it physically exists on the failed server.
Any transaction logs must also be available to the new server.
JMS Server Migration
JMS is an exactly-once service; each JMS server exists

on exactly one Oracle WebLogic Server.
When an Oracle WebLogic Server fails, its JMS servers
can be migrated. However, migration must be configured
ahead of time.
For persistent messaging, migratable targets must have
access to the same JMS store as the original server.
A JMS server can migrate to an Oracle WebLogic Server
that already hosts distributed destination members.
Migration may be a part of scheduled maintenance.
Performing Migration
Services that are migrated to a nonrunning server are

started when the server starts.
Migration can be manually or automatically initiated.
Automatic migration happens only through whole server
migration.
It is possible to use third-party products to perform
migration:
JMX
Veritas HA
JMS Migratable Targets
The JMS server can be a target to a different independent

Oracle WebLogic Server instance or to a migratable target
in a WebLogic cluster.
A migratable target is a special target that can migrate
from one server in a cluster to another.
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.
JMS Migratable Targets

You can configure JMS and JTA services for high availability by using migratable targets. As an
exactly-once service, WebLogic JMS is not active on all Oracle WebLogic Server instances in
a cluster. It is instead pinned to one server in the cluster to preserve data consistency. To
ensure that pinned services do not introduce one point of failure for dependent applications in
the cluster, Oracle WebLogic Server can be configured to migrate exactly-once services to
any server in the clusters migratable target list.
WebLogic JMS takes advantage of the migration framework by allowing administrators to
specify a migratable target for a JMS server through the Administration Console. When
configured, a JMS server and all of its destinations can migrate to another Oracle WebLogic
Server within a cluster.
This allows WebLogic JMS to properly respond to migration requests, and bring a JMS server
online and offline in an orderly fashion. This includes scheduled migrations and migrations in
response to an Oracle WebLogic Server failure. Migration framework feature improves the
availability of these services because they can be restarted quickly if the original host server
fails.
JMS Migratable Targets (continued)
In order to configure a migratable 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, and can
optionally specify a user-preferred host 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 independent of when a specific
server member is available. In other words, the queue is always available when the migratable
target is hosted by any server in the cluster.
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. If you do not configure a migratable target in the cluster, migratable services can
be migrated to any WebLogic Server instance in the cluster.
Migrating JMS Data
For the JDBC store:

If the database is on the failed server, migrate the database
to the new server and change the JDBC URL for the JDBC
stores DataSource.
If the database is not on the failed server, no changes are
required.
For the file store:
Migrate to a new server.
Ensure that the path name is the same on the new server as
the original one.
For transactions, also migrate the transaction logs.
Migrating JMS Data

WebLogic JMS uses the migration framework that is implemented in the Oracle WebLogic
Server core, which allows WebLogic JMS to properly respond to migration requests and bring a
WebLogic JMS server online and offline in an orderly way. This includes both scheduled
migrations and migrations in response to an Oracle WebLogic Server failure.
When properly configured, a JMS server and all of its destination members can migrate to
another Oracle WebLogic Server within a cluster.
Migration Configuration
To configure a JMS migration, perform the following:

Define migratable target servers in the cluster.
Create JMS servers and assign to the migratable targets.
Create physical member destinations (use the autodeploy
option for distributed destinations).
Configuring a Migratable Target
Configuring a Migratable Target

For each Oracle WebLogic Server in a domain, specify the JMS migration target.
Targeting JMS Server to a Migratable Target
Migrating Services
Summary

Migrate a whole server
Cluster JNDI objects
Cluster JDBC data sources
Cluster transactions
Cluster JMS connection factories
Appendix A
Practices and Solutions
Table of Contents
Practices for Lesson 1 ......................................................................................................... 4
Installing the Oracle WebLogic Server Software ............................................................... 4
Practice 1-1: Installing Oracle WebLogic Server 10.3 ................................................... 6
Practices for Lesson 2 ......................................................................................................... 7
Configuring a Domain Template ........................................................................................ 7
Using the Administration Console.................................................................................... 10
Using the Command Lines ............................................................................................... 11
Practice 2-1: Configuring a Domain Template............................................................. 12
Practice 2-2: Using the Administration Console .......................................................... 15
Practice 2-3: Using the Command Line........................................................................ 17
Practices for Lesson 3 ....................................................................................................... 19
Configuring Servers and Machines................................................................................... 19
Starting the Servers Using Node Manager........................................................................ 21
Configuring Network Channels and Network Access Points (Optional) ......................... 24
Practice 3-1: Configuring Servers and Machines ......................................................... 27
Practice 3-2: Starting Servers Using Node Manager .................................................... 30
Practice 3-3: Configuring Network Channels and Network Access Points (Optional) 33
Deploying and Undeploying Web Applications ............................................................... 35
Practice 4-1: Deploying/Undeploying Web Applications ............................................ 37
Configuring Data Sources................................................................................................. 41
Practice 6-1: Configuring Data Sources ....................................................................... 44
Configuring the JMS Servers and Destinations ................................................................ 47
Practice 7-1: Configuring the JMS Servers and Destinations....................................... 50
Data Sources and Transactions ......................................................................................... 53
Practice 8-1: Data Sources and Transactions................................................................ 56
Managing Users and Groups............................................................................................. 58
Securing Web Applications .............................................................................................. 61
Configuring Additional Conditions .................................................................................. 63
Configuring SSL ............................................................................................................... 65
Protecting Against Attacks ............................................................................................... 69
Practice 9-1: Managing Users and Groups ................................................................... 70
Practice 9-2: Securing Web Applications ..................................................................... 71
Practice 9-3: Configuring Additional Conditions ......................................................... 73
Practice 9-4: Configuring SSL...................................................................................... 75
Practice 9-5: Protecting Against Attacks ...................................................................... 78
Practices for Lesson 10 ..................................................................................................... 80
Using a Deployment Plan ................................................................................................. 80
Production Redeployment................................................................................................. 82
Oracle WebLogic Server 10g R3: System Administration A - 2

Practice 10-1: Using a Deployment Plan ...................................................................... 84
Practice 10-2: Production Redeployment ..................................................................... 87
Creating a Basic Cluster.................................................................................................... 91
Configuring Proxy Servers ............................................................................................... 93
Practice 12-1: Creating a Basic Cluster ........................................................................ 98
Practice 12-2: Configuring Proxy Servers .................................................................. 100
Practices for Lesson 13 ................................................................................................... 105
Managing HTTP Session States...................................................................................... 105
Practice 13-1: Managing HTTP Session States .......................................................... 111
EJB Load Balancing and Failover .................................................................................. 116
Practice 14-1: EJB Load Balancing and Failover ....................................................... 120
Clustering JDBC Data Sources....................................................................................... 126
Load-Balance JMS Messages ......................................................................................... 131
Practice 15-1: Clustering JDBC Data Sources............................................................ 135
Practice 15-2: Load-Balancing JMS Messages........................................................... 138

Practices for Lesson 1
Installing the Oracle WebLogic Server Software

(20 minutes)
After completing this exercise, you should be able to install the Oracle WebLogic Server 10.3
software.
To address the issues in the current Dizzyworld architecture, Oracle WebLogic Server enables
you to deploy, execute, and maintain highly integrated, high-performance, and reliable enterprise
applications.
Oracle WebLogic Server 10.3 increases productivity and lowers the cost structure for enterprise
IT organizations by providing a unified, simplified, and extensible platform for system
administrators and management.
You install the Oracle WebLogic Server software for use with the lab exercises. Oracle
WebLogic Server 10.3 offers a common application architecture that includes the following:
A set of integrated technology frameworks that provide a solutions-oriented starting point
for addressing your project needs
A unified, simplified management architecture that empowers developers and
administrators to realize business objectives in an environment that is populated with
distributed, heterogeneous technologies and platforms
A highly-reliable, available, scalable, extensible, standards-based, and high-performing
foundation that allows you to incorporate flexibility and choice in your IT solutions
Specifications
Table 1 displays the environment variables that are used throughout the lab exercises. These
environment variables are set by script files that are used at various points during the exercises.
Table 1
Environment Variable Example Description

<BEA_HOME> /u01/app/oracle/product/Mi Your installation directory for
ddleware Middleware products
<WEBLOGIC_HOME> /<BEA_HOME>/wlserver_10.3 The Oracle WebLogic Server 10.3
installation directory
<STUDENT> /home/oracle/wls_sysadm The student directory
<WORK_HOME> <STUDENT>/work The directory where users can

create their own domains
<LAB_HOME> <STUDENT>/labs/LabX-X The laboratory directories
<APACHE_HOME> /u01/app/apache The Apache Home directory

For all the practices, make sure that you are logged in as oracle/oracle unless explicitly
asked to log in as root/oracle.
Important Note: The following are some of the Ant scripts that you will use in the labs, with a
brief description of what each one does. To run these Ant scripts (except continue_work),
navigate to the <LAB_HOME> directory. To run continue_work, navigate to <WORK_HOME>.
The scripts can be used starting from Lab 3 onwards.
setup_exercise Creates a backup of your domain, starts databases and the

administration server if they are not running. When you run the ant
setup_exercise command, if you are prompted with the question, Do you want to
overwrite existing domain backup select Yes to continue. This script may also be used
in some lessons to perform operations that are required as a prerequisite for the lab (for
example, deploying an application implicitly).
setup_solution Starts databases and the administration server if they are not
running. It performs all the steps for the lab. Most of the setup_solution scripts
provide solution only for one particular lab. However, setup_solution for four
Cluster labs are cumulative lab solutions, that is, they provide solution for all prior cluster
labs when you run setup_solution.
continue_exercise Creates a backup of the last lab that you worked on and
replaces the domain with any backup copy for the current lab from the directory where
you run the script. It also starts databases and the administration server if they are not
running. Use continue_exercise to redo a previous lab starting from the backup
copy of the domain that was taken at the beginning of the lab using setup_exercise.
Run setup_exercise before starting each lab. Run continue_exercise to

revert to a previous lab to start working on it based on the backup that was taken before
the start of the lab using setup_exercise. Run setup_solution to successfully
complete an unfinished or incorrectly performed lab. Running setup_exercise is
required, whereas running either continue_exercise or setup_solution is
optional.
continue_work Starts databases and the administration server if they are not
running
Note: The solution script files are provided to you in the <LAB_HOME>/solution directory.
The exercise script files are provided to you in the <LAB_HOME>/exercise directory.
Basic Instructions
1. Install Oracle WebLogic Server 10.3. The installation program
(server103_linux32.bin) is located in /stage.

Practice 1-1: Installing Oracle WebLogic Server 10.3
In this practice, you install Oracle WebLogic Server 10.3 by performing the following
steps:
1.1 Run the installation program: server103_linux32.bin

$ cd /stage/weblogic_server103
$ ./server103_linux32.bin
1.2 Use the following configuration information:
Screen Value
Choose BEA Home Directory /u01/app/oracle/product/Middle
ware
Note: Select Yes when a warning
message appears stating that The
directory is not empty, do you want to
proceed?
Choose Install Type Custom
Choose Products and Components Deselect the Workshop option.
JDK Selection Bundled JDK - BEA JRockit 1.6.0_05

SDK
Choose Product Installation Directories /u01/app/oracle/product/Middle
ware/wlserver_10.3
1.3 Review Installation Summary. Finally, deselect the Run Quickstart check box and click
Done to complete the installation.

Configuring a Domain Template

(30 minutes)
After completing this practice, you should be able to create:
A new custom domain template
A new domain using the custom domain template
The Dizzyworld system architects have decided to create a customized domain template by using
Domain Template Builder so as to have the flexibility to create domains for multiple
development, test, and production environments.
In this lab, you create your own customized template called dizzyworld.jar using Domain
Template Builder. You then use the Configuration Wizard to create the dizzyworld domain
with the customized domain template dizzyworld.jar that you created.
Note: For Lab 2-1

setup_solution Creates a dizzyworld domain from the template using Oracle
WebLogic Server Scripting Tool (WLST)

The Domain Template Builder:

Basic Instructions
1. Configure a new domain template dizzyworld.jar using the Domain Template Builder
tool. Start the Domain Template Builder.
Configure the Administration Server with the following specifications:

Name: AdminServer
Listen address: All Local Addresses
Listen Port: 7001
Note: Do not enable SSL.
Configure the Administrator username and password with the following specifications:
Username: system
Password: weblogic
Confirm user password: weblogic
Currently, there is no need to configure additional users, groups, and global resources
roles.
Create the template using the following specifications:

Template jar name: dizzyworld
Template location: <WORK_HOME>/templates
2. Build a dizzyworld domain using the newly created domain template dizzyworld.jar
and the Configuration Wizard tool.
Add a Managed Server with the following specifications to the dizzyworld domain:
Name: dizzy1
Listen Port: 7003
Create a Oracle WebLogic Server domain with the following specifications:

Domain name: dizzyworld
Domain location: <WORK_HOME>/domains
3. Test the domain that was created by changing the directory to
<WORK_HOME>/domains/dizzyworld and executing the following:
./startWebLogic.sh
Specify the following username and password:

Username: system
Password: weblogic

Using the Administration Console
(15 minutes)
After completing this exercise, you should:

Be familiar with the Administration Console
Practice modifying the properties of Oracle WebLogic Server using the Administration
Console
Configure and view log file entries for an Oracle WebLogic Server using the
Administration Console
Oracle WebLogic Server is administered by using a Web-based Administration Console

that enables you to configure and monitor the Oracle WebLogic servers. Using Log
messages, you can detect problems, track down the source of an error, and track system
performance.
Note: For Lab 2-2

setup_solution Updates the Standard out threshold by using the WLST script
Basic Instructions
1. Start Oracle WebLogic Server for the examples domain wl_server.
2. Use the Administration Console to modify the standard output severity threshold for the
wl_server to Info.
3. Shut down the examplesServer(admin) server by using the Administration Console.
4. Restart the Administration Server, and then view the server logging for examplesServer
using the Administration Console.

Using the Command Line
(10 minutes)
After completing this exercise, you should be familiar with the WebLogic Scripting Tool
(WLST), which is a command-line administration utility.
The WLST utility allows you to monitor servers from the command line. Also, from the
command line, you can shut down the server, change server attributes, and configure a
domain.
Basic Instructions
1. Set up the exercise by running examplesServer and opening a command prompt using
./prompt.sh that is found in <STUDENT>/bin.
2. Update a running server using WLST in Online mode to set the log FileCount for the
examplesServer to 8.
3. Disable the SSL listen port for examplesServer by using WLST.

Practice 2-1: Configuring a Domain Template
In this practice, you configure a new domain template by performing the following steps:
Configure a new domain template using the Domain Template Builder tool.
1.1 You can create a domain template by using the Domain Template Builder tool. Start the
Domain Template Builder.
Open a prompt using ./prompt.sh in the <STUDENT>/bin directory and navigate to
<WEBLOGIC_HOME>/common/bin. Execute the config_builder.sh script.
1.2 In the Create a New Template window, select Create a Domain Template, and then
click Next.
1.3 In the Select a Template Domain Source window, click the Select a Template tab.
Select Basic WebLogic Server Domain and click Next.
1.4 In the Describe the Template window, specify the following:
Name: Dizzyworld Domain
Retain the default values for all the other fields. Click Next.
1.5 You do not need to add files currently. Click Next in the Add Files window.
1.6 You do not need to add SQL scripts currently, so click Next on the Add SQL Scripts
window.
1.7 In the Configure the Administration Server window, specify the following:
Name: AdminServer
Listen Port: 7001
Note: Do not enable SSL.

Retain all the default settings in this window.
1.8 In the Configure Administrator Username and Password window, specify the following:
User name: system

User password: weblogic
Confirm user password: weblogic
Currently, there is no need to configure additional users, groups, and global roles;
therefore, select the No option and click Next.
Note: You can retain the default for Description.

1.9 Retain the defaults in the Specify Start Menu Entries window and click Next.
1.10 You do not need to prepare scripts and files with replacement variables. Click Next.
1.11 Review the WebLogic Domain Template and make sure that AdminServer is listed
under the Server tree. Click Next.

Practice 2-1: Configuring a Domain Template (continued)
1.12 In the Create a Template window, specify the following:
Template jar name: dizzyworld

Template location: <WORK_HOME>/templates
If prompted, click Yes to confirm the creation of the templates directory, and then click
Create. Click Done.
1.13 Inspect the dizzyworld.jar file that is created under the <WORK_HOME>/templates
directory to familiarize yourself with the file created by the Domain Template Builder.
Build a dizzyworld domain using the newly created domain template dizzyworld.jar.
2.1 Using the domain template that was created in the previous step, you can create a
domain using the Configuration Wizard tool.
Start the Configuration Wizard.

Open a prompt using ./prompt.sh in the <STUDENT>/bin directory and navigate to
<WEBLOGIC_HOME>/common/bin. Execute the config.sh script.
2.2 In the Welcome window, select Create a new WebLogic Domain and click Next.
2.3 In the Select Domain Source window, select Base this domain on an existing template
and click Browse to give the directory location of the template. Browse to the
<WORK_HOME>/templates directory, select dizzyworld.jar, and click Next.
2.4 In the Configure Administrator Username and Password window, verify the username
and password, and click Next.
2.5 In the Configure Server Start Mode and JDK window, select JRockit SDK 1.6.0_05 as
the JDK Selection, click Production Mode as the WebLogic Domain Startup Mode, and
then click JRockit SDK 1.6.0_05 again as the JDK Selection. Click Next.
Note: Sometimes, students may find the Lock & Edit button missing in the Administration
Console after you create the domain and log in to the Administration Console. This may
be due to the order in which mode and JDK are selected. If that happens, you can fix the
issue by going to Preferences > User Preferences and deselecting Automatically acquire
lock and activate changes.
2.6 Because you will configure other Managed Servers for the dizzyworld domain, select
Yes in the Customize Environment and Services Settings window. Click Next.
2.7 Select the defaults in the Configure RDBMS Security Store Database window and click
Next.
In the Configure the Administration Server window, verify the Administration Server
specifications and click Next.
2.8 In the Configure Managed Servers window, click Add to add a Managed Server with the
following specifications:
Name: dizzy1
Listen Port: 7003
Click Next.

Practice 2-1: Configuring a Domain Template (continued)
2.9 You do not need to create a cluster, so in the Configure Clusters window, click Next.
2.10 You do not need to create machines now, so in the Configure Machines window, click
Next.
2.11 Review the WebLogic domain and make sure that AdminServer and dizzy1 are listed
under the Server tree. Click Next.
2.12 In the Create WebLogic Domain window, specify the following:
Domain name: dizzyworld
Domain location: <WORK_HOME>/domains
Click Create, and then click Done.

Test the created domain.
3.1 Inspect the subdirectories under the <WORK_HOME>/domains/dizzyworld directory to
familiarize yourself with the files created by the Configuration Wizard.
3.2 Open a command prompt by using ./prompt.sh found in <STUDENT>/bin.
3.3 Verify that the domain is configured properly and that the server starts up by browsing to
the <WORK_HOME>/domains/dizzyworld directory in the command prompt and
executing the following:
./startWebLogic.sh
3.4 Specify the username and password:
Username: system
Password: weblogic
After you have verified that the server starts up properly, shut down the server by entering
CTRL C in the command-line window.

Practice 2-2: Using the Administration Console
In this practice, you start and stop Oracle WebLogic Server by using the Administration
Console and view the server logs.
Start Oracle WebLogic Server for the Examples Domain wl_server.

1.1 Open a prompt by using ./prompt.sh in <STUDENT>/bin.
1.2 Change to the <WEBLOGIC_HOME>/samples/domains/wl_server directory.
1.3 Make sure that all the previously running servers are shut down and execute the following
script to start the examples server:
./startWebLogicEx.sh
Note: Be patient; it takes a while to start the server because a few applications are
already deployed on the server. You may see the following error in stdout, this is benign:
Could not invoke the browser. Failed to show URI:

http://<ip_address>:7001/index.jsp
Try localhost or a fully qualified distinguished name instead of the IP address and it
should work.
Use the Administration Console to modify the standard output severity threshold for
wl_server to Info.
2.1 If not already open, open a Web browser and navigate to http://localhost:7001/console.
Log in as:
Username: weblogic
Password: weblogic
2.2 Navigate to wl_server > Environment > Servers > examplesServer(admin) >
Logging > General.
2.3 Scroll to the bottom of the page and click Advanced.
2.4 Set the following properties:
Redirect stdout logging enabled: Selected

2.5 In the Message Destination(s) section, set the following Standard out properties:
Severity level: Info

2.6 Save your changes.
Shut down the examplesServer(admin) server using the Administration Console.
3.1 Navigate to wl_server > Environment > Servers > examplesServer(admin) >
Control > Start/Stop. Verify that the examplesServer(admin) check box is selected
in the Server Status table and click Shutdown.

Practice 2-2: Using the Administration Console (continued)
3.2 Start the server again using the instructions in the preceding steps 1.1 through 1.3. (The
Prompt window that you opened should still be available.)
3.3 Note how much more information is output to the stdout I/O stream when the server is
started again (once again, you should see a number of notices of severity <Info>).
View server logging for the examplesServer using the Administration Console as the
log viewer.
4.1 Open a Web browser and navigate to http://localhost:7001/console.
Log in as:
Username: weblogic
Password: weblogic
4.2 Navigate to wl_server > Diagnostics > Log Files.
4.3 In the Log Files table, select ServerLog and click View. This allows you to view log file
entries via the console.

Practice 2-3: Using the Command Line
In this practice, you learn how to work with WLST to perform basic operations such as
setting log FileCount for Oracle WebLogic Server and disabling the SSL listen port.
Set up the exercise.

1.1 If not already running, start examplesServer by using the steps described in the Using
the Administration Console lab.
1.2 Open a prompt using ./prompt.sh in <STUDENT>/bin.
Update a running server using WLST in online mode to set the log FileCount for
examplesServer to 8.
2.1 Start the WLST by enter the following command at the prompt:
java weblogic.WLST
Note: WLST is case-sensitive.

2.2 At the wls:/offline> prompt, enter:
connect(weblogic, weblogic, t3://localhost:7001)

2.3 After you are connected, at the wls:/wl_server/serverConfig> prompt, enter the
following series of commands:
edit()
cd(Servers)
cd(examplesServer)
cd(Log)
cd(examplesServer)
startEdit()
set(FileCount,8)
save()
activate()
disconnect()
exit()
Note: If you do not want to enter the entire command, write scripts that contain the
command invocations.
Note: The solution script files are provided to you in the <LAB_HOME>/solution
directory. You can execute the solution scripts from the prompt window by entering
the following command: java weblogic.WLST fileCount.py.
2.4 You can see the effect of this series of commands by navigating to wl_server >
Environment > Servers > examplesServer(admin) > Logging > General. Check that
the value of the Files To Retain attribute is set to 8.

Practice 2-3: Using the Command Line (continued)
Disable the SSL listen port for examplesServer using WLST
3.1 Disable the SSL listen port by using WLST. Before disabling the SSL listen port, you can
check whether the SSL listen port value is set by navigating to wl_server >
Environment > Servers > examplesServer(admin) > Configuration > General in
the Administration Console. Look for the SSL Listen Port Enabled flag.
Hint:
To move back a directory, use the command, cd(..).
To see the attributes under a directory, use the command, ls().
Note: The solution script files are provided to you in the <LAB_HOME>/solution
directory. You can execute the solution scripts from the prompt window by entering the
following command:
java weblogic.WLST SSLDisabled.py
You can verify the results by checking whether the SSL Listen Port Enabled check box is
selected in the Administration Console as stated above.
3.2 Shut down examplesServer when you have finished with the lab. You do not need
examplesServer for the rest of this course.

Configuring Servers and Machines

(30 minutes)
After completing this practice, you should be able to:
Create WebLogic machines
Create Managed Servers
Assign Managed Servers to machines
Start Managed Servers
The Dizzyworld system architects have decided to simulate the production environment by
configuring Managed Servers and machines for the dizzyworld domain to host business
applications and use the Administration Server to configure and monitor the Managed Servers.
Note: For Lab03-1

setup_exercise Creates a dizzyworld domain from the template using WLST and adds the
dizzy1 server using the WLST script
setup_solution Adds all Managed Servers and machines using the WLST scripts
In this lab, you create and configure the Managed Servers dizzy1, dizzy2, and dizzy3
and machines dizzyMachine1 and dizzyMachine2 for the dizzyworld domain that you
created to simulate the production environment.
Specifications
Table 2 Managed Server Specifications
Server Name Listen Address Listen Port SSL Listen Port

dizzy1 127.0.0.1 7003 7004
dizzy2 127.0.0.1 7005 7006
dizzy3 127.0.0.1 7007 7008
Table 3 Machine Specifications
Node Manager Listen Node Manager Listen

Name Address Port (Type = Plain) Server
dizzyMachine1 127.0.0.1 5555 dizzy1
dizzyMachine2 127.0.0.1 5556 dizzy2
dizzy3

Basic Instructions
1. Set up the exercise by opening a command prompt using ./prompt.sh found in the
<STUDENT>/bin directory. Change to the <LAB_HOME> directory and enter:
ant setup_exercise
2. Because the dizzy1 Managed Server was configured while configuring the domain in the
previous labs, in this lab, you create the remaining Managed Servers dizzy2 and
dizzy3 by referring to the server specifications in Table 2.
3. Create and configure the machines dizzyMachine1 and dizzyMachine2 by referring
to the machines specifications in
Table 3.
4. Test the configuration by starting the created Managed Servers using the command line,
by executing the following command that replaces <server_name> with the name of the
Managed Server:
./startManagedWebLogic.sh <server_name> http://127.0.0.1:7001
Tip: If you are using the local address for the Administration Server, you can simply
supply the <server_name> as the argument.
5. (Optional): To set up the solution for this lab, open a command prompt using
./prompt.sh found in the <STUDENT>/bin directory. Change to the <LAB_HOME>
directory and enter:
ant setup_solution

Starting the Servers Using Node Manager
(40 minutes)
After completing this exercise, you should be able to:

Configure a machine for remote startup and shutdown
Configure and run Node Manager
Start and stop servers remotely
The Dizzyworld system architects have determined that it would be beneficial to have the option
to remotely start any Managed Server instances. They decided to configure Node Manager for
dizzyMachine2, which will allow the Administration Server to remotely start the Managed
Servers instances dizzy2 and dizzy3 that are running on dizzyMachine2.
Note: For Lab03-2

setup_exercise Adds all Managed Servers and machines using the WLST scripts
setup_solution Starts the Managed Servers via Node Manager using the WLST scripts
Node Manager is a Java program running in a remote machine that allows the Administration
Server to remotely start any Managed Server instances on that machine. It can also be used to
monitor the health status of the Managed Servers on that machine. In this lab, you configure Node
Manager properties for dizzyMachine2 and remotely start the Managed Server instances
running on dizzyMachine2 using the Administration Console.
Specifications
Figure 1 presents the infrastructure that consists of three Managed Server instances running on
two physical machines.
Figure 1: Dizzyworld machines and server instances

Although one machine is centrally located in the IT department, the other is in another building
across town. Restarting server instances on the remote machine has been a problem.
To make it easier to manage remote server instances, configure and run the Node Manager
service on the remote machine, dizzyMachine2 (Figure 2).
Figure 2: Node Manager
The Node Manager service runs on Port 5556. You must declare the AdminServers IP address
as a trusted host so that it can access the Node Manager process on dizzyMachine2.
Design Specifications
Element Value
Node Manager service port for dizzyMachine2 5556
IP Address of AdminServer 127.0.0.1
Node Manager service port for dizzyMachine1 5555

Basic Instructions
1. Set up the exercise by opening a command prompt ./prompt.sh found in
<STUDENT>/bin. Change to the <LAB_HOME> directory and enter:
ant setup_exercise
Note: There is no automated solution that is set up for this lab, so you will have to walk
through all the steps to complete it.
2. Connect to the domain using WLST. Apply the nmEnroll WLST command to enroll the
machine. Navigate to Domain and set the classpath of servers.
3. Open a prompt and change to the <WEBLOGIC_HOME>/server/bin directory.
Start Node Manager to listen on port 5555 on dizzyMachine1 by executing the following
command:
./startNodeManager.sh 127.0.0.1 5555
Start Node Manager to listen on port 5556 on dizzyMachine2 by executing the following
command:

4. Start the servers using the Node Manager service.

Configuring Network Channels and Network Access
Points (Optional)
(15 minutes)
After completing this exercise, you should be familiar with setting up network channels.
The Dizzyworld system architects have decided to configure network channels for
AdminServer and the dizzy1 Managed Server that will define the attributes of a
network connection to Oracle WebLogic Server.
Note: For Lab03-3

setup_exercise Deploys benefits.war to dizzy1 using WLST
setup_solution Configures network channels using the WLST scripts
In WebLogic 10.3, a server instance need not be bound to a single network address, or a
single port number/secure port. A network channel provides this functionality. A network
channel is a configurable resource that defines the attributes of a network connection to
Oracle WebLogic Server. For instance, a network channel can define:
The protocol that the connection supports
The listen address
The listen ports for secure and nonsecure communication
Connection properties such as the login timeout value and maximum message
sizes
Whether or not the connection supports tunneling
Whether the connection can be used to communicate with other Oracle
WebLogic Server instances in the domain, or used only for communication
with clients
In this lab, you configure a new NetworkChannel called DizzyworldNetworkChannel1 on
the dizzy1 Managed Server that supports the http protocol, localhost for the listen
address, and 9001 for the listen port. You also configure a NetworkChannel called
DizzyworldNetworkChannel2 on the AdminServer that supports the http protocol,
localhost for the listen address, and 9003 for the listen port.

Basic Instructions
1. Set up the exercise by opening a command prompt ./prompt.sh found in
ant setup_exercise
2. Create a new NetworkChannel called DizzyworldNetworkChannel1 on the dizzy1

Managed Server with the following specifications:
Name: DizzyworldNetworkChannel1
Protocol: http
Listen Address: localhost
Listen Port: 9001
External Listen Address: localhost
External Listen Port: 9001
3. Test the newly created channel using the benefits.war application deployed to the
dizzy1 Managed Server by browsing to http://localhost:9001/benefits.

4. Create a new NetworkChannel called DizzyworldNetworkChannel2 on the
AdminServer with the following specifications:
Protocol: http
Listen Port: 9003
Test the newly created channel by browsing to http://localhost:9003/console.

5. (Optional): Set up the solution for this lab, if you are unable to complete it. Make sure that
AdminServer and dizzy1 are running. Open a command prompt using ./prompt.sh
found in the <STUDENT>/bin directory. Change to the <LAB_HOME> directory and enter:
ant setup_solution

Practice 3-1: Configuring Servers and Machines
In this practice, you configure the Managed Servers and machines.

1.2 Change to the <LAB_HOME> directory.
1.3 Copy the boot.properties file from the <LAB_HOME>/exercise folder to the
<WORK_HOME>/domains/dizzyworld folder so that when the server starts, you do not
have to specify the Administrative credentials explicitly.
1.4 Enter the following command:
ant setup_exercise
Create the servers.

Log in as:
Username: system
Password: weblogic
2.2 Navigate to dizzyworld > Environment > Servers > dizzy1 > Configuration >
General. Lock the console. Update the Managed Server dizzy1 to match the
specifications in Table 2.
2.3 Because you already have the dizzy1 server configured, you now configure the dizzy2
and dizzy3 servers.
2.4 Navigate to dizzyworld > Environment > Servers. Under the Servers table, click New.
Specify the following properties on the Create a New Server page:
Server Name: dizzy2

Server Listen Address: 127.0.0.1
Server Listen Port: 7005
Under Should this server belong to a cluster? select No, this is a standalone
server.
2.5 Click Next, review the selections and if they are correct, click Finish to create the server.

Practice 3-1: Configuring Servers and Machines (continued)
General. Specify the following properties:
SSL Listen Port Enabled: Selected

SSL Listen Port: 7006
Note: Leave the machine setting at None in this step. You will assign the machines to the
Managed Servers after you create them.
Save and Activate your changes.
2.7 Similar to how you created and configured the Managed Server dizzy2, create the
Managed Server dizzy3 using the Managed Server specifications from Table 2.
Create and configure the machines.
3.1 Navigate to dizzyworld > Environment > Machines. Lock the console. Under the
Machines table, click New. Specify the following properties on the Create a New
Machine page:
Name: dizzyMachine1
Machine OS: Unix (Linux)
Click OK.
Activate your changes.
3.2 Assign the machine dizzyMachine1 to the dizzy1 server by clicking the machine
name. Lock the console and click the Servers tab.
3.3 Click Add under the Servers table. Select dizzy1 from the existing server drop-down list
and click Finish.
3.4 Click the Node Manager tab to enter the properties of Node Manager for this machine
according to the machine specifications (Table 3).
Note: In this training environment, you use a PLAIN text connection between Node
Manager and the servers. In production, using SSL secures the communication when
using the Java-based Node Manager.
3.5 Save and activate your changes.
3.6 Repeat this process to create the machine, dizzyMachine2, by referring to the machine
specifications in
Table 3, and assign the Managed Servers dizzy2 and dizzy3 to dizzyMachine2.
Also configure the Node Manager properties for the machine.
Test the configuration by starting the created Managed Servers.
4.2 Change to the <WORK_HOME>/domains/dizzyworld/bin directory.

Practice 3-1: Configuring Servers and Machines (continued)
4.3 Start the Managed Servers using the command line by executing the following command
that replaces <server_name> with the name of the Managed Server:
./startManagedWebLogic.sh <server_name> http://127.0.0.1:7001
Tip: If you use the local address for the Administration Server, you can simply supply the
<server_name> argument.
4.4 If prompted, enter the Administrator credentials at server prompt.
Note: Check to make sure that all Managed Servers are up and running. Before
you start the next lab, make sure that all Managed Servers are stopped (CTRL+
C to stop dizzy1, 2, and 3 on terminal windows).
(Optional) Set up the solution, if unable to complete the lab.
5.1 To set up the solution for this lab, open a command prompt ./prompt.sh found in the
<STUDENT>/bin directory. Change to the <LAB_HOME> directory and enter:
ant setup_solution

Practice 3-2: Starting Servers Using Node Manager
In this practice, you configure Node Manager, and then start the server using Node
Manager.
ant setup_exercise
Run the nmEnroll WLST command.


Practice 3-2: Starting Servers Using Node Manager (continued)
2.2 Start WLST by entering the following command at the prompt:
java weblogic.WLST
Note: WLST is case-sensitive.

2.3 At the wls:/offline> prompt, enter:
connect (system,weblogic,t3://localhost:7001)
2.4 After you are connected at the wls:/dizzyworld/serverConfig> prompt, enter the
following command:
nmEnroll ([domainDir], [nmHome])
wls:/dizzyworld/serverConfig>
nmEnroll(/home/oracle/wls_sysadm/work/domains/dizzyworld,/u01/
app/oracle/product/Middleware/wlserver_10.3/common/nodemanager)
2.5 Go to the Administration Console and navigate to dizzyworld > Environment >
Servers > dizzy1 > Configuration > Server Start. Lock the console.
2.6 Set the classpath.
Note: You can copy CLASSPATH from

<LAB_HOME>/exercise/classpath_unix.txt. Place code all in one line.
2.7 Click Save and click Activate Changes. Repeat steps 2.5 through 2.7 for dizzy2 and
dizzy3.
Start Node Manager.
3.1 Open a command prompt and change to the <WEBLOGIC_HOME>/server/bin
directory.
3.2 Start Node Manager to listen on port 5555 on dizzyMachine1 by executing the
following command:

Practice 3-2: Starting Servers Using Node Manager (continued)
3.3 Start Node Manager to listen on port 5556 on dizzyMachine2 by executing the
following command:
Start the servers using the Node Manager service.
4.1 Return to the Administration Console and navigate to dizzyworld > Environment >
Servers > dizzy1 > Control > Start/Stop. Select the check box against dizzy1 in the
Server Status table and click Start. When prompted to verify whether you want to start
the dizzy1 Managed Server, click Yes.
Note: If you get an error, shut down the Node Manager associated with 5555, edit the
nodemanager.properties file under
/u01/app/oracle/product/Middleware/wlserver_10.3/common/nodemanag
er, and make sure that the SecureListener property is set to false. Start Node Manager
and try step 4.1 again.
4.2 Repeat the preceding step to start the Managed Servers dizzy2 and dizzy3.
4.3 Navigate to dizzyworld > Environment > Servers. Verify the running state for both the
Managed Servers dizzy2 and dizzy3.
Alternatively, use the command prompt window and run netstat an to verify that the
servers dizzy1, dizzy2, and dizzy3 are listening.
4.4 Stop dizzy1, dizzy2, and dizzy3 and both Node Managers.
Note: From here on, you should try to start or stop the Administration Server and the
Managed Servers using the command line rather than the Administration Console just to
be consistent. This will also allow you to see the error/debug/info messages easily on the
terminal window (especially in the case of Clustering labs).

Practice 3-3: Configuring Network Channels and Network
Access Points (Optional)
In this practice, you create and test a new network channel.

ant setup_exercise
You must run this script for this lab to work.

Create a new NetworkChannel called DizzyworldNetworkChannel1 on dizzy1
Managed Server.
2.1 Start AdminServer and the dizzy1 server in the dizzyworld domain if they are not
already running.
Note: Do not start dizzy1 using Node Manager.
2.2 Navigate to dizzyworld > Environment > Servers > dizzy1 > Protocols >
Channels. Lock the console. In the Network Channels table, click New to create a new
channel and specify the following properties:
Protocol: http
2.3 Click Next.
2.4 On the Create a new Network Channel page, specify the following properties:

Listen Port: 9001
2.5 Click Finish and activate your changes.
Test the newly created channel using the benefits.war application deployed to the
dizzy1 Managed Server.
3.1 To test the default channel, browse to http://localhost:7003/benefits. You can then test the
new network channel by browsing to http://localhost:9001/benefits.
Create a new NetworkChannel Called DizzyworldNetworkChannel2 on the
AdminServer.
4.1 Navigate to dizzyworld > Environment > Servers > AdminServer > Protocols >
Channels. Lock the console.

Practice 3-3: Configuring Network Channels and Network
Access Points (Optional) (continued)
4.2 In the Network Channels table, click New to create a new channel and specify the
following properties:
Protocol: http
4.3 Click Next.
4.4 On the Create a new Network Channel page, specify the following properties:

Listen Port: 9003
4.5 Click Finish and activate your changes.
4.6 To test the newly created channel, browse to http://localhost:9003/console.
5.1 Set up the solution for this lab, if you are unable to complete it. Make sure that
found in the <STUDENT>/bin directory. Change to the <LAB_HOME> directory and enter:
ant setup_solution

Deploying and Undeploying Web Applications

(15 minutes)
At the end of this exercise, you should be able to deploy a prepackaged .war file.
The Dizzyworld system architects want to deploy a company benefits Web application that
allows employees to view the company benefits. For this exercise, you need to deploy a
prepackaged application to the dizzy1 Managed Server in the dizzyworld domain.
Note: For Lab04-1

setup_exercise Undeploys benefits.war using WLST
setup_solution Deploys benefits.war to dizzy1 using WLST
Interactive, Web applications are groupings of static pages and dynamic pages for the
overall application. They can be packaged in a Web Archive file with a .war extension.
They are packaged using the JAR utility. In this lab, you deploy the Web application
benefits.war, and also deploy and undeploy the benefits_as_default.war
Web application.
Specifications
Figure 3 presents the dizzyworld domain.
Figure 3: The dizzyworld domain

Basic Instructions
1. Set up the exercise by opening a command prompt using ./prompt.sh that is located in
ant setup_exercise
2. Deploy the benefits.war Web application.
3. Deploy the benefits_as_default.war Web application.
4. Undeploy the benefits_as_default.war Web application using the Administration
Console.
5. (Optional): Set up the solution for this lab, if you are unable to complete it. Make sure that
that is located in the <STUDENT>/bin directory. Change to the <LAB_HOME> directory
and enter:
ant setup_solution

Practice 4-1: Deploying/Undeploying Web Applications
In this practice, you deploy, and then undeploy a Web application.

ant setup_exercise
Deploy the Web application benefits.war.

2.1 Start AdminServer and the dizzy1 Managed Server if they are not already running.
2.2 Navigate to the <WORK_HOME> directory and create an applications directory, if not
already there.
2.3 Navigate to the <LAB_HOME>/exercise directory, locate the benefits.war file, and
copy it to the <WORK_HOME>/applications directory. Replace the existing application,
if present.
Log in as:
Username: system
Password: weblogic
2.5 Navigate to dizzyworld > Deployments. Lock the console.
2.6 If benefits.war exists, select the benefits application, and then click Stop > Force
Stop Now. (The state changes to Prepared. If you click Prepared, you can see that the
application is successfully stopped.) Select the benefits application, and then click
Delete. Activate your changes, and then re-lock the console.
2.7 Lock the console. In the Deployments table, click Install. Navigate to the location
<WORK_HOME>/applications, select benefits.war and click Next.
2.8 On the Choose Targeting Style page, select Install this deployment as an
application, which is the default option, and click Next.
2.9 On the Select Deployment Targets page, select the dizzy1 Managed Server in the
Servers table and click Next.
2.10 On the Optional Settings page, under the Source Accessibility header, select Copy
this application onto every target for me and click Next.
2.11 On the Review page, select No, I will review the configuration later under the
Additional Configuration header and click Finish.
2.12 Activate your changes.
2.13 Navigate to dizzyworld > Deployments. In the Deployments table, select the benefits
application check box and click Start > Servicing All Requests.

(continued)
2.14 The Summary of Deployments page should indicate the module state as Active or
Distribute Running when the deployment has been completed.
2.15 Verify that the deployment has been completed by opening a browser and navigating to
http://localhost:7003/benefits.
This should open up the Dizzyworld benefits application.
Deploy the Web application benefits_as_default.war.
3.1 Sometimes, it is convenient to set a Web application as a default Web application for a
server, so that in the request URL, you can omit the context name. You can select one
default Web application per server. In this lab, the benefits_as_default.war
application has been configured to be the default Web application.
Note: The only difference between benefits.war and benefits_as_default.war

is that the latter has a deployment descriptor file called /WEB-INF/weblogic.xml,
which contains the stanza:
<weblogic-web-app>
<context-root>/</context-root>
</weblogic-web-app>
Note: A similar result could also have been achieved by navigating to Servers > dizzy1 >
Protocols > HTTP tab of the admin console and specifying value for the attribute "Default
WebApp Context Root". This way developers don't have to built-in this information during
development.
3.2 Navigate to the <LAB_HOME>/exercise directory, locate the
benefits_as_default.war file, and copy it to the <WORK_HOME>/applications
directory.
3.3 Deploy the benefits_as_default.war Web application that is located in the
<WORK_HOME>/applications directory to dizzy1.
Note: Do not forget to activate the changes and start the application.
3.4 Verify the default Web application configuration by browsing to http://localhost:7003.
Note: You do not need to specify the application root /benefits in the requested URL
any more.
Undeploy the benefits_as_default.war Web application using the Administration
Console.
4.2 In the Deployments table, click benefits_as_default. The settings for
benefits_as_default appears. Click the Targets tab, deselect the check box for the
dizzy1 target, and then click Save. Under Message, you should get a confirmation that
your settings were saved successfully.

(continued)
4.4 Verify that the Web application was indeed undeployed by browsing to
http://localhost:7003.
You should get an error, Error 404 Not Found, when you do this.
Note: If you use the same browser window to request the Web application, browser
caching may result in pages being served even after the application itself is undeployed.
You can clear the browser cache for Firefox by selecting Edit > Preferences > Privacy >
Cache Options from the Menu bar and clicking Clear Cache Now. Reload the page.
that is located in the <STUDENT>/bin directory. Change to the <LAB_HOME> directory
and enter:
ant setup_solution
Note: Running the ant setup_solution script completes only a portion of the lab.
(Deploy the Web application benefits.war steps from 2.1 to 2.15.) The remaining part
of the lab, the Deploy/Undeploy the benefits_as_default.war Web Application
section has to be completed manually.

There are no practices for this lesson.

Configuring Data Sources

(15 minutes)
Create a JDBC data source
Locate a JDBC data source in a servers JNDI tree
The Dizzyworld system architects have decided to create the dizzyworldDS data source object
to connect to HRDATABASE because data sources and their connection pools provide connection
management processes that help keep the system running.
Note: For Lab06-1

setup_solution Creates a data source using the WLST script and deploys testds.war
to dizzy1 using WLST
A DataSource object enables a JDBC client to obtain a DBMS connection from a JDBC pool.
The connection pool within a JDBC data source contains a group of JDBC connections that
applications reserve, use, and then return to the pool. The connection pool and the connections
within it are created when the connection pool is registered, usually when starting up Oracle
WebLogic Server or when deploying the data source to a new target. In this lab, you create a
dizzyworldDS data source to connect to HRDatabase. See the following diagram:

Specifications
Figure 4: Dizzyworld Domain

Basic Instructions
ant setup_exercise
2. Create a DataSource with the following specifications:
Name: dizzyworldDS
JNDI Name: dizzyworldDS
Database Type: PointBase
Database Driver: *PointBases Driver (Type 4)versions:4.x,5.x
Database Name: HRDATABASE
Host Name: localhost
Port: 9092
Database User Name: PBPUBLIC
Password: PBPUBLIC
Initial Capacity: 5
Maximum Capacity: 15
Capacity Increment: 5
Login Delay: 1
Target: dizzy1
3. Verify the DataSource by deploying a prepackaged testds.war Web application and
navigating to http://localhost:7001/testds/testdatasource.jsp to test the datasource.
4. (Optional): To set up the solution:
Make sure that HRDatabase, AdminServer, and dizzy1 are running
Enter ant setup_solution from <LAB_HOME>

Practice 6-1: Configuring Data Sources
In this practice, you create and validate a new DataSource.

Edit setDomainEnv.sh in
/home/oracle/wls_sysadm/work/domains/dizzyworld/bin to change
the classpath as follows:
CLASSPATH="${PRE_CLASSPATH}${CLASSPATHSEP}${WEBLOGIC_CLASSPATH}${
CLASSPATHSEP}${POST_CLASSPATH}${CLASSPATHSEP}${WLP_POST_CLASSPATH
}${CLASSPATHSEP}${WL_HOME}/common/eval/pointbase/lib/pbembedded57
.jar:${WL_HOME}/integration/lib/util.jar"
ant setup_exercise
Create a DataSource object.

2.1 Start AdminServer and the dizzy1 Managed Server if they are not already running.
Log in as:
Username: system
Password: weblogic
2.3 Navigate to dizzyworld > Services > JDBC > Data Sources. Lock the console.
2.4 On the Summary of JDBC Data Sources page, lock the console and click New under the
Data Sources table. Specify the following properties for configuring a JDBC data source:
Name: dizzyworldDS
JNDI Name: dizzyworldDS
Database Driver: *PointBases Driver(Type 4)versions:4.x,5.x
Note: Do not select the Type 4 XA driver.

2.5 Click Next.
2.6 On the Transaction Options page, retain the default options and click Next.

Practice 6-1: Configuring Data Sources (continued)
2.7 Define the following connection properties:
Database Name: HRDATABASE

Port: 9092
Password: PBPUBLIC
2.8 Click Next.
2.9 Click Test Configuration to check if the connection to the database is working, and then
click Next.
2.10 Target the dizzy1 Managed Server and click Finish.
2.11 Click dizzyworldDS under the Data Sources table on the Summary of JDBC Data
Sources page.
2.12 Click the Configuration > Connection Pool tab. Specify the following parameters:
Initial Capacity: 5
Maximum Capacity: 15
Capacity Increment: 5
2.14 Check the JNDI tree of the dizzy1 Managed Server to make sure that the data source is
deployed. Look for a JNDI entry called dizzyworldDS.
Verify the DataSource by deploying a prepackaged testds.war Web application.
3.1 Navigate to the <LAB_HOME>/exercise directory, locate the testds.war file, and
copy it to the <WORK_HOME>/applications directory.
3.3 Select Install, navigate to <WORK_HOME>/applications, and select testds.war.
3.4 Make sure that you opt to Install this deployment as an application, target the
application to dizzy1, and select Copy this application onto every target for me for
Source accessibility on the Optional Settings page. Click Finish.
3.5 Activate your changes, and then start the application.
3.6 Open a Web browser and navigate to http://localhost:7003/testds/testdatasource.jsp to
test the data source. Use the Test Data Source button to retrieve data from the HR
database.

Practice 6-1: Configuring Data Sources (continued)
4.1 Set up the solution for this lab, if you are unable to complete it. Ensure that HRDatabase,
AdminServer, and dizzy1 are running. Open a command prompt using
./prompt.sh that is located in the <STUDENT>/bin directory. Change to the
<LAB_HOME> directory and enter:
ant setup_solution
Note: Restart the dizzy1 server after running the solution script. Make sure that the
state of the testds application is Active before testing the testds application.

Configuring the JMS Servers and Destinations

(30 minutes)
After completing this practice, you should be able to get hands-on experience with configuring
and monitoring Java Message Service (JMS) queues and topics.
The Dizzyworld system architects have decided to explore the JMS services by configuring a
JMS server, a JMS module with JMS queue, and JMS topic resources, and by deploying a simple
messaging.war application to post messages to the queue and the topic.
Note: For Lab07-1

setup_solution Creates a JMS server and module using the WLST scripts and deploys
messaging.war to dizzy1 using WLST
A JMS server implements the JMS infrastructure on a WebLogic Server. Destinations

(queues or topics) are targeted to a WebLogic server when the JMS server is targeted to
the WebLogic server.
In this exercise, you configure a JMS server dizzyworldJMSServer, a queue

dizzyworldQueue, and a topic dizzyworldTopic. You then post messages to the
queue and topic, and monitor them in the Administration Console. For reference, see the
following figure.
Currently, you do not have any consumers; you simply post the messages and get familiar
with monitoring the message statistics in the Administration Console.

Specifications
Dizzyworld Domain with JMS Services

Basic Instructions
ant setup_exercise
2. Configure a JMS server with the following specifications:
Name: dizzyworldJMSServer
Persistent Store: (none)
3. Configure a JMS module, and add a queue and topic to the JMS module, according to the
following specifications:
JMS Module
Name: dizzyworldModule
Descriptor File Name: dizzyworldModule
Target: dizzy1
Subdeployment
Subdeployment Name: dizzy1SubDeployment
Targets: dizzyworldJMSServer
Queue
Name: dizzyworldQueue
JNDI Name: dizzyworldQueue
Template: None
Target: dizzyworldJMSServer
Topic
Name: dizzyworldTopic
JNDI Name: dizzyworldTopic
Template: None
Target: dizzyworldJMSServer
4. Deploy the messaging.war Web application, which allows you to post messages to the
queue or the topic.
5. Verify that the Web application is deployed correctly by navigating to
http://localhost:7003/messaging and posting messages to either the queue or the topic
using the deployed Web application.

Practice 7-1: Configuring the JMS Servers and Destinations
In this practice, you configure the JMS server and JMS module, and add a queue and
topic to the module.

ant setup_exercise
Configure a JMS server.
2.1 Ensure that HRDatabase, AdminServer, and dizzy1 are running.
2.2 Navigate to dizzyworld > Services > Messaging > JMS Servers. Lock the console.
2.3 Click New under the JMS Servers table and specify the following properties:
Name: dizzyworldJMSServer
Persistent Store: (none)
2.4 Click Next and target the JMS server to the dizzy1 Managed Server. Click Finish.
Configure a JMS module, and add a queue and topic to the JMS module.
3.1 Navigate to dizzyworld > Services > Messaging > JMS Modules. Lock the console, if
necessary.
3.2 Click New under the JMS Modules table and specify the following properties:
Name: dizzyworldModule
Descriptor File Name: dizzyworldModule
3.3 Click Next and target the module to the dizzy1 Managed Server. Click Next and select
the following:
Would you like to add resources to this JMS system module?

3.4 Click Finish.
3.5 On the Settings for dizzyworldModule page, click the Subdeployments tab. Under
the Subdeployments table, click New to create a subdeployment with the following
specifications:
Subdeployment Name: dizzy1SubDeployment
Click Next.
3.6 On the Targets page, select dizzyworldJMSServer as the target under the JMS
Servers table. Click Finish.

(continued)
3.7 Click the Configuration tab.
3.8 On the Settings for dizzyworldModule page, under the Summary of Resources
table, click New to configure a new JMS queue for the JMS module.
3.9 On the Create a New JMS System Module Resource page, under Choose the type of
resource you want to create, select Queue.
3.10 Click Next.
3.11 In JMS Destination Properties, specify the following parameters:
Name: dizzyworldQueue
JNDI Name: dizzyworldQueue
Template: None
3.12 Click Next.
3.13 Select dizzy1SubDeployment from the subdeployments list. Click Finish.
3.14 On the Settings for dizzyworldModule page, under the Summary of Resources
table, click New to configure a new JMS topic for the JMS module.
3.15 On the Create a New JMS System Module Resource page, under Choose the type of
resource you want to create, select Topic.
3.16 Click Next.
3.17 In JMS Destination Properties, specify the following parameters:
Name: dizzyworldTopic
JNDI Name: dizzyworldTopic
Template: None
3.18 Click Next.
3.19 Select dizzy1SubDeployment from the subdeployments list. Click Finish.
3.20 Activate the changes.
You should be able to see the JNDI entries, called dizzyworldQueue and
dizzyworldTopic, on the dizzy1 Managed Server.
Deploy the Web application messaging.war, which allows you to post messages to the
queue or topic.
4.1 Navigate to the <LAB_HOME>/exercise directory, locate the messaging.war file, and
4.3 Select Install, navigate to <WORK_HOME>/applications, and select
messaging.war. Click Next, accept all the defaults, and click Next again. Target the
application to dizzy1. Click Next and accept all the defaults. Click Finish (when
possible).

(continued)
4.5 Start the application by selecting the check box against the application name under the
Deployments table. Click Start and select Servicing all requests.
Verify that the Web application is deployed correctly.
5.1 If not already open, open a Web browser and navigate to
http://localhost:7003/messaging.
5.2 Using the application, post several messages to the standard queue and to the topic, not
to the distributed queue.
5.3 Use the Administration Console to view the number of messages that have been posted
into each of the destinations. Navigate to dizzyworld > Services > Messaging > JMS
Modules. In the JMS Modules table, click dizzyworldModule. On the Summary of
Resources page, click dizzyworldQueue, and then click the Monitoring tab.
Customize this table to show the Messages Total column. The Messages Total column
shows you the number of messages that have been sent to dizzyworldQueue. Repeat
these steps to view the number to messages sent to dizzyworldTopic. (Observe the
Messages total count.)
HRDatabase, AdminServer, and dizzy1 are running. Open a command prompt using
ant setup_solution

Data Sources and Transactions

(20 minutes)
After completing this practice, you should be able to monitor transactions in the Administration
Console.
Dizzyworld is dedicated to helping its employees save for their retirement. It offers
employees a money market savings account and a 401K retirement account. Employees
are allowed to freely transfer money between these two accounts.
Note: For Lab08-1

setup_exercise Creates a data source using the WLST script
setup_solution Deploys retirement.war to dizzy1 using WLST
Transactions are a group of steps that have to operate as a single step. Either all
operations succeed or the state of the system rolls back as if none of the steps occurred.
Oracle WebLogic Server allows administrators to monitor transactions through the
Administration Console.


Basic Instructions
ant setup_exercise
2. Make sure that you have configured the dizzyworldDS data source in the previous
Configuring Data Sources lab.
3. Deploy the retirement.war Web application.
4. Test the deployed retirement.war Web application by accessing the application and
use the application to make the following transfers:
Michael Fullertransfer from 401K to savings1500
Chris Montgomerytransfer from savings to 401K15000
Thomas Bernardtransfer from savings to 401K1520
Katherine Fredericktransfer from savings to 401K8900
Note: Some of the people listed above may have insufficient funds, which is according to
the design of the application.
After making these transfers, monitor the transactions in the Administration Console and
answer the following questions:
How many transactions were there?
How many transactions were committed?
How many transactions were rolled back?


Practice 8-1: Data Sources and Transactions
In this practice, you monitor transactions using the Administration Console.

ant setup_exercise
Make sure you have configured the dizzyworldDS data source in the previous lab on
Configuring Data Sources.
2.1 Make sure that HRDatabase, AdminServer, and dizzy1 are running.
2.2 To ensure that the dizzyworldDS data source is running on the dizzy1 Managed
Server, navigate to dizzyworld > Services > JDBC > Data Sources. Click
dizzyworldDS under the Data Sources table, and then click the Monitoring tab. To
make sure that the data source is deployed, look for the dizzy1 entry in the Statistics
table.
Deploy the retirement.war Web application.
3.1 Navigate to the <LAB_HOME>/exercise directory, locate the retirement.war file,
and copy it to the <WORK_HOME>/applications directory.
3.2 Deploy the retirement.war Web application that is located in the
<WORK_HOME>/applications directory.
Make sure that you opt to install this deployment as an application, target the application
to dizzy1, and select Copy this application onto every target for me for Source
accessibility on the Optional Settings page.
Note: Remember to activate and start the application.
The retirement application allows employees to transfer money between their 401K
savings plan and a typical money market savings account.
Test the deployed retirement.war Web application.
4.1 Open a Web browser and navigate to http://localhost:7003/retirement.

Practice 8-1: Data Sources and Transactions (continued)
4.2 After the Web application is deployed, use the application to make the following transfers:
Michael Fullertransfer from 401K to savings1500
Chris Montgomerytransfer from savings to 401K15000
Thomas Bernardtransfer from savings to 401K1520
Katherine Fredericktransfer from savings to 401K8900
Note: Some of the people listed above may have insufficient funds, which is according to
the design of the application.
4.3 After making these transfers, monitor the transactions in the Administration Console by
navigating to dizzyworld > Environment > Servers, click dizzy1 under the Servers
table, and then click the Monitoring > JTA tab. Answer the following questions:
How many transactions were there?
How many transactions were committed?
How many transactions were rolled back?

HRDatabase, AdminServer, and dizzy1 are running. Open a command prompt using
ant setup_solution

Managing Users and Groups

(10 minutes)
After completing this practice, you should become familiar with configuring users, passwords,
and groups in the default realm called myrealm.
Dizzyworld has four employees who would need to be authenticated into the Oracle
WebLogic Server environment. Each employee has a different role within the company,
but some belong to common groups. All employees belong to the group employees;
some belong to a group called managers.
Note: For Lab09-1

setup_solution Creates users and groups using the WLST script
Authentication is the who of security. This involves verifying that the individuals are
the entities that they say they are.

Specifications
Figure 5: Secure Access Process

Table 4: Users and Groups
User Password Groups
john weblogic Administrators
joe weblogic employees, managers
ted weblogic employees, managers
mary weblogic employees
albert weblogic employees
Basic Instructions
ant setup_exercise
2. Create the groups employees and managers in the dizzyworld domain according to
Table 4.
3. Create the users for the dizzyworld domain and associate the groups with each user
according to Table 4.
ant setup_solution

Securing Web Applications
(20 minutes)
After completing this exercise, you should be able to get hands-on experience of setting security
on a Web application.
The Dizzyworld department wants to deploy an application that allows employees to
generate absence reports and to request time off. The application also allows managers to
close the office. However, only managers should be allowed to close the office.
Therefore, you need to set security on specific resources in this application, allowing only
users in the managers group to access certain URLs. You configure security directly in
the Administration Console so that only users in this group can make requests on the
URL pattern /managers/*. You use the timeoff.war Web application in this lab.
For reference, see Figure 6.
Note: For Lab09-2

setup_solution Adds role and security policy to timeoff.war using the WLST
script
System administrators usually work with application developers to set security on Web
applications. The developers know what belongs in their Web application and the
structure, and the administrator is familiar with the users defined in the Oracle WebLogic
Server environment.
Specifications
Figure 6: The dizzyworld Domain

Basic Instructions
ant setup_exercise
Note: There is no automated solution set up for this lab, so you will have to walk through
all the steps to complete this lab.
2. Deploy the timeoff.war Web application and configure security settings for the Web
application by selecting the following option while deploying the application:
Custom Roles: Use roles that are defined in the Administration Console; use policies that
are defined in the deployment descriptor.
Create a new role URL pattern for the Web application by specifying the following
properties:
URL Pattern: /managers/*
Name: director
Provider Name: XACMLRoleMapper
3. Start the timeoff Web application.

Configuring Additional Conditions
(15 minutes)
After completing this exercise, you should be able to configure additional security constraint
conditions for a deployed Web application.
Note: For Lab09-3
setup_solution Adds role and security policy to timeoff.war using the WLST script
(You have to edit the script before you run this command as described in readme.txt.)
Interactive roles and policies can be enforced at the domain level (global scope) and/or at the
resource level (for all types of resources such as Web applications, EJBs, JDBC, JNDI, JMS, and
so on.). In this lab, you introduce an additional security constraint stating that managers can close
an office only on a certain day of the month.
Specifications
Figure 7: The dizzyworld Domain

Basic Instructions
ant setup_exercise
2. Add a new role condition for the deployed timeoff.war Web application stating that an
office can be open only on a certain day of the month (between 1 and 31, representing the
calendar day).
3. Test the timeoff Web application.

Configuring SSL
(15 minutes)

Use keytool to generate an identity keystore that contains a private key and a self-signed
public certificate
Configure keystores
Configure secure sockets layer (SSL)
The Dizzyworld department has decided to configure SSL and keystores to ensure secure
communications between a server and the client.
Note: For Lab09-4

setup_solution Configures SSL for dizzy1 using the WLST script
Many applications need the security of communicating over the secure sockets layer
(SSL). This provides secure communications between the server and the client, or
between two servers. In this lab, you configure SSL and the keystores for the dizzy1
Managed Server in the dizzyworld domain.
Table 5: Identity Key and Certificate Design Specifications
Identity Key and Certificate

X.500 Distinguished Name: "CN=localhost, OU=Dizzyworld Web, O=Dizzyworld\,
Inc., C=US"
Private key alias: dwkey
Private key password: dwkeypass
Validity duration: 365 days
Encryption strength: Algorithm (-keyalg): RSA
Size (-keysize): 512-bit
CSR filename: dw_cert_request.pem
Table 6: Identity Keystore Design Specifications
Identity Keystore
Keystore filename dw_identity.jks
Keystore directory $WEBLOGIC_DOMAIN
Keystore password dwstorepass
Keystore type JKS

Table 7: Trust Keystore Design Specifications
Trust Keystore
Keystore filename cacerts
Keystore directory $JAVA_HOME/jre/lib
Keystore password changeit

Basic Instructions
ant setup_exercise
2. Generate a key, a self-signed certificate, and an identity keystore:
Run the Java keytool -genkey command. For example:
keytool genkey v alias dwkey keyalg RSA keysize 512
-dname "CN=localhost, OU=Dizzyworld Web,
O=Dizzyworld\, Inc., C=US"
-keypass dwkeypass
-validity 365
-keystore dw_identity.jks
-storepass dwstorepass
Copy the dw_identity.jks file from <WORK_HOME>/security to the

<WORK_HOME>/domains/dizzyworld directory.
3. Generate a CSR:
Run the Java keytool -certreq utility. For example:

keytool certreq v alias dwkey file dw_cert_request.pem
-keypass dwkeypass storepass dwstorepass
Copy the dw_cert_request.pem file from <WORK_HOME>/security to the

4. Configure the keystores by specifying the following properties from the WebLogic
Administrative Console:
Keystores: Custom Identity and Java Standard Trust

Custom Identity Keystore: dw_identity.jks
Custom Identity Keystore Type: JKS
Custom Identity Keystore Passphrase: dwstorepass
Java Standard Trust Keystore Passphrase: changeit
5. Configure SSL by specifying the following properties:
Identity and Trust Locations: Keystores

Private Key Alias: dwkey
Private Key Passphrase: dwkeypass
6. Test the SSL setup.

Copy the following files from the <LAB_HOME>/exercise directory to the
<WORK_HOME>/domains/dizzyworld directory:
dw_identity.jks (Identity keystore)
dw_cert_request.pem (Identity key)
Note: The private key file and the certificate have been provided to you for
testing.
Make sure that AdminServer and dizzy1 are running
Open a prompt using ./prompt.sh that is located in <STUDENT>/bin

Protecting Against Attacks
(15 minutes)
After completing this exercise, you should be familiar with the WLS features for strengthening
against password attacks.
The Dizzyworld department has decided to ensure protection against attacks by configuring the
User Lockout setting for Oracle WebLogic Server using the Administration Console.
Note: For Lab09-5

setup_solution Configures the User Lockout security settings using the WLST script
In this lab, you strengthen WLS against password guessing. As an administrator, you
monitor User Lockout and decide whether to unlock that user or not.
Basic Instructions
ant setup_exercise
2. Configure User Lockout using the Administration Console by specifying the following
properties:
Lockout Enabled: Selected (if not already selected)
Lockout Threshold: 3
Lockout Duration: 30
3. Verify that the lockout configuration worked by trying to log in to the console with the
incorrect password.
4. Unlock the user john.
Make sure that AdminServer is running

Practice 9-1: Managing Users and Groups
In this practice, you create users, groups, and associate users with groups.

ant setup_exercise
Create groups employees and managers in the dizzyworld domain.

Log in as:
Username: system
Password: weblogic
2.2 Navigate to dizzyworld > Security Realms.
2.3 Under the Realms table in the right-hand pane, click myrealm. Navigate to Users and
Groups > Groups. Under the Groups table, click New to create the employees group,
and then create a managers group.
Create the users for the dizzyworld domain and associate the groups with each user.
3.1 Navigate to Users and Groups > Users. Create users, according to the design
specifications (Table 4).
3.2 Associate the correct groups with each user, according to the design specifications, by
navigating to Users and Groups > Users for the security realm. Click the user name that
you want to update. Click the Groups tab. Refer to the design specifications (Table 4)
and associate the user with the appropriate groups by moving them to the Chosen box.
3.3 Save your changes.
4.1 To set up the solution for this lab, open a command prompt using ./prompt.sh that is
located in the <STUDENT>/bin directory. Change to the <LAB_HOME> directory and
enter:
ant setup_solution

Practice 9-2: Securing Web Applications
In this practice, you deploy and configure security settings for the Web application.

ant setup_exercise
Deploy the timeoff.war Web application and configure security settings for the Web
application.
Log in as:
Username: system
Password: weblogic
2.2 If not already running, start AdminServer and the dizzy1 server.
2.3 Navigate to the <LAB_HOME>/exercise directory, locate the timeoff.war file, and
2.4 Deploy the timeoff.war Web application that is located in the
<WORK_HOME>/applications directory by navigating to dizzyworld >
Deployments. Lock the console.
2.5 Select Install, navigate to <WORK_HOME>/applications, and select the
timeoff.war file. Click Next and accept the defaults. Target the application to the
dizzy1 Managed Server and click Next again. On the Optional Settings page, under
the Security header, select the following:
Custom Roles: Use roles that are defined in the Administration Console; use
policies that are defined in the deployment descriptor.
2.6 Under the Source Accessibility header, select the following:
Copy this application onto every target for me.

2.7 Click Finish and Activate your changes.
2.8 Navigate to dizzyworld > Deployments.
2.9 Click timeoff under the Deployments table.
Note: Do not start the timeoff application yet.

Practice 9-2: Securing Web Applications (continued)
2.10 Navigate to Security > URL Patterns > Roles. Click New in the Standalone Web
Application URL Patterns table and specify the following properties:
URL Pattern: /managers/*

Name: director
Provider Name: XACMLRoleMapper
Click OK. In the Standalone Web Application URL Patterns Scoped Roles table, you
should now see the URL pattern created and assigned to the director role.
2.11 Click director and click Add Conditions. Choose Group from Predicate List and click
Next.
2.12 On the next screen, enter managers as the Group Argument Name. Click Add, and then
Click Finish. Click Save.
Start the timeoff Web application.
3.1 Navigate to dizzyworld > Deployments. Under the Deployments table, it should say
Prepared under the column named State for the timeoff Web application. Select the
check box next to the timeoff application, and then click Start > Servicing all
requests. Click Yes when prompted.
3.2 Verify that the application is successfully deployed by opening a browser and navigating
to http://localhost:7003/timeoff.
Try closing the office by clicking Close An Office. Log on as different users created in
the previous lab. For example, you should find that mary is denied access, but joe is
granted access. The lab ends when the user is able to see the next page after login.
Note: To log on as a new user, close your browser to get rid of the previous cached
authentication information. In Firefox, this includes ALL browsers. Also, make sure that
you explicitly clear the browser cache.

Practice 9-3: Configuring Additional Conditions
In this practice, you add a new role condition for the deployed Web application.

ant setup_exercise
Add a new role condition for the deployed timeoff.war Web application.
Log in as:
Username: system
Password: weblogic
2.3 Click the timeoff Web application in the Deployments table and navigate to Security >
URL Patterns > Roles. Click director on the Standalone Web Application URL Pattern
Scoped Roles page. Click Add Conditions on the Edit a Standalone Web Application
URL Pattern Scoped Role page and from Predicate List, select Access occurs on the
specified day of the month. Click Next.
2.4 Specify the following properties on the Edit Arguments page:
The day of the month: Todays date

GMT offset: Add the value appropriate to your time zone
Note: Enter GMT+hh:mm for the time ahead of GMT or GMT-hh:mm for the time
behind GMT. For example, Eastern Standard Time in the USA would be GMT-5:00.
2.5 Click Finish.
2.6 To apply both the new condition that you created and the old condition that was created
in the previous lab, select both the conditions shown on the Edit a Standalone Web
Application URL Pattern Scoped Role page and choose the value And from the list. Save
your changes.
Note: You should see the message, Changes saved successfully, displayed on the
page after you save the conditions.

Practice 9-3: Configuring Additional Conditions (continued)
Test the timeoff Web application.
3.1 Change the date on your computers system clock to a couple of days in the future.
(Select Applications > System Settings > Date and Time.)
Note: Root password is oracle.
3.2 Open a Web browser and navigate to http://localhost:7003/timeoff.
3.3 Click Close An Office. Log in as a manager; for example, log in as joe, who is a user
(manager) configured in the previous labs. The policy allows access only on todays date,
so Joe will not be allowed to access the Close An Office part of the Web application.
3.4 Set the system date back when you have finished.

Practice 9-4: Configuring SSL
In this practice, you perform all the steps to configure SSL in an Oracle WebLogic Server
environment.

ant setup_exercise
Generate a key, a self-signed certificate, and an identity keystore.

2.1 Navigate to the <WORK_HOME> directory and create a new directory by name security.
2.2 Open a prompt (if not already open) using ./prompt.sh in <STUDENT>/bin.
2.3 Change to the <WORK_HOME>/security directory.
2.4 Run the Java keytool -genkey command.
Use the information in Table 5 and Table 6 to supply the keytool command arguments,
for example:
keytool genkey v alias dwkey keyalg RSA keysize 512
-dname "CN=localhost, OU=Dizzyworld Web,
O=Dizzyworld\, Inc., C=US"
-keypass dwkeypass
-validity 365
-storepass dwstorepass
The key and certificate are generated and stored in a keystore.
Copy the dw_identity.jks file from <WORK_HOME>/security to the

(Alternative to using keytool -genkey): To save time, you may copy the
dw_identity.jks file from the <LAB_HOME>/exercise directory to the
Generate a Certificate Signing Request (CSR).
3.1 Open a prompt (if not already open) using ./prompt.sh in <STUDENT>/bin.
3.2 Change to the <WORK_HOME>/security directory.

Practice 9-4: Configuring SSL (continued)
3.3 Run the Java keytool -certreq utility. Use the information in Table 5 and Table 6 to
supply the keytool command arguments, for example:
keytool certreq v alias dwkey file dw_cert_request.pem
-keypass dwkeypass storepass dwstorepass
A CSR is generated.
Copy the dw_cert_request.pem file from <WORK_HOME>/security to the
(Alternative to using keytool -certreq): To save time, you may copy the
dw_cert_request.pem file from the <LAB_HOME>/exercise directory to the
Configure the keystores.
4.1 Make sure that AdminServer and dizzy1 are running.
Log in as:
Username: system
Password: weblogic
Keystores. Lock the console.
4.4 On the Keystores page, specify the following properties:
Keystores: Custom Identity and Java Standard Trust

Custom Identity Keystore: dw_identity.jks
Custom Identity Keystore Type: JKS
Custom Identity Keystore Passphrase: dwstorepass
Java Standard Trust Keystore Passphrase: changeit
4.5 Save the changes.
Configure SSL.
5.1 Navigate to dizzyworld > Environment > Servers > dizzy1 > Configuration > SSL.
5.2 On the SSL page, specify the following properties:
Identity and Trust Locations: Keystores

Private Key Alias: dwkey
Private Key Passphrase: dwkeypass
5.3 Save the changes.
General. Verify that the check box next to SSL Listen Port Enabled is selected and
that the SSL Listen Port is 7004.

Practice 9-4: Configuring SSL (continued)
5.5 Activate the changes and restart the dizzy1 Managed Server.
Test the SSL setup.
6.1 Open a browser window and navigate to https://localhost:7004/benefits.
You should see a warning, The certificate issued by your server is not signed by a
trusted authority, because in this lab, you use a self-signed digital certificate. Accept the
certificate (the description may vary from one browser to another). The benefits
application should then open up in your browser.
7.1 To set up the solution, copy the following files from the <LAB_HOME>/exercise
directory to the <WORK_HOME>/domains/dizzyworld directory:
dw_identity.jks (Identity keystore)
dw_cert_request.pem (Identity key)
Note: The private key file and the certificate have been provided to you for testing.
7.2 Make sure that AdminServer and dizzy1 are running. Open a command prompt using
ant setup_solution
After running the setup_solution script, restart the dizzy1 Managed Server, and
then navigate to https://localhost:7004/benefits to view the results.

Practice 9-5: Protecting Against Attacks
In this practice, you configure User Lockout using the Administration Console.

ant setup_exercise
Configure user lockout using the Administration Console.

2.1 Make sure that AdminServer is running.
2.2 Navigate to dizzyworld > Security Realms > myrealm > Configuration > User
Lockout. Lock the console.
2.3 Specify the following properties on the User Lockout page:
Lockout Enabled: Selected (if not already selected)
Lockout Threshold: 3
Lockout Duration: 30
2.4 Save and Activate your changes.
2.5 For the changes to take effect, a server restart is required. Shut down dizzy1 first if it is
still running, followed by AdminServer. Then start AdminServer.
Note: dizzy1 is not required to be running to complete this lab.

Log in as:
Username: system
Password: weblogic
2.7 Navigate to dizzyworld > Environment > Servers > AdminServer > Monitoring >
Security. Lock the console.
Note: You will need to keep the console open throughout the following steps.
Verify that the lockout configuration worked by trying to log in to the console with the
incorrect password.
3.1 Open another Web browser and navigate to http://localhost:7001/console.
Enter a wrong password for the user john at least three times. In the stdout of
AdminServer, you should see the message that the user has been locked out
immediately after the third incorrect login attempt.

Practice 9-5: Protecting Against Attacks (continued)
3.2 In addition, if you refresh the first Administration Console screen that you opened in step
2, you should be able to see that the User Lockout Total Count box is incremented by
one.
3.3 If you now enter the correct password for the user john in the second Administration
Console that you opened in step 3, you should not be able to access the Administration
Console.
Unlock the user john.
4.1 In your first Admin Console window, click dizzyworld, and then in the right pane,
navigate to Security > Unlock User.
Enter the username of the account that you would like to unlock, which is john.
4.2 Click Save.
4.3 Verify that the user is unlocked by trying to log in to the second Administration Console
session with the correct password.
5.1 Set up the solution for this lab, if you are unable to complete it. Ensure that
AdminServer is running. Open a command prompt using ./prompt.sh that is located
in the <STUDENT>/bin directory. Change to the <LAB_HOME> directory and enter:
ant setup_solution
Note: If you run the ant setup_solution script, only a part of the lab is completed,
which is specifying the properties on the User Lockout page (step 2.3). The remaining lab
has to be completed manually.

Using a Deployment Plan

(20 minutes)
Create deployment plans
Deploy enterprise applications along with the deployment plan
Describe the directory structure of an exploded enterprise application for its successful
deployment
Sometimes, it is necessary to deploy applications multiple times and in different types of

environments. Instead of having to configure the deployment information each time, it would be
easier to package that information with the application. Therefore, the user creates the
deployment plans for an enterprise application and creates a proper directory structure for the
successful deployment of enterprise applications.
Note: For Lab10-1

setup_exercise Creates a data source, JMS server, and JMS module using the WLST
scripts
The user manually creates an initial deployment plan for an enterprise application that resides
outside the application archive and configures an application for deployment to a specific Oracle
WebLogic Server environment. The deployment plan helps the administrator to easily modify an
applications WebLogic Server configuration for deployment into multiple, differing WebLogic
Server environments without modifying the deployment descriptor files that are included in the
application archive. The user creates a proper directory structure for the successful deployment of
enterprise applications that are packaged with the deployment plan. See Figure 8.
Specifications
Figure 8: Directory Structure
Root
Application directory
app
plan

Basic Instructions
ant setup_exercise
2. Copy the HRApp application from the <LAB_HOME>\exercise directory to the
<LAB_HOME>\work\app directory.
3. Use weblogic.PlanGenerator to create a plan entitled plan.xml for the HRApp
application. Open a command prompt using ./prompt.sh under <STUDENT>/bin and
change to the <LAB_HOME> directory. Execute the following command:
java weblogic.PlanGenerator all root work
Navigate to the <LAB_HOME>/work/plan directory and open

plan.xml using a text editor.
Set /EEOAPP as a value for
<variable><name>WeblogicWebApp_ContextRoots_xxxxxxxxx
xxxxx.
Remove the attribute xsi:nil="true" from the <value> tag, so that it
looks like the following:
<variable>
<name>WeblogicWebApp_ContextRoots_
xxxxxxxxxxxxxx </name>
<value>/EEOAPP</value>
</variable>
In the area <variable-
assignment><name>WeblogicWebApp_ContextRoots_
xxxxxxxxxxxxxx
add the following line: <operation>replace</operation>,
so that it looks like the following:
<variable-assignment>
<name>WeblogicWebApp_ContextRoots_ xxxxxxxxxxxxxx
</name>
<xpath>/weblogic-web-app/context-root</xpath>
<operation>replace</operation>
</variable-assignment>
4. Redeploy the application with the plan in the Administration Console.
5. View the deployed application.

Production Redeployment
(20 minutes)
After completing this exercise, you should be able to describe:

Production Redeployment
The importance of versioning the enterprise applications that are deployed to Oracle
WebLogic Server
The importance and advantages in using Production Redeployment
The user gets to deploy the first version of an application and view the application. Thereafter, the
user redeploys the second version of the same application, which is modified a bit, and views this
version of the application. The old client, if not yet finished with using the application, still has
access to the first version of the application, whereas the new clients get connected to the second
version of the application. When the first version of the application is no longer in use by a client,
the state of the first version of the application is retired and that version of the application
becomes unavailable.
Note: For Lab10-2

setup_exercise Creates a data source, JMS server, and JMS module using the WLST
scripts
Using the Production Redeployment strategy, users can experience how to use WebLogic Server
to redeploy a new version of a production application without interrupting the availability of the
application to new client requests. Thus, the new clients get connected to the new version of the
application, and the previous version of the application, which is still in use by the older clients,
gets retired after the client disconnects.
Figure 9 illustrates these concepts.
Specifications
WebLogic Server
New clients
Retiring Application Version Active Application

CompanyStoreAdmin Version
Existing clients (Version1) companyStoreAdmin
(Version2)
Figure 9: Production Redeployment

Basic Instructions
ant setup_exercise
2. Delete all the other companyStoreAdmin applications deployed to AdminServer.
3. Create a deploy1 and deploy2 directory in the <LAB_HOME> directory. Copy the
companyStoreAdmin application from the <LAB_HOME>/exercise/deployMFv1
directory to the <LAB_HOME>/deploy1 directory. Also copy the companyStoreAdmin
application from <LAB_HOME>/exercise/deployMFv2 to the <LAB_HOME>/deploy2
directory.
4. Deploy the companyStoreAdmin application that is stored in the
<LAB_HOME>/deploy1 directory such that the version number for that application is v1.
5. View the deployed application, v1.
6. The State of the deployed application v1 should be Active.
7. Deploy the companyStoreAdmin application from the <LAB_HOME>/deploy2
directory such that the version number for that application is v2.
8. After you redeploy the application as v2, the State of the application v1 becomes Retired
and the State of the newly deployed application v2 is Active.
9. View the deployed application v2 for changes in the background color of the heading that
should now be green and the text displayed is v2. All the new clients get connected to v2
of the application. When v1 of the application is no longer in use by a client, the State of
the application becomes Retired.

Practice 10-1: Using a Deployment Plan
In this practice, you create a deployment plan, and then deploy an application using this
plan.

ant setup_exercise
1.4 Start AdminServer and dizzy1 if they are not already running.
Note: Start dizzy1 from <WORK_HOME>/domains/dizzyworld/bin.

1.5 If it is not already open, open a Web browser and navigate to
http://localhost:7001/console. Log in as:
Username: system
Password: weblogic
Deploy the HRApp application from the <LAB_HOME>/exercise directory to the
<LAB_HOME>/work/app directory. Deploy the HRApp application.
2.1 In the Administration Console, navigate to dizzyworld > Deployments. Lock the
console, if necessary.
2.2 Click Install in the right pane and browse to the <LAB_HOME>/exercise directory.
Select HRApp and click Next.
2.3 On the Install Application Assistant page, select Install this deployment as an
application and click Next.
2.4 Target the application to dizzy1. Click Next.
2.5 On the Optional Settings page, enter HRApp as the name and select Copy this
application onto every target for me under the Source Accessibility section. Click
Finish and Activate the changes.
2.6 Navigate to dizzyworld > Deployments and select the check box for the HRApp
application. Click Start > Servicing all Requests.
2.7 Point your browser to http://localhost:7003/HRApp.
2.8 Create a work directory in the <LAB_HOME> directory, and then create a directory app in
the work directory. Copy the HRApp application from the <LAB_HOME>/exercise
directory to the <LAB_HOME>/work/app directory.

Practice 10-1: Using a Deployment Plan (continued)
Use weblogic.PlanGenerator to create a plan plan.xml for the HRApp application.
java weblogic.PlanGenerator all root work
PlanGenerator is a utility for creating a deployment plan template based on the
standard descriptors included in an application. The resulting plan (-plan option) will
describe the application structure, identify all deployment descriptors, and will export a
subset of the applications configurable properties.
By default, the plan exports only application dependencies. This can be overridden with
any one of the following:
-declarations: Export resources defined by the application
-configurables: Export non-resource-oriented configurable properties
-dynamics: Export properties that may be changed in a running application
-all: Export all changeable properties
-none: Export no properties
3.4 Navigate to the <LAB_HOME>/work/plan directory and open plan.xml using a text
editor.
3.5 Set /EEOAPP as a value for
<variable><name>WeblogicWebApp_ContextRoots_xxxxxxxxx</name></variable>.
Note: This is around Line 26 in the code.
3.6 Remove the attribute xsi:nil="true" from the <value> tag, so that it appears thus:
<variable>
<name>WeblogicWebApp_ContextRoots_xxxxxxxxxx</name>
<value>/EEOAPP</value>
</variable>
3.7 In the following area:
<name>WeblogicWebApp_ContextRoots_xxxxxxxxxxxx </name>
(Note: It is around line 137.)
Add the following line:
So that it appears thus:

<name> WeblogicWebApp_ContextRoots_xxxxxxxxxxxx </name>
<xpath>/weblogic-web-app/context-root</xpath>
</variable-assignment>

Practice 10-1: Using a Deployment Plan (continued)
Redeploy the application with the plan in the Administration Console.
console.
4.2 Select HRApp and click Update.
4.3 Click Change Path next to Deployment Plan Path.
4.4 Select <LAB_HOME>/work/plan/plan.xml.
Select plan.xml and click Next.
4.5 Select Redeploy this application using the following deployment files (if not
selected). Click Next, and then click Finish. Click Activate changes.
View the deployed application.
5.1 Point your browser to http://localhost:7003/EEOAPP.

Practice 10-2: Production Redeployment
In this practice, you configure production redeployment for two versions of an
application.

ant setup_exercise
Delete all the other applications deployed to AdminServer.

2.1 If it is not already running, start the Administration Server for the Dizzyworld domain.
2.2 If it is not already open, open a Web browser and navigate to
http://localhost:7001/console.
Log in as:
Username: system
Password: weblogic
2.3 Click Lock & Edit in Change Center in the left pane of the Administration Console.
2.4 Note: If you are redoing this lab, perform step 2.4 and 2.5 otherwise skip to step 3.1.
Click Deployments under the dizzyworld domain structure in the left pane of the
Administration Console. In the right pane on the Summary of Deployments page, select
any existing companyStoreAdmin application check boxes under the Deployment table
and stop the applications by clicking Stop > Force Stop Now. Click Yes when prompted
to confirm that the selected deployments are to be immediately stopped. On the
Summary of Deployments page, select all the existing companyStoreAdmin application
check boxes under the Deployment table again and delete them by clicking Delete. Click
Yes when prompted.
2.5 Click Activate Changes in Change Center in the left pane of the Administration Console.
Copy the companyStoreAdmin application.
3.1 Create the deploy1 and deploy2 directories in the <LAB_HOME> directory. Copy the
companyStoreAdmin application from the <LAB_HOME>/exercise/deployMFv1
directory to the <LAB_HOME>/deploy1 directory. Also copy the companyStoreAdmin
application from <LAB_HOME>/exercise/deployMFv2 to the <LAB_HOME>/deploy2
directory.
Deploy the companyStoreAdmin application stored in the <LAB_HOME>/deploy1 directory
such that the version number for that application is v1.

Practice 10-2: Production Redeployment (continued)
4.1 Open the command prompt using prompt.sh and navigate to the
<LAB_HOME>/deploy1 directory. Enter the following to deploy the application:
java weblogic.Deployer -adminurl t3://localhost:7001 -user system

-password weblogic -deploy -name companyStoreAdmin source
companyStoreAdmin.ear -targets AdminServer -stage -appversion v1
View the deployed application v1.
5.1 Point your browser to http://localhost:7001/csAdministration.
The background color of the heading should be navy.
Note: Do not close this browser because it is required to show further results.
State of the deployed application v1 (version1) should be Active.
6.1 Click Deployments under the dizzyworld domain structure in the left pane of the
Administration Console. In the right pane on the Summary of Deployments page, check
to see whether the State of the companyStoreAdmin (v1) application is Active.
(Note: You may see a warning message under the Health column.)
Deploy the companyStoreAdmin application stored in the <LAB_HOME>/deploy2 directory
such that the version number for that application is v2.
7.1 In the command prompt, navigate to the <LAB_HOME>/deploy2 directory. Enter the
following to deploy the companyStoreAdmin.ear application:
java weblogic.Deployer -adminurl t3://localhost:7001 -user system

-password weblogic -redeploy -name companyStoreAdmin source
companyStoreAdmin.ear -appversion v2
After redeploying the application as v2, the State of application v1 becomes Retired
and the State of the newly deployed application v2 (version2) is Active.
8.1 Click Deployments under the dizzyworld domain structure in the left pane of the
Administration Console. In the right pane on the Summary of Deployments page, check
to see whether the State of the: companyStoreAdmin(v1)application is Retired and
the CompanyStoreAdmin (v2) application is Active.(Note: You may see a warning
message under the Health column.)
8.2 Display the browser window that you opened in step 5.1.
Note: The background color of the heading should be navy.

View the deployed application v2 for changes in the background color of the table.

Practice 10-2: Production Redeployment (continued)
9.1 Open up a new browser window and point your browser to
http://localhost:7001/csAdministration.
Note: The background color of the heading should be green.
You may need to reload to see the change due to caching in some browsers.
All the new clients get connected to v2 of the application. When v1 of the application is
no longer in use by a client, the State of the application becomes Retired. (It may take a
while for the state to change.)

There are no practices for this lesson.

Creating a Basic Cluster

(15 minutes)
Create a cluster of Managed Servers
Start clustered servers
The Dizzyworld system architects determined that the Dizzyworld applications would benefit
from a highly available environment, which load-balances requests to different servers. This
would make the Dizzyworld applications more reliable to employees and customers in case of
server failure. It would also allow for more processing capabilities when application traffic is
heavier than usual.
In this lab, you create a cluster of three servers, dizzy1, dizzy2, and dizzy3. This cluster
will eventually host your Dizzyworld applications but for now, you want to confirm that they start
properly and join the cluster.
Note: For Lab12-1
setup_solution Creates a cluster using the WLST script
dizzyworld
dizzyworldCluster
dizzyMachine1 dizzyMachine2
dizzy1 dizzy2 dizzy3
Figure 10: Dizzyworld Cluster Architecture

Basic Instructions
ant setup_exercise
2. If they are running, shut down the dizzy1, dizzy2, and dizzy3 Managed Servers. If it
is not open, start a Web browser and navigate to http://localhost:7001/console. Log in as:
Username: system
Password: weblogic
Create a new cluster with the following properties:
Name: dizzyworldCluster
Multicast Address: 239.192.0.0 (default)
Multicast Port: For example, a unique number (Check with your instructor.)
Servers: dizzy1, dizzy2, dizzy3
3. Start dizzy1, dizzy2, and dizzy3. Watch each server as it tries to synchronize with
other servers in the cluster and as it finally joins the cluster. During startup of the servers,
if prompted, enter the following:
Username: system
Password: weblogic
./prompt.sh that is located in <STUDENT>/bin directory. Change to the <LAB_HOME>
ant setup_solution

Configuring Proxy Servers
(60 minutes)
Set up HTTPClusterServlet in a WebLogic Server to proxy requests to a cluster
Set up Apache with the proxy plug-in to proxy requests to a cluster
The Dizzyworld architects have checked your current cluster configuration and determined that to
take full advantage of the cluster, you need a proxy server in front of the cluster to proxy requests
from the clients to the cluster. However, they have not decided whether they want to use
HTTPClusterServlet within a WebLogic Server to proxy the requests or whether they want
to use your external Apache Web server.
Note: For Lab12-2

setup_exercise Creates a cluster using the WLST script, deploys browsestore.war to
a cluster using WLST
setup_solution Using the WLST script, creates a cluster, proxyServer; using WLST,
deploys browsestore.war to a cluster and proxyApp.war to proxyServer
You have created your dizzyworldCluster but you still have not finished setting up the
environment, so the application requests are sent to different servers in the cluster. In this lab, you
create two proxy servers: one using HTTPClusterServlet in a new WebLogic Server called
proxyServer and the other as a plug-in for your Apache Web server.

Specifications
Figure 11 presents the cluster with the HTTPClusterServlet proxy architecture.
dizzyworld
proxyServer (with
HTTPClusterServle
t)
dizzyworldCluster
Figure 11: HTTPClusterServlet Proxy Architecture

Figure 12 presents the cluster with the Web server plug-in proxy architecture.
Apache Web Server
(with proxy plug-in)
dizzyworld
dizzyworldCluster
Figure 12: Web Server Plug-In Proxy Architecture

Basic Instructions
ant setup_exercise
2. Create the WebLogic proxy server with the following properties:
Server Name: proxyServer
Server Listen Address: localhost
Standalone Server: True
Start the proxy server.

3. Configure the HTTPClusterServlet in <LAB_HOME>/exercise/proxyApp/WEB-
INF/web.xml. Add the <init-param> element that tells the servlet what servers are in
the cluster. Add the <servlet-mapping> elements that map HTTPClusterServlet
to any request for JSPs, HTML, and HTM pages plus anything that is not recognized.
4. Using <LAB_HOME>/exercise/proxyApp/WEB-INF/weblogic.xml, set the proxy
application as the default Web application for the proxy server.
5. Package the proxy application into proxyApp.war and copy it to
<WORK_HOME>/applications. Deploy proxyApp.war to proxyServer.
6. Open a Web browser and navigate to the browsestore application on the proxy server
at http://localhost:7009/browsestore.
Test the proxy server by browsing the application and checking the server console
windows to see which server is handling the request. You should see different servers
handling each request.
7. Shut down AdminServer, dizzy1, dizzy2, dizzy3, and proxyServer.
Note: Make sure that no other Web server is running on port 80.
Customize the installation by opening <APACHE_HOME>/conf/httpd.conf and adding

the following properties in the appropriate sections:
Listen 127.0.0.1:80
ServerAdmin admin@dizzyworld.com
ServerName wls.dizzyworld.com:80
Start Apache by navigating to <APACHE_HOME>/bin and entering:
apachectl start
Note: To stop Apache, enter apachectl stop.
Verify that Apache has started by opening a browser window and navigating to
http://localhost. You should see the Apache test page.

8. Implement the proxy plug-in for the Apache Web server. Copy the mod_wl_22.so file
from <LAB_HOME>/exercise/linux to <APACHE_HOME>/modules. Modify the
httpd.conf file located in <APACHE_HOME>/conf to load mod_wl_22.so and add the
module-specific configuration.
<IfModule mod_weblogic.c>
WebLogicCluster 127.0.0.1:7003,127.0.0.1:7005,127.0.0.1:7007
MatchExpression /*
</IfModule>
<Location /weblogic>
SetHandler weblogic-handler
DebugConfigInfo ON
PathTrim /weblogic
</Location>
Restart the Apache Web server, AdminServer, dizzy1, dizzy2, and dizzy3.
9. Test the Apache Web server by opening a Web browser and navigating to the
browsestore application on the proxy server at http://localhost/browsestore.
Browse the application and check the server consoles to see which servers are handling
the requests.
ant setup_solution
This does not set up the Apache server.

Note: The three Managed Servers (dizzy1, dizzy2, and dizzy3), AdminServer, and
HRdatabase have to be started before running the ant setup_solution script.
Although the ant setup_solution script creates proxyServer, deploys the proxy
application (Proxyapp.war) to the proxyServer, it does not start it. You have to
manually start the proxyServer.

Practice 12-1: Creating a Basic Cluster
In this practice, you create and start a cluster.

ant setup_exercise
Create a cluster.
2.1 If they are already running, shut down dizzy1, dizzy2, and dizzy3 Managed Servers.
2.2 If it is not already open, start a Web browser and navigate to
Username: system
Password: weblogic
2.3 Navigate to dizzyworld > Environment > Clusters. Lock the console, if necessary.
2.4 Create a new cluster with the following properties:
Name: dizzyworldCluster
Messaging Mode: Multicast
Multicast Port: For example, 7011 (Check with your instructor.)
Each student must use a unique port number between the range 7011 and 7031.
Click OK.
2.5 Return to dizzyworldCluster and click the Configuration > Servers tab.
2.6 Add the existing servers dizzy1, dizzy2, and dizzy3 to the cluster.
2.8 Navigate to dizzyworld > Environment > Servers and view the list of servers. Note
that dizzy1, dizzy2, and dizzy3 are now part of dizzyworldCluster.
Start the clustered servers.
3.1 Using the previously opened prompt, navigate to
<WORK_HOME>/domains/dizzyworld/bin.
3.2 Start the dizzy1 server by entering the following in the prompt:
xterm T dizzy1 e ./startManagedWebLogic.sh dizzy1 &

Practice 12-1: Creating a Basic Cluster (continued)
3.3 If you are prompted, enter the following:
Username: system
Password: weblogic
3.4 Watch the server start up in the prompt window. At some point, you should see it start
listening for cluster announcement and waiting to synchronize with other servers in the
cluster. Because the other servers have not started yet, there is nothing for it to
synchronize with yet.
<Notice> <Cluster> <BEA-000138> <Listening for announcements from
cluster dizzyworldCluster on 239.192.0.0:7011.>
<Notice> <Cluster> <BEA-000133> <Waiting to synchronize with

other running members of dizzyworldCluster.>
3.5 Finally, you should see that it has successfully joined the cluster. You see something like:
<Notice> <Cluster> <BEA-000102> <Joining cluster

dizzyworldCluster on 239.192.0.0:7011>
3.6 Start the dizzy2 server by entering the following in the prompt window:
xterm T dizzy2 e ./startManagedWebLogic.sh dizzy2 &

3.7 If you are prompted, enter the following:
Username: system
Password: weblogic
3.8 Watch the server start up in the prompt window. Because one of the servers in the cluster
has started up, dizzy2 synchronizes with dizzy1 and downloads the cluster JNDI tree.
<Notice> <Cluster> <BEA-000133> <Waiting to synchronize with

other running members of dizzyworldCluster.>
3.9 Finally, start the dizzy3 server, watch it synchronize with the other servers in the cluster,
and finally join the cluster.
enter:
ant setup_solution

Practice 12-2: Configuring Proxy Servers
In this practice, you create and configure a proxy server.

ant setup_exercise
Note: When the exercise is set up, a simple application is deployed to the cluster to test
the proxy servers and the cluster. You will manually deploy a more complex application to
the cluster in a later lab.
You must run this script for this lab to work.

Create the WebLogic proxy server.
http://localhost:7001/console.
Log in as:
Username: system
Password: weblogic
2.2 Navigate to dizzyworld > Environment > Servers. Lock the console, if necessary.
2.3 Create a new server with the following properties:
Server Name: proxyServer

Click Next.
2.4 Click Finish. Activate your changes.
2.5 Open a prompt using ./prompt.sh in <STUDENT>/bin. Navigate to the
<WORK_HOME>/domains/dizzyworld/bin directory.
2.6 Start the proxyServer server by entering the following in the prompt. (Use
system/weblogic as username/password.):
xterm T proxyServer e ./startManagedWebLogic.sh proxyServer &

Configure the HTTPClusterServlet.
3.1 Open <LAB_HOME>/exercise/proxyApp/WEB-INF/web.xml in a text editor.

Practice 12-2: Configuring Proxy Servers (continued)
3.2 In the <servlet> element, add the HTTPClusterServlet.
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-
class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>
3.3 After the <servlet-class> element, add the <init-param> element that tells the
servlet what servers are in the cluster.
<init-param>
<param-name>WebLogicCluster</param-name>
<param-
value>localhost:7003|localhost:7005|localhost:7007</param-value>
</init-param>
3.4 After </servlet>, add the <servlet-mapping> elements that map
HTTPClusterServlet to any request for JSPs, HTML, and HTM pages plus anything
that is not recognized.
<servlet-mapping>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
Alternatively, you could copy and paste the elements from

<LAB_HOME>/exercise/ServletMappings.txt.
3.5 Save and close the file.
Set HTTPClusterServlet as the default Web application on the proxy server.
4.1 Open <LAB_HOME>/exercise/proxyApp/WEB-INF/weblogic.xml in a text editor.
4.2 Within the <weblogic-web-app> element, add the <context-root> element, which
makes this the default Web application for proxyServer.
<context-root>/</context-root>

Package the proxy application and deploy to the proxy server.
5.1 In the prompt window, navigate to <LAB_HOME>/exercise/proxyApp and package
the application using the following command:
jar cf ../proxyApp.war *
5.2 Copy <LAB_HOME>/exercise/proxyApp.war to <WORK_HOME>/applications.
5.3 Deploy <WORK_HOME>/applications/proxyApp.war to the proxyServer. Activate
your changes and start the application.
Test the WebLogic proxy server.
6.1 Open the dizzy1, dizzy2, and dizzy3 server windows and arrange them so that you
can see all three simultaneously.
6.2 Open a Web browser and navigate to the browsestore application that is accessed
through the proxy server at http://localhost:7009/browsestore.
6.3 Check the server windows to see which server received the request.
6.4 Click the Browse Store link. Check the server windows to see which server received the
request.
6.5 Select a category and retrieve the items. Return to the home page, select another
category, and retrieve the items again. Check the server windows to see which server
received the request. You should see different servers handling each set of requests.
Set up the Apache Web server.
7.1 Change to the root user (root/oracle) for the remaining part of Lab12-2. Make sure
that you revert to the oracle user from next lab onwards.
Navigate to <APACHE_HOME>/conf and open httpd.conf in a text editor. This file is
used to customize the Apache settings.
7.2 Find the Listen section and add the following line:
Listen 127.0.0.1:80
Note: Comment out Listen 80.
7.3 Find the ServerAdmin section and add the following line:
ServerAdmin admin@dizzyworld.com
7.4 Find the ServerName section and add the following line:
ServerName wls.dizzyworld.com:80
7.6 In the prompt, navigate to <APACHE_HOME>/bin and enter:
./apachectl start
Note: To stop Apache, enter ./apachectl stop.

7.7 Verify that Apache has started by opening a browser window and navigating to
http://localhost. You should see the Apache test page.
Note: If you do not see the Apache test page, you may need to manually start the
Apache server. Open a command prompt, change the directories to the
<APACHE_HOME>/bin directory, and enter apache.
7.8 Verify that mod_so.c is enabled by navigating to <APACHE_HOME>/bin in the
command prompt and entering ./apachectl l.
mod_so.c should be one of the modules listed.
Implement the proxy plug-in in the Apache Web server.
8.1 Copy the mod_wl_22.so file from the <LAB_HOME>/exercise/linux folder to
<APACHE_HOME>/modules.
8.2 Open the httpd.conf file located in <APACHE_HOME>/conf.
Note: You may want to make a backup copy of this file first.
8.3 You must install the Apache plug-in module. In httpd.conf, find the commented line
that starts with:
# Dynamic Shared Object (DSO) Support.
Add the following line after the commented example:
LoadModule weblogic_module modules/mod_wl_22.so

8.4 In the httpd.conf file, find the line that starts with:
<IfModule log_config_module>
Add the following <IfModule> and <Location> definitions above this line:
<IfModule mod_weblogic.c>
MatchExpression /*
</IfModule>
<Location /weblogic>
SetHandler weblogic-handler
DebugConfigInfo ON
PathTrim /weblogic
</Location>
Save and close. This configures the cluster proxy parameters.
Note: You can also copy and paste this text from
<LAB_HOME>/exercise/httpdconf.txt.

8.5 Verify that the configuration that you just entered is correct by navigating to
<APACHE_HOME>/bin in the command prompt and entering ./apachectl t.
Note: The command should echo Syntax OK. If not, fix the syntax errors and repeat the
process.
8.6 Restart the Apache Web server.
Stop and start the Apache server using the stop and start commands mentioned earlier.
8.7 Start AdminServer.
8.8 Start dizzy1, dizzy2, and dizzy3 using the command line.
Test the Apache Web server as a proxy server.
9.1 After the servers have started, open a Web browser and navigate to the browsestore
application via Apache at http://localhost/browsestore.
9.2 Check the server windows to see which server received the request.
9.3 Click the Browse Store link.
9.4 Select a category and retrieve the items. Return to the home page. Check the server
windows to see which server received the request. You should see different servers
handling each set of requests.
enter:
ant setup_solution
This does not set up the Apache server.

Note: The three Managed Servers (dizzy1, dizzy2, and dizzy3), AdminServer, and
HRdatabase should be started up before running the ant setup_solution script.
Although the ant setup_solution script creates proxyServer, deploys the proxy
application (Proxyapp.war) to the proxyServer, it does not start it. You have to
manually start the proxyServer.

Managing HTTP Session States

(45 minutes)

Set up in-memory session replication
Deploy an application to a cluster
Set up JDBC session replication
Now that you have your cluster set up with a proxy server, you need to deploy an application to
the cluster. The application uses sessions to save shopping cart information. Therefore, to fully
take advantage of the cluster, you need to set up session replication. However, the system
architects are not sure whether they want to use in-memory replication or JDBC replication.
Note: For Lab13-1

setup_exercise Using the WLST script, creates a cluster and proxyServer
setup_solution Adds the session persistence schema to the database using a SQL script,
and using the WLST script, creates a cluster, proxyServer, and replication groups
With the three servers, you create two replication groups. The first, dizzyRepGroup1, will
contain the servers, dizzy1 and dizzy2. The second, dizzyRepGroup2, will contain only
the dizzy3 server. You will also set up a database with the WL_SERVLET_SESSIONS table in
order to back up session information.

Specifications
Figure 13 presents the in-memory replication architecture.
Apache Web Server
(with the proxy plug-in)
dizzyworld
dizzyworldCluster
dizzyRepGroup1 dizzyRepGroup2
Primary Replicate
Session d Session
Figure 13: In-Memory Replication Architecture

Figure 14 presents the JDBC replication architecture.
Apache Web Server
dizzyworldCluster
dizzyRepGroup1 dizzyRepGroup2
Primary
Session
SessionD SessionD SessionD
WL_SERVLET_SESSIONS
Session Backup
Figure 14: JDBC Replication Architecture

Table 8: Replication Groups
Server Replication Group Preferred Secondary Group
dizzy1 dizzyRepGroup1 dizzyRepGroup2

Basic Instructions
ant setup_exercise
2. Create the following replication groups:
Restart dizzy1, dizzy2, and dizzy3.

3. Add the <session-descriptor> group to the
<LAB_HOME>/exercise/ShoppingCart/WEB-INF/weblogic.xml to enable in-
memory replication of sessions for that application.
Note: The <session-descriptor> group requires three elements at a minimum:

<timeout-secs>, <invalidation-interval-secs>, and <persistent-store-
type>.
4. Package the application into ShoppingCart.war. Copy it into
<WORK_HOME>/applications and deploy it to dizzyworldCluster.
5. Test the in-memory session replication by navigating to
http://localhost/ShoppingCart/welcome.jsp.
Go shopping and add some items to your shopping cart. View the shopping cart and
check the dizzy1, dizzy2, and dizzy3 server consoles to see which server is handling
the requests.
Kill the server that is handling the requests, then return to the application and add another
item to the shopping cart. View the shopping cart. All the items should still be in it. Check
the server consoles again to see which server is handling the requests.

6. Create a Data Source with the following properties:
Name: SessionDS
JNDI Name: SessionDS
Database Driver: *PointBases Driver (Type 4) Versions: 4.X, 5.X
Supports Global Transactions
One-Phase Commit
Database Name: HRDatabase
Port: 9092
Password: PBPUBLIC
Targets: dizzyworldCluster
7. Using the PointBase Console that is located at
<WEBLOGIC_HOME>/common/eval/pointbase/tools, log in with the following
properties and create the table that is found in
<LAB_HOME>/exercise/SessionTable.txt
Driver: com.pointbase.jdbc.jdbcUniversalDriver
URL: jdbc:pointbase:server://localhost:9092/HRDatabase
User: PBPUBLIC
Password: PBPUBLIC
8. Modify <LAB_HOME>/exercise/ShoppingCart/WEB-INF/weblogic.xml to store
session information in a database. You will need to change the <persistent-store-
type> element and add the following elements:
<persistent-store-pool>
<persistent-store-table>
9. Package the modified application into ShoppingCart.war, copy it to
<WORK_HOME>/applications, and overwrite the existing application. Update the
application in the Administration Console.
10. Test the application again by adding items to the shopping cart, viewing the server that is
handling the requests, killing the server, adding more items to the shopping cart, and then
viewing the server handling the requests again. You may also want to view the contents of
the WL_SERVLET_SESSIONS table in PointBase to confirm that session information is
being written to the database.
11. (Optional): All the servers in dizzyworldCluster must be running before you set up
the solution for this lab.
Open a command prompt using ./prompt.sh that is located in the <STUDENT>/bin

directory. Change to the <LAB_HOME> directory and enter:
ant setup_solution

Practice 13-1: Managing HTTP Session States
In this practice, you configure and test in-memory session replication and JDBC session
replication.

ant setup_exercise
Create replication groups.

Username: system
Password: weblogic
Cluster. Lock the console, if necessary.
2.3 Set the following properties:
Replication Group: dizzyRepGroup1

Preferred Secondary Group: dizzyRepGroup2
Save your changes.

2.4 Set the following properties for dizzy2 and dizzy3:

2.6 Changing the Replication Group properties requires a server restart. Restart dizzy1,
dizzy2, and dizzy3.
Modify the Shopping Cart application to use in-memory session replication.
3.1 Open <LAB_HOME>/exercise/ShoppingCart/WEB-INF/weblogic.xml in an XML
editor or text editor.

Practice 13-1: Managing HTTP Session States (continued)
3.2 Add the following element:
<timeout-secs>300</timeout-secs>
<invalidation-interval-secs>60</invalidation-interval-secs>
<persistent-store-type>replicated_if_clustered</persistent-
store-type>
Note: This enables in-memory replication for this application if it is deployed to clustered
servers.
Package and deploy the Shopping Cart application to the cluster.
4.1 If it is not already open, open a prompt using prompt.sh in <STUDENT>/bin.
4.2 Navigate to <LAB_HOME>/exercise/ShoppingCart.
4.3 Package the Company Store Web application into a .war file by entering the following in
the prompt:
jar cf ../ShoppingCart.war *
4.4 Move the new ShoppingCart.war file from <LAB_HOME>/exercise to the
<WORK_HOME>/applications directory.
4.5 Ensure that all the servers in your cluster are running.
4.7 Click Install. Navigate to <WORK_HOME>/applications and select
ShoppingCart.war. Click Next.
4.8 Select Install this deployment as an application and click Next.
4.9 Select dizzyworldCluster as the deployment target and click Next.
4.10 Click Next, and then click Finish.
4.12 Return to dizzyworld > Deployments and select the ShoppingCart application.
Select Start > Servicing all requests. Click Yes, when prompted. The application should
now be active and ready to be accessed.
Test the in-memory session replication.
5.1 Open a Web browser and navigate to http://localhost/ShoppingCart/welcome.jsp.
Note: You are using the Apache Web server to proxy requests to the servers in the
cluster.
5.2 Select Go Shopping and add something to your shopping cart.

5.3 Return to the home page, and then view the items in your shopping cart.
5.4 Check the dizzy1, dizzy2, and dizzy3 server consoles to see which server is
handling the request.
5.5 To simulate a server failure, kill the server instance that is handling your requests by
entering CTRL-C in the server console.
5.6 Continue shopping and add something else to your shopping cart.
5.7 View the shopping cart. All the items that you purchased should be in the cart. Based on
the replication groups and machines, which server do you think is handling the request?
5.8 Check the server consoles to see which server is now handling the request.
5.9 Restart the server that was killed.
Create a data source.
6.1 In the Administration Console, navigate to dizzyworld > Services > JDBC > Data
Sources and create a new data source with the following properties:
Name: SessionDS
JNDI Name: SessionDS
Supports Global Transactions
One-Phase Commit
Port: 9092
Password: PBPUBLIC
Targets: dizzyworldCluster
Activate your changes.
Note: This data source is used by the application to access the database and write
session information.
Add the WL_SERVLET_SESSIONS table to database.
7.1 Open the PointBase console using ./startPointBaseConsole.sh in
<WEBLOGIC_HOME>/common/eval/pointbase/tools.
7.2 Log in using the following properties:
Driver: com.pointbase.jdbc.jdbcUniversalDriver
URL: jdbc:pointbase:server://localhost:9092/HRDatabase
User: PBPUBLIC
Password: PBPUBLIC

7.3 Copy and paste the contents of <LAB_HOME>/exercise/SessionTable.txt into the
Enter SQL Commands window.
7.4 Click Execute All. This creates the table that is necessary to store session information.
7.5 Expand Schemas > PBPUBLIC > Tables and confirm that the WL_SERVLET_SESSIONS
table exists. You may have to refresh the Tables node to see the new table. Leave the
PointBase console open.
Modify weblogic.xml to save session replication information to a database.
8.1 Open <LAB_HOME>/exercise/ShoppingCart/WEB-INF/weblogic.xml in an XML
editor or text editor.
8.2 Change the <session-descriptor> element to support the JDBC-based session
replication:
<timeout-secs>300</timeout-secs>
<invalidation-interval-secs>60</invalidation-interval-secs>
<persistent-store-type>jdbc</persistent-store-type>
<persistent-store-pool>SessionDS</persistent-store-pool>
<persistent-store-table>WL_SERVLET_SESSIONS</persistent-
store-table>
Note: This enables JDBC session replication for this application.

Package and update the modified application.
9.2 Navigate to <LAB_HOME>/exercise/ShoppingCart.
the prompt:
jar cf ../ShoppingCart.war *
9.4 Move the new ShoppingCart.war file from <LAB_HOME>/exercise to the
<WORK_HOME>/applications directory. Replace the existing file.
9.5 In the Administration Console, update the application by navigating to dizzyworld >
Deployments. Lock the console, if necessary and select the ShoppingCart application.
9.6 Click Update, and then click Finish.
Test the JDBC session replication.
10.1 Open a new Web browser and navigate to http://localhost/ShoppingCart/welcome.jsp.
Note: You are using the Apache Web server to proxy requests to the servers in the
cluster.

10.2 Select Go Shopping and add something to your shopping cart.
10.3 Return to the home page, and then view the items in your shopping cart.
handling the request.
10.5 Return to the PointBase console and navigate to Schemas > PBPUBLIC > Tables >
WL_SERVLET_SESSIONS.
10.6 Right-click WL_SERVLET_SESSIONS and select SELECT * FROM
PBPUBLIC.WL_SERVLET_SESSIONS.
10.7 View the results. You should see a session record. If you do not, wait for a minute, and
then try again.
10.8 To simulate a server failure, kill the server instance that is handling your requests by
entering CTRL-C in the server console.
10.9 Continue shopping and add something else to your shopping cart.
10.10 View the shopping cart. All the items that you purchased should be in the cart. Based on
the replication groups and machines, which server do you think is handling the request?
10.11 Check the server consoles to see which server is now handling the request.
11.1 All the servers in dizzyworldCluster must be running before you set up the solution
for this lab.
Open a command prompt using ./prompt.sh that is located in the <STUDENT>/bin

directory. Change to the <LAB_HOME> directory and enter:
ant setup_solution
Note: The functions that need to be performed include:

a) Creating the server replication group properties
b) Deploying the Shopping Cart war application
c) Creating the data source
d) Adding the WL_SERVLET_SESSIONS table to the database
The ant setup_solution script performs only the creation of the server replication
group properties. All other functions have to be performed manually.

EJB Load Balancing and Failover

(45 minutes)
Create a second cluster for a multi-tier architecture
Inspect a Web application and an EJB application that are designed for deployment on a
multi-tier cluster
Deploy a Web application to one tier of the cluster
Deploy an EJB application to the second tier of the cluster
The architects have decided that they would like an environment with a multi-tiered cluster for
the Company Store application. The application developers have split the application into the
front-end Web application and the back-end EJB application. They have designed the JSPs to
look up the EJBs on a different set of servers and they have compiled the EJBs to be cluster-
aware.
Note: For Lab14-1

setup_exercise Using the WLST script, creates a cluster, proxyServer,
replication groups, and data sources
setup_solution Using the WLST script, creates a cluster, proxyServer,
replication groups, data sources, EJB cluster; using WLST, deploys
companyStoreEJBs.jar to the EJB cluster and CompanyStore.war to a cluster
The deployed application is divided into two: the Web application and the EJB application. The
Web part of the application sends data to the EJBs, which return the catalog items to the Web
application to display to the user. The users are also able to add the items to their shopping carts,
view their shopping cart, and check out.
The EJB part of the application comprises the following EJBs:
ShoppingCartBean (session)
ProcessPaymentBean (session)
ClientBean (entity)
CatalogBean (entity)
The ShoppingCartBean maintains the shopping cart session information and should be
available on a secondary server if the primary server fails. The CatalogBean maintains the
catalog information that the application uses and should be available on all servers that can
handle requests from the Web application.

Specifications
Figure 15 presents the application and cluster architecture.
1. A client adds
an item to its
2. The Web server shopping cart.
load balances the
request to dizzy1. Apache Web Server
dizzyworld
dizzyworldCluster
Company Store Company Store Company Store

Web Web Web
Application Application Application
4. A request
from the Web
dizzyworldEJBCluster application to
3. Web application create a new
does a JNDI lookup dizzyMachine3 shopping cart
on dizzy4 for or add an
ShoppingCartHome item to an
and a replica-aware existing one
stub is returned. dizzy4 dizzy5 is load
balanced to
dizzy5.
Company Store Company Store
EJB EJB
Application Application
Figure 15: Application and Cluster Architecture

Basic Instructions
1. Set up the exercise by opening a command prompt using prompt.sh that is located in
ant setup_exercise
2. Create a second cluster of servers with the following properties, in order to set up a
multitier architecture:
Name: dizzyworldEJBCluster
Each student must use a unique port number between the 70327052 range.
Server Name: dizzy4

Machine: Machine3
Cluster: dizzyworldEJBCluster
Server Name: dizzy5

Machine: dizzyMachine3
Cluster: dizzyworldEJBCluster
Deploy the ClientDS and CatalogDS data sources to dizzyworldEJBCluster.

3. Open <LAB_HOME>/exercise/CompanyStoreApp/retrieveitems.jsp in a text
editor and look at the JNDI lookup section. Which server is the application using to look up
the EJB home and retrieve the stub?
When you have finished inspecting the application, package the Web application into
CompanyStore.war and move the new CompanyStore.war file to
<WORK_HOME>/applications.
4. Open <LAB_HOME>/exercise/companyStoreEJBs/META-INF/weblogic-ejb-
jar.xml in a text or XML editor and look for the elements in each EJB that defines their
clustering abilities.
How will the requests to the ShoppingCart EJB be load balanced?
When you have finished inspecting the application, package the EJB application into
companyStoreEJBs.jar and move the new companyStoreEJBs.jar file to

5. Deploy the CompanyStore.war application to dizzyworldCluster. Deploy the
companyStoreEJBs.jar application to dizzyworldEJBCluster. Do not start the
applications.
Note: You may have to deactivate or delete (undeploy) the benefits_as_default

application due to a conflict in default applications.
6. Stop dizzy1, dizzy2, and dizzy3, if they are running.
Change the memory settings for dizzy1 through dizzy5 so that they have a minimum
and maximum of 256 MB available to them.
Copy the CompanyStoreEJBsClient.jar library from <LAB_HOME>/exercise to

<WORK_HOME>/domains/dizzyworld/lib.
Start dizzy1 through dizzy5 with the new memory settings.

7. Start the newly deployed applications.
Open a Web browser and navigate to http://localhost/welcome.jsp.
Browse the store catalog and add several items to your shopping cart. View your
shopping cart. Check the first tier of servers to see which one is handling your requests.
Using the Administration Console and the monitoring capabilities of the
companyStoreEJBs application, check to see which server is handling the EJB
requests.
Kill the server that is handling the EJB requests. Return to the Company Store application,
add another item to the shopping cart, and view the shopping cart. All your items should
still be in the shopping cart.
When you have finished testing, shut down dizzy4 and dizzy5.

Practice 14-1: EJB Load Balancing and Failover
In this practice, you configure and test EJB load balancing and failover.

1.1 Open a prompt using prompt.sh in <STUDENT>/bin.
ant setup_exercise
You must run this ant script.

Create a second cluster in order to set up a multitier cluster architecture.
Username: system
Password: weblogic
2.2 Navigate to dizzyworld > Environment > Servers. Lock the console, if necessary.
2.3 Create a new server with the following properties:
Server Name: dizzy4

2.4 Create another server with the following properties:
Server Name: dizzy5

2.6 Navigate to dizzyworld > Environment > Machines. Lock the console, if necessary.
2.7 Create a new machine with the following properties:
Name: dizzyMachine3
Machine OS: Unix
Click OK.
2.8 Return to dizzyMachine3 and navigate to Configuration > Servers.
2.9 Add dizzy4 and dizzy5 to Machine3.

Practice 14-1: EJB Load Balancing and Failover (continued)
2.10 Navigate to dizzyworld > Environment > Clusters.
2.11 Add a new cluster with the following properties:
Name: dizzyworldEJBCluster
Each student must use a unique port number between the 70327052 range.
Click OK.
2.12 Return to the cluster and navigate to Configuration > Servers.
2.13 Add the existing servers dizzy4 and dizzy5 to the cluster.
2.15 Navigate to dizzyworld > Services > JDBC > Data Sources > CatalogDS >
Targets. Lock the console, if necessary.
2.16 Select dizzyworldEJBCluster and deselect dizzyworldCluster. Make sure that
only the dizzyworldEJBCluster cluster is targeted. Save your changes.
2.17 Repeat the process for the ClientDS data source. Save and activate your changes.
Inspect and package the Company Store Web application.
3.1 Open <LAB_HOME>/exercise/CompanyStoreApp/retrieveitems.jsp in a text
editor.

3.2 Look for the following section:
Hashtable ht = new Hashtable();

ht.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialCo
ntextFactory");
ht.put(Context.PROVIDER_URL,"t3://localhost:8001");
try {
InitialContext ic = new InitialContext(ht);
} catch(Exception e) {
ht.put(Context.PROVIDER_URL,"t3://localhost:8003");
}
InitialContext ic = new InitialContext(ht);
CatalogHome home = (CatalogHome)

PortableRemoteObject.narrow(ic.lookup("com.bea.edu.wls.CatalogEJB
"), CatalogHome.class);
Enumeration catalogItems = home.findByCategory(value);
The JSP does the initial lookup of the EJB from dizzy4 and if that does not work,
dizzy5. The initial server returns a replica-aware stub, which then handles any requests
to the EJB. So, when the JSP calls the findByCategory method, the stub chooses the
server to send the request to.
3.3 Close the file.
3.5 Navigate to <LAB_HOME>/exercise/CompanyStoreApp.
the prompt:
jar cf ../CompanyStore.war *
3.7 Move the new CompanyStore.war file from <LAB_HOME>/exercise to
Inspect and package the Company Store EJB application.
4.1 Open <LAB_HOME>/exercise/companyStoreEJBs/META-INF/weblogic-ejb-
jar.xml in a text or XML editor.

4.2 Look for the following set of elements for CatalogBean:
<entity-descriptor>
<entity-clustering>
<home-is-clusterable>true</home-is-clusterable>
<use-serverside-stubs>true</use-serverside-stubs>
</entity-clustering>
</entity-descriptor>
This set of elements tells the weblogic.appc compiler that the entity EJB,
CatalogBean, is clusterable. You should also be able to find the same set of elements
for the ClientBean.
4.3 Look for the following set of elements for the ShoppingCart EJB:
<stateful-session-descriptor>
<stateful-session-clustering>
<home-is-clusterable>true</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
<replication-type>InMemory</replication-type>
</stateful-session-clustering>
</stateful-session-descriptor>
This set of elements tells the weblogic.appc compiler that the stateful session EJB,
ShoppingCart, is clusterable. It also lets the cluster know that load balancing for the
EJB is random (If this is not explicitly defined here, it uses the load-balancing algorithm
set up in config.xml.) and that the session state replication is in-memory.
4.4 Close the file.
4.6 Navigate to <LAB_HOME>/exercise/companyStoreEJBs.
4.7 Package the Company Store EJBs application into a .jar file by entering the following in
the prompt:
jar cf ../companyStoreEJBs.jar *
4.8 Move the new companyStoreEJBs.jar file from <LAB_HOME>/exercise to
Deploy the Web and EJB applications to the clusters.
5.2 Deploy the CompanyStore.war application to dizzyworldCluster.
5.3 Deploy the companyStoreEJBs.jar application to dizzyworldEJBCluster.
5.4 Activate your changes. Do not start the applications.

Change the memory settings of the server.
6.1 If they are running, shut down dizzy1, dizzy2, and dizzy3.
6.2 Navigate to <WORK_HOME>/domains/dizzyworld/bin.
6.3 Make a copy of startManagedWebLogic.sh and call it:
startClusteredManagedWebLogic.sh.
6.4 Open the new file in a text editor and find the following section:
ADMIN_URL=http://localhost:7001
6.5 Add the following line after the ADMIN_URL line:
USER_MEM_ARGS="-Xms256m -Xmx256m
export USER_MEM_ARGS
Note: Due to the restrictive nature of the lab environment, the amount of memory that
each server can use is restricted.
6.7 Copy the CompanyStoreEJBsClient.jar library from <LAB_HOME>/exercise to
<WORK_HOME>/domains/dizzyworld/lib.
Note: This library is used by the Web application when accessing the EJB packages. By
placing it in the lib directory of your domain, when you restart the servers, it is
automatically added to classpath.
6.8 Using the prompt that was opened earlier, or a new one, navigate to
<WORK_HOME>/domains/dizzyworld/bin and start dizzy1 through dizzy5 using
xterm T <server_name> -e ./startClusteredManagedWebLogic.sh
<server_name> &.
Note: Wait until each server is RUNNING before you start the next one. Replace
<server_name> with the name of the server that you are starting, for example, dizzy1.
At this point, the performance of the machine slows down considerably. So be patient.
Test failover and load balancing in a multitier cluster.
7.1 In the Administration Console, navigate to dizzyworld > Deployments. Start the
CompanyStore and companyStoreEJBs applications.
7.2 Open a Web browser and navigate to http://localhost/welcome.jsp.
7.3 Browse the store catalog and add several items to your shopping cart.
7.4 View your shopping cart.
handling your request.

7.6 In the Administration Console, navigate to dizzyworld > Deployments >
companyStoreEJBs > Monitoring > Stateful. Which server contains the stateful
session beans?
7.7 Kill the server that is handling the EJB requests (either dizzy4 or dizzy5) by entering
CTRL-C in the server console.
7.8 Return to the Company Store application and add another item to the shopping cart. View
the shopping cart. All your items should still be in the shopping cart.
7.9 When you have finished testing, shut down dizzy4 and/or dizzy5.

Clustering JDBC Data Sources

(30 minutes)

Deploy a data source to a cluster
Test the data source clustering capabilities
Configure a multi data source
Fail over a data source
The developers have given you an application that requires access to a database. This application
needs to be targeted to a cluster. The architects have determined that the database will be highly
available, so you need to set up the environment to take advantage of this.
Note: For Lab15-1

setup_exercise Using the WLST script, creates a cluster, proxyServer,
replication groups, data source; deploys testds.war to dizzy1 using WLST
setup_solution Using the WLST script, creates a cluster, proxyServer,
replication groups, and a multi data source; creates data sources and targets them to a
cluster using the WLST scripts; deploys testds.war to dizzy1 using WLST
Resources should be deployed homogeneously to a cluster. If an application that uses a data

source is to be deployed to a cluster, the data sources it uses should also be. The TestDS
application is deployed to dizzyworldCluster. It uses the DizzyworldDS data source, so
this data source should also be deployed to the cluster. A multi data source will take advantage of
the highly available database by grouping together multiple data sources that connect to different
copies of the same database. Thus, if one of the databases fails, the other data source is available
for access to the same set of data on a copy of the original database.

Specifications
Figure 16 presents the clustered data source architecture.
dizzyworld
dizzyworldCluster
TestDS TestDS TestDS

DizzyworldDS DizzyworldDS DizzyworldDS

Data Source Data Source Data Source
HRDatabase
Figure 16: Cluster Data Source Architecture

Figure 17 presents the multi data source architecture.
dizzyworld
dizzyworldCluster
TestDS TestDS TestDS

DizzyworldMul DizzyworldMul DizzyworldMul

tiDS Multi Data tiDS Multi Data tiDS Multi Data
Source Source Source
DizzyworldDS DizzyworldDS DizzyworldDS
DizzyworldDS2 DizzyworldDS2 DizzyworldDS2
HRDatabase
(Original)
HRDatabase
(Copy)
Figure 17: Multi Data Source Architecture

Basic Instructions
1. Set up the exercise by opening a command prompt using ./prompt.sh that is located
in <STUDENT>/bin. Change to the <LAB_HOME> directory and enter:
ant setup_exercise
2. Deploy the TestDS application to the cluster. It should already be deployed to dizzy1.
3. Deploy the data source, dizzyworldDS, to dizzyworldCluster. It should already be
deployed to dizzy1.
4. Open a Web browser and navigate to http://localhost/TestDS.
Verify the information and click the Test Data Source button. You should see the results
from the query of the EMPLOYEE table. Check the dizzy1, dizzy2, and dizzy3 server
consoles to see which one is handling the request and accessing the database.
5. Suspend the data source on the server that is handling the requests and test the
application again. This time you should get an error page because the data source is no
longer available.
Note: Clustering a data source allows all the data sources to be available on all servers in
a cluster for both local (running on the same server) and remote clients. A remote client
can fail over the connection but a local client is pinned to the data source. A multi data
source can help a local client fail over its connection.
6. Create another data source with the following properties:
Name: dizzyWorldDS2
JNDI Name: dizzyWorldDS2
Port: 9092
Password: PBPUBLIC
Target: dizzyworldCluster
7. Create a multi data source with the following properties:
Name: dizzyworldMultiDS
JNDI Name: dizzyworldMultiDS
Algorithm Type: Failover
Driver: Non-XA Driver
Data Sources: dizzyworldDS, dizzyworldDS2

8. Return to the Web browser with the TestDS application open. It should be on the error
page you got from the last time (step 5). Return to the test page and try again but this time
specify dizzyworldMultiDS as the Data Source Name. Now you should get a
connection, even though the original data source is still suspended. This is because you
now have a multi data source deployed to that server so it can fail over to the other data
source.
Note: In the lab environment, you use only one database. But in a production
environment, multi data sources are used together with a highly available database. So,
each data source in the multi data source may point to a different database. These
databases need to be able to synchronize with each other.
./prompt.sh that is located in <STUDENT>/bin directory. Change to the <LAB_HOME>
ant setup_solution
When this is complete, you need to manually target the testds application to
dizzyworldCluster in the Administration Console.

Load-Balance JMS Messages
(30 minutes)

Create a distributed destination
Load-balance messages on different JMS servers and queues
The developers have given you an application that requires the use of the Java Message Service
(JMS). This application needs to be targeted to a cluster. The architects have determined that the
application should load-balance its messages to different JMS servers in the cluster.
Note: For Lab 15-2

setup_exercise Using the WLST script, creates a cluster, proxyServer, replication
groups, a JMS server and module. It also deploys messaging.war to dizzy1 using WLST.
setup_solution Using WLST script, creates a cluster, proxyServer, replication groups,
JMS servers, a JMS module, and a distributed queue. It also configures a JMS store using the
script and deploys messaging.war to dizzy1 using WLST.
JMS resources are pinned resources and cannot be deployed to multiple servers in a cluster, with
the exception of a connection factory and distributed destination. Each server that handles JMS
messages needs to have a JMS server with one or more destinations. Load-balancing messages
from clients can be accomplished with the use of distributed destinations. A distributed
destination is a virtual destination that sends the message to one of the physical destinations it
represents, therefore the message ends up on only one server.

Specifications
Figure 18 presents the dizzyworldDistributedQueue.
dizzyworld
dizzyworldCluster
Messaging Messaging Messaging

dizzyworldDistributedQueue
dizzyworldJMS dizzyworldJMS dizzyworldJMS

Server@dizzyw Server2@dizzy Server3@dizzy
orldDistributed worldDistribute worldDistribute
Queue dQueue dQueue
Figure 18: dizzyworldDistributedQueue

Basic Instructions
ant setup_exercise
2. Create two new JMS servers with the following properties:
Name: dizzyworldJMSServer2
Target: dizzy2
Target: dizzy3
3. Create a new JMS module with the following properties:
Name: dizzyworldClusterJMSModule
4. Create a new subdeployment and distributed destination with the following properties:
Subdeployment Name: dizzyworldClusterSubdeployment

Type: Distributed Queue

Name: dizzyworldDistributedQueue
JNDI Name: dizzyworldDistributedQueue
Load Balancing Policy: Round-Robin
Allocate Members Uniformly: True
Target: dizzyworldClusterSubdeployment
Server Affinity disabled
5. Create a new connection factory with the following properties:
Type: Connection Factory

Name: dizzyworldConnectionFactory
JNDI Name: dizzyworldConnectionFactory
Target: dizzyworldClusterSubdeployment
Server Affinity: Disabled

6. Deploy the messaging application to dizzyworldCluster. Then open a Web browser
and navigate to http://localhost/messaging.
Post three different messages to the distributed queue, and then view the messages in
the distributed queues. Each queue should have one of the messages that you sent from
the application.
Note: If you do not see the message immediately, wait for a minute or two, and then
refresh the screen.

Practice 15-1: Clustering JDBC Data Sources
In this practice, you configure and test the failover capabilities of multi data source.

ant setup_exercise
You must run this script for this lab.

Deploy the TestDS application to the cluster.
Username: system
Password: weblogic
2.2 Navigate to dizzyworld > Deployments. Lock the console, if necessary.
2.3 Click the testds application and navigate to the Targets tab.
2.4 Deselect, and then select dizzyworldCluster to ensure that the data source is
targeted to all the servers in the cluster.
Deploy DizzyworldDS to the cluster.
3.1 Navigate to dizzyworld > Services > JDBC > Data Sources. Lock the console, if
necessary.
3.2 Click the dizzyworldDS data source and navigate to the Targets tab.
3.3 Deselect, and then select dizzyworldCluster to ensure that the data source is
targeted to all the servers in the cluster.
3.5 Restart dizzy1, dizzy2, and dizzy3.
Test the TestDS application.
4.1 Open a Web browser and navigate to http://localhost/testds.
4.2 Verify the information and click the Test Data Source button. You should see the results
from the query of the Employee table. Keep this window open.
4.3 Check the dizzy1, dizzy2, and dizzy3 server consoles to see which one is handling
the request and accessing the database.

Practice 15-1: Clustering JDBC Data Sources (continued)
Suspend DizzyworldDS and test the application.
5.1 Return to the Administration Console and navigate to dizzyworld > Services > JDBC
> Data Sources > dizzyworldDS > Control.
5.2 Select the check box for the server that is currently handling the requests.
5.3 Click Suspend, and then select Suspend from the drop-down list. Click Yes when
prompted. This suspends the data source, simulating a failure of a data source.
5.4 Return to the TestDS application and click the Test Data Source button. This time you
should get an error page because the data source is no longer available. Do not close
this browser window.
Note: Clustering a data source allows all the data sources to be available on all servers in
a cluster for both local (running on the same server) and remote clients. A remote client
can fail over the connection but a local client is pinned to the data source. A multi data
source can help a local client fail over its connection.
Create another data source to connect to the HRDatabase.
6.1 Return to the Administration Console and navigate to dizzyworld > Services > JDBC
> Data Sources. Lock the console, if necessary.
6.2 Create a new data source with the following properties:
Name: dizzyworldDS2
JNDI Name: dizzyworldDS2
Database Driver: *PointBases Driver (Type 4) Versions: 4.X,5.X
Click Next.
6.3 Accept the defaults and click Next.
6.4 Enter the following details for connection properties:

Port: 9092
Password: PBPUBLIC
Click Next.
6.5 Test the configuration, and then click Next.
6.6 Target the data source to dizzyworldCluster and click Finish.
Create a multi data source.
7.1 Navigate to dizzyworld > Services > JDBC > Multi Data Sources. Lock the console,
if necessary.

Practice 15-1: Clustering JDBC Data Sources (continued)
7.2 Create a new multi data source with the following properties:
Name: dizzyworldMultiDS
JNDI Name: dizzyworldMultiDS
Algorithm Type: Failover
Click Next.
7.3 Target the multi data source to dizzyworldCluster and click Next.
7.4 Select Non-XA Driver and click Next.
7.5 Add dizzyworldDS and dizzyworldDS2 to the list of Chosen data sources. Click
Finish.
Test the failover capabilities of the multi data source.
8.1 Return to the Web browser with the TestDS application open. It should be on the error
page you received from last time (step 5.4).
8.2 Return to the test page (http://localhost/tesds) and try again. This time specify
dizzyworldMultiDS as the Data Source Name. Now you should get a connection,
even though the original data source is still suspended. This is because you now have a
multi data source deployed to that server so it can fail over to the other data source.
Note: In the lab environment, you use only one database. But in a production
environment, multi data sources are used together with a highly available database. So,
each data source in the multi data source may point to a different database. These
databases need to be able to synchronize with each other.
After completing this lab, close any prompt terminal windows if they are open.
enter:
ant setup_solution
When this is complete, you need to manually target the testds application to
dizzyworldCluster in the Administration Console.

Practice 15-2: Load-Balancing JMS Messages
In this practice, you configure JMS load balancing with the distributed queue.

ant setup_exercise
You must run this ant script for this exercise.

Create JMS servers on dizzy2 and dizzy3.
Username: system
Password: weblogic
2.2 Navigate to dizzyworld > Services > Messaging > JMS Servers. Lock the console, if
necessary.
2.3 Create a new JMS server with the following properties:
Target: dizzy2
2.4 Create another new JMS server with the following properties:
Target: dizzy3
Create the dizzyworldClusterJMSModule JMS module.
3.1 Navigate to dizzyworld > Services > Messaging > JMS Modules. Lock the console, if
necessary.
3.2 Create a new JMS module with the following properties:
Name: dizzyworldClusterJMSModule
3.3 Click Next. Click Finish.
Create a new subdeployment and distributed destination.
4.1 Navigate to dizzyworld > Services > Messaging > JMS Modules >
dizzyworldClusterJMSModule > Subdeployments. Lock the console, if necessary.

Practice 15-2: Load-Balancing JMS Messages (continued)
4.2 Create a new subdeployment with the following properties:
Subdeployment Name: dizzyworldClusterSubdeployment

dizzyworldClusterJMSModule.
4.4 Create a new JMS System Module Resource with the following properties:
Type: Distributed Queue
Name: dizzyworldDistributedQueue
JNDI Name: dizzyworldDistributedQueue
Load Balancing Policy: Round-Robin
Allocate Members Uniformly: True
Target: dizzyworldClusterSubdeployment (Hint: Select Advanced Targeting.)
4.5 Return to dizzyworldDistributedQueue and navigate to Configuration >
Members.
4.6 Review the Distributed Destination Members. Note that each of the JMS servers in the
cluster now has a special distributed queue. So, while the application looks up and
connects to dizzyworldDistributedQueue, the actual messages appear on the
distributed queues on the individual servers.
Create a new JMS connection factory and deploy it to dizzyworldCluster.
dizzyworldClusterJMSModule. Lock the console, if necessary.
5.2 Create a new JMS System Module Resource with the following properties:
Type: Connection Factory

Name: dizzyworldConnectionFactory
JNDI Name: dizzyworldConnectionFactory
Target: dizzyworldClusterSubdeployment (Hint: Select Advanced Targeting.)
5.3 Return to dizzyworldConnectionFactory and navigate to Configuration > Load
Balance.
5.4 Deselect Server Affinity Enabled.
Note: The Server Affinity Enabled parameter attempts to load-balance across any other
local destination members that are also running on the same Oracle WebLogic Server
and favors destinations on servers to which it already has a connection.
Test JMS load balancing with the distributed queue.
6.1 Navigate to dizzyworld > Deployments > Messaging > Targets. Lock the console, if
necessary.

Practice 15-2: Load-Balancing JMS Messages (continued)
6.2 Target the application to all the servers in dizzyworldCluster by deselecting, and
then reselecting dizzyworldCluster. Save and activate your changes.
6.3 Open a Web browser and navigate to http://localhost/messaging.
6.4 Post three different messages to the distributed queue.
6.5 Return to the Administration Console and navigate to dizzyworld > Services >
Messaging > JMS Modules > dizzyworldClusterJMSModule >
dizzyworldDistributedQueue > Monitoring.
6.6 View the number of messages in the queue. Repeat the process for the other two
queues. Each queue should have one of the messages that you sent from the
application.
Notes: Customize the table to view messages. If you do not see the message
immediately, wait for a minute or two, and then refresh the screen.
After completing this lab, close any prompt terminal windows if they are open.

Virtual Host
Objectives

following:
Explain a virtual host
Create virtual hosts
Configure virtual hosts
Monitor virtual hosts
Target virtual hosts to servers
Oracle WebLogic Server 10g R3: System Administration B - 2
Understanding Virtual Hosts
Virtual hosts:
Have one or more Web addresses associated with them
(domain name and IP address)
Enable you to make one Web server behave as if it were
multiple servers
Virtual hosting can be used to allow one Web server to
host multiple internal and external corporate sites.
It is often convenient to have the same Web server
respond to requests for multiple domain names.
Understanding Virtual Hosts

Virtual hosting allows you to define host names that servers or clusters respond to. When you use
virtual hosting, you use the domain name server (DNS) to specify one or more host names that map
to the IP address of an Oracle WebLogic Server or cluster and you specify the Web applications that
are served by the virtual host. When used in a cluster, load balancing allows the most efficient use of
your hardware, even if one of the DNS host names processes more requests than the others.
For example, you can specify that a Web application called books responds to requests for the virtual
host name www.books.com, and that these requests are targeted to Oracle WebLogic Servers A, B,
and C. You can also specify that a Web application called cars responds to the virtual host name
www.autos.com and that these requests are targeted to Oracle WebLogic Servers D and E.
Depending on your application and the Web server requirements, you can configure a variety of
combinations of virtual host, Oracle WebLogic Servers, clusters, and Web applications.
The Big Picture of Virtual Hosting
Requests for www.example.com VirtualHost1
Web Web
App 1 App 2
Web
App 3
VirtualHost2
Web Web
App 4 App 5
Requests for www.demo.com

Oracle WebLogic Server
The Big Picture of Virtual Hosting

One instance of Oracle WebLogic Server can be configured to look like several instances. Oracle
WebLogic Server allows you to create virtual hosts and deploy Web applications based on those
virtual hosts. Therefore, depending on the request in the URL, different applications are available to
the client. In the example in the slide, the virtual host at the top is named VirtualHost1 and responds
to the URL www.example.com. There are three Web applications deployed on this virtual host;
therefore, clients making a request on www.example.com have three Web applications available to
them. The virtual host below is named VirtualHost2 and responds to the URL www.demo.com.
When clients make a request on this instance of Oracle WebLogic Server with the URL
www.demo.com, they have two Web applications available to them.
Configuring Virtual Hosts
To configure a virtual host, perform the following steps:

1. Create the virtual host in the Administration Console.
2. Target the virtual host to a server.
3. Target applications to the virtual host.
4. Resolve DNS names in a system host file.
WLS
2
3
1
Virtual Host Application
Configuring Virtual Hosts

These steps are described in greater in the following slides.
Creating Virtual Hosts
Creating Virtual Hosts

To create a new virtual host, perform the following steps:
1. Expand Environment in the left pane. Click Virtual Hosts.
2. Click Create a New Virtual Host in the right pane.
3. Enter a name to represent this virtual host.
4. Enter the virtual host names, one per line. Only those requests that match one of these virtual
host names are handled by Oracle WebLogic Server or the cluster targeted by this virtual host.
Note: The default Web application can be configured to the virtual host by configuring the
<context-root> attribute in weblogic.xml of the Web application. Otherwise, the virtual
host gets a null context when accessed without an application name.
Targeting Virtual Hosts to Servers
Targeting Virtual Hosts to Servers

Typically, Managed Servers are used, in which case you would want to target your virtual host to one
of them, although it is possible to target an Administration Server in the simple case where only one
Oracle WebLogic Server instance is used for both administration and application execution.
Targeting Applications to a Virtual Host
Targeting Applications to a Virtual Host

To target Web applications to a virtual host, perform the following steps:
1. Select the Web application that you want to target.
2. Click the Targets tab in the right panel.
3. Select the virtual hosts to which you want to deploy the application.
Configuring Virtual Host Logging
Configuring Virtual Host Logging

The access log enables monitoring of all incoming requests to a particular virtual host. HTTP
requests for a virtual host are kept in a log file that is separate from the servers log files.
Note: The log is used only if the virtual host name specified is an actual DNS name, or is associated
with the local IP address or loop-back address. Getting an entry in the access log is a good way to
test whether the virtual host is indeed being used.
Summary

Create virtual hosts
Deploy Web applications to virtual hosts
Target virtual hosts to servers
Target virtual hosts to clusters
Monitor virtual hosts
Getting Started with BEA Guardian
Objectives
After completing this appendix, you should be able to do the

following:
List the features of BEA Guardian
Install Guardian and initialize a workspace
Inventory and evaluate domains to detect potential
problem signatures
Create a support case using Guardian
Oracle WebLogic Server 10g R3: System Administration C - 2
Road Map
Guardian Concepts
General Architecture and Capabilities
Domain Inventory
Problem Signatures
Getting Started
Working with Domains
Guardian Architecture
WebLogic Domain
Admin Server
JMX
Guardian
Agent (WAR)
Managed Server
HTTP(S)
Guardian JMX
Client Guardian
Agent (WAR)
GUI or Script
WebLogic Domain
Guardian Architecture
A domain is a logically related group of Oracle WebLogic Server resources that you manage as
a unit. A domain always includes at least one Oracle WebLogic Server instance called the
Administration Server. The Administration Server acts as a central point of contact for server
instances and system administration tools. A domain may also include additional Oracle
WebLogic Server instances called Managed Servers. Each Guardian client workspace maintains
a registry of active domains. A domain is considered active when it is capable of being
evaluated. You select the domains to activate and evaluate.
There are two different ways to run Guardian: using the Graphical User Interface (GUI) and
using the Command Line Interface. The Graphical User Interface provides more functionality
and is easier to use. But the Command Line Interface provides automated scripting capabilities
that the Graphical User Interface does not have.
The Guardian Agent collects data from your domain. This data is used during an evaluation to
detect signatures that can cause problems in your domain.
The Guardian Agent uses the Java Management Extensions (JMX), Java System Properties, and
JDBC drivers to collect the data that is required by the signatures. To access this data, a
Guardian Agent may be installed on each server in the domain during domain activation. If you
have configured additional servers in your domain since activation, additional Guardian Agents
may be installed during evaluation.
Road Map
Guardian Concepts
Getting Started
Product Installation
Supported Configurations
Client Workspace
Product Updates
Agent Deployment
Installation
A valid support account is required to download Guardian.

Guardian is installed outside of your BEA_HOME.
Installation
Install Guardian by running the guardian_installer.exe executable. To run the
Guardian installer on Linux in Console Mode (with no GUI), run the following:
guardian_installer.bin -i console.
Otherwise, when you run the Guardian installer, the InstallAnywhere preparation window
appears. The Guardian installer then takes you through the following steps:
1. Language Selection Select your native language from the list and click OK.
2. Introduction Read the introduction and click Next.
3. License Agreement Read the license terms, select I accept, and then click Next.
4. Choose Install Folder Select a folder in which to install Guardian and click Next. By
clicking Choose, you can navigate to the installation folder that you want or create a new
folder.
5. Pre-Installation Summary Review the summary and click Install to start the installation.
Guardian will not start on a machine that is running a Java Runtime Environment (JRE) older
than version 5 (also known as version 1.5). If you attempt to run Guardian with an older JRE,
you get an error message. If necessary, edit guardian.ini (in the Guardian installation
directory) and supply the location of your JRE:
-vm
c:\jre_1.5\bin\java.exe
Guardian Workspace
When launching the Guardian client, select a Workspace folder

in which to store the domain inventories and evaluations.
Guardian Workspace
When Guardian starts, it opens the Select Workspace dialog box, which prompts you for the
Guardian Workspace directory that holds the Domain Inventories, Evaluation Summaries, and
Case Archives for each domain. The Guardian Workspace location must be separate from the
Guardian installation directory. This requirement preserves the implicit contract with the
customer that their data will never be removed, even when Guardian is uninstalled.
The default Guardian Workspace location is in your home directory, for example, C:\Documents
and Settings\<username>\guardianWorkspace for Windows and /home/<username>/
guardianWorkspace for Linux. The default workspace location is especially important for the
Guardian Command Line Interface in the case where you run it before the Graphical User
Interface and have not yet had a chance to select a Guardian Workspace location. To change the
Guardian Workspace location, click Browse and navigate to the location that you want. You can
also create a new Guardian Workspace directory by clicking Make New Folder.
If you select the Use this as the default workspace and do not ask again check box, Guardian
uses the current location from then on when it starts. To resume opening the Select Workspace
dialog box at startup, select the Prompt for workspace on startup check box in the Startup and
Shutdown section of the Guardian Preferences menu.
Updating Guardian
Regularly update Guardian to download and install the

latest:
Client and agent software
Problem signatures
Supply your BEA Customer Support account credentials:
Contact BEA or use the support.bea.com site to enable
Guardian on your account.
Guardian Toolbar
Updating Guardian
The Main Toolbar comprises buttons with icons and text below the main menu. When the cursor
is over a toolbar button, a tool tip appears and specifies what the button does.
To update Guardian, use the Update Wizard to download new BEA Guardian software and
signatures from the BEA Guardian update site, http://guardian.bea.com/update. The Update
Wizard uses a sequence of dialog boxes to gather the information that is needed to download and
install new signatures and application features:
1. eSupport Login: Enter your BEA eSupport username and password to access the
Guardian update site.
2. Select eSupport Site Id: If you have multiple eSupport site identifiers, select one to use
for this update. Most customers have only one site identifier.
3. Search Results: If there are new signatures or application features available, select the
ones that you want to install. All of them are selected by default.
4. Feature License: Click the button that indicates that you accept the terms in the license
agreement.
5. Installation Location: You can change the installation location for each signature and
application feature update, but it is recommended that you use the default location.
6. Restart Guardian: After all the updates are installed, click Yes to restart Guardian. When
Guardian restarts, all the new signatures and application features that you downloaded are
available.
Deploying the Agent
Before a domain can be evaluated, you must manually deploy

the Guardian agent to its servers:
bea-guardian-agent.war
Deploying the Agent

The Guardian diagnostic tool is included with this release of Oracle WebLogic Server. Guardian
is not enabled by default. You can enable it via the GuardianEnabled attribute of
DomainMBean by using the WebLogic Scripting Tool (WLST) or the Administration Console.
To enable Guardian from the Administration Console, perform the following:
1. In the Change Center of the Administration Console, click Lock & Edit.
2. In the left pane of the Console, under Domain Structure, select the domain name.
3. In the right pane, select General Configuration, and then select the Enable Guardian Agent
option.
4. To activate these changes, in the Change Center of the Administration Console, click
Activate Changes.
5. Restart the server.
Road Map
Guardian Concepts
Getting Started
Domain Activation
Domain Inventory
Domain Evaluation
Support Case Management
Scripting Guardian
Activate a Domain
Activated domains support evaluation by Guardian.
1
2
Location of domain
admin server
Activating a Domain
Activating a domain prepares it for evaluation by installing any required Guardian Agents and
creating a new Domain Inventory.
There are several different ways to invoke the Domain Activation Wizard:
Click Activate on the main toolbar.
From the File menu, select New > Domain.
Right-click inside the Domain Explorer and select Activate Domain from the shortcut
menu.
The Domain Activation Wizard contains the following data entry fields:
The communication Protocol: Either http:// or https:// for secure sockets layer (SSL)
encryption. Note that Guardian does not use 128-bit SSL encryption for domain activation.
The Host Name: The listen address of the target domains Administration Server
The Username and Password: of an administrator account on the target domain
If the Remember username/password check box is selected, the username and password are
encrypted and stored on disk. Whenever you access the domain, the username and password are
filled in.
You may select the name of a proxy server from the list. If there are no proxy servers in the list,
click Add Proxy Servers to add one.
Explorer Views
The Domain Explorer lists all generated inventories and

evaluations for each activated domain.
The Signature Explorer allows you to browse all installed
problem signatures that are used during evaluations.
Activated
domain
Double-click to view
a domain inventory.
Explorer Views
After activating a domain, a node is added to the Domain Explorer view, in the Target Domains
folder. An initial Domain Inventory entry is also added to the domain nodes Inventory History
folder.
Domain nodes also include icons. One icon is for active domains and one is for inactive
domains. Active domains can also be decorated with icons that indicate whether the username
and password have been persisted, and whether the domain requires SSL encryption for all
communication. Note that Guardian uses 128-bit open source encryption for SSL.
Every time you activate, evaluate, or inventory a domain, a new Domain Inventory is created
and added to the domains Inventory History folder. If you double-click a Domain Inventory, a
Domain Inventory editor opens in the Document pane.
Every time you evaluate a domain, a new Evaluation Summary is created and added to the
domains Evaluation History folder. If you double-click an Evaluation Summary, an Evaluation
Summary editor opens in the Document pane.
Signature Explorer is a view that allows you to browse and interact with the available signatures.
Signature entries include severity indicator icons (such as Critical or Warning) that approximate
the level of attention you should give the signature when it is detected.
Explorer Views (continued)
If you double-click a signature in Signature Explorer, a Signature Details editor opens in the
Document pane. When you click Signature Explorers Menu icon, a menu is displayed that
allows you to sort and filter the list of signatures displayed.
When Outline View is open and the Signature Details editor is active, you can also use Outline
View to control what the Signature Details editor displays.
Domain Inventory
Select a server to
view its details.
Select a JDBC data
source to view its details.
View printable
version.
Domain Inventory
A Domain Inventory is an XML document that describes your domains environment. It
includes descriptions of your servers, Java Virtual Machines (JVMs), operating systems, and
databases. The descriptions include product versions as well as some configuration settings. A
Domain Inventory is created when you activate a domain and is refreshed each time a domain is
evaluated. You can also invoke the Inventory Wizard yourself to create a new Domain
Inventory. Domain Inventories are kept in the Guardian Workspace. Sometimes, it is helpful to
inventory a domain to check its status or to print a description of it.
There are several ways to invoke the Inventory Wizard:
Click Inventory on the main toolbar.
From the File menu, select New > Inventory.
Right-click inside the Domain Explorer and select Inventory from the shortcut menu.
At the bottom of the Domain Inventory editor are the following tabs for the different Domain
Inventory representations. Note that these representations are read-only:
Overview Provides a summary of the Domain Inventory
Source Provides the actual XML source for the Domain Inventory
Report Provides the same information as the Overview tab but in a printer-friendly
format
When Outline View is open and the Domain Inventory editor is active, you can use Outline
THESE View to control ARE
eKIT MATERIALS whatFOR
the YOUR
Domain Inventory
USE editor displays.
IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
Evaluation Summary
View the description and the suggested remedy for each

detected signature. Select a detected
problem signature.
Evaluation Summary
An Evaluation Summary is created each time you evaluate a domain. It is persisted in the
Guardian Workspace. The Evaluation Summary editor in the Document pane allows you to
interact with the Evaluation Summary and determine whether you need to take any corrective
action.
At the bottom of the Evaluation Summary editor are the following tabs for the different
Evaluation Summary representations. Note that these representations are read-only:
Overview: Provides evaluation statistics and a list of detected signatures. It also includes a
description and remedy recommendation for each signature detected in the evaluation.
Source: Provides the actual XML source from the Evaluation Summary. It includes the
raw data for each detected and undetected signature.
Report: Provides all the information contained in the Overview tab but in a printer-
friendly format
The Severity column of the detected signature table includes an icon (Critical, Warning) that
approximates the amount of attention you should give each signature that is detected.
Evaluation Summary (continued)
For a given bundle of signatures, some signatures may not be used in the evaluation because
they target different products/versions than that the domain is configured for. The ones that do
target what the domain has are counted as Targeted Signatures. Targeted Signatures are divided
into Detected Signatures, which are actually found on the domain and Undetected Signatures,
which are not found on the domain. If a signature fails to evaluate, it is counted as an
Undetectable Signature and is considered flawed.
Comparing Evaluations
Compare the differences between any two domain evaluations.
2
Submitting Support Case
Guardian can generate a new BEA Customer Support case

based on a problem signature.
Cases automatically include your:
Domain Inventory and config.xml file
Domain, server, and HTTP log files
Evaluation results

To submit a support case, invoke the Support Case Wizard from an Evaluation Summary by
clicking Get more help from BEA support. You can open an Evaluation Summary either by
performing an evaluation, or by double-clicking an Evaluation Summary entry in the Domain
Explorer. The Support Case Wizard uses a sequence of dialog boxes to gather the information
that is required to open a support case and allow a support engineer to begin working on it.
You can either connect to BEA to open an actual support case now, or save the case information
in a Case Creation Archive to open a support case later.
After the case is created, the Evaluation Summary is updated with either the BEA support case
number or the name of the Case Creation Archive. The Get more help from BEA support link
is then no longer available.
Server used to
initialize JVM and
1 OS case fields
2
Submit case
online.
3
Save case to submit Logs and other

later with eSupport. case attachments
Submitting Support Case (continued)

The Support Case Wizard steps include the following:
1. Select Server Node: Identify the server node on the domain that has the detected
signature. If the node preselected in the dialog box is not the correct one, change it using
the drop-down list. If there is only one server in your domain, the Administration Server is
used by default and this step is skipped.
2. Support Case Notes: Add any additional text that you feel may help resolve the support
case sooner in the Additional Case Notes section. The Default Case Notes section already
contains the text from the Evaluation Summarys description and remedy sections.
3. Select Case Attachments: Specify the background materials to send to BEA, for example,
the server log or the domain configuration file. Each signature includes a list of
attachments needed to resolve the case. Some, such as the Domain Inventory, are required
to create a support case. They are listed in the Case Attachments section and cannot be
unselected. If you feel additional attachments would help in resolving the support case
sooner, you can add them to the Other Attachments section by clicking the plus symbol
icon and navigating to the attachment that you want to add.
4. Domain Login: Enter the username and password used to log in to the domain and get the
case attachments that are specified in step 3.
Submitting Support Case (continued)
5. Select Case Destination: Select whether to connect to BEA and create a support case now,
or to save the case information as a Case Creation Archive and create a support case later
(may be useful for machines that are not connected to the Internet).
6. eSupport Login: Enter your BEA eSupport username and password.
Guardian Security
Guardian has several features to help you avoid compromising

the security of your domain.
If enabled, the 128-bit SSL encryption is used for
communication between:
The Guardian client and the domain (agent)
The Guardian client and eSupport (signature updates and
support cases)
All credentials and server names that are saved
in your Workspace are first encrypted.
Guardian Security
All communication between Guardian and the servers in the target domain requires valid
username and password credentials. Guardian prompts you for the username and password of an
administrator account on the target domain when you conduct an evaluation or activate a
domain. You can choose to have Guardian remember the username and password so that you do
not have to enter them for every evaluation. All passwords that are persisted on disk are
encrypted. Usernames and server names are also encrypted. This encryption helps prevent the
disclosure of any clear text data that could compromise the security of your domain.
SSL encryption is available for all communication with Oracle over the Internet and all
communication with Guardian Agents in your target domain. Note that Guardian uses 128-bit
open source encryption for SSL and that to use this level of encryption, you may need to take
additional actions to be in compliance with your countrys import requirements. If you want to
use SSL, there are three types of communication to consider:
To use SSL encryption for communication between Guardian and your target domain
during domain activation and evaluation, select the https:// communications protocol
option and specify your domains secure port in the Domain Activation Wizard.
Guardian Security (continued)
To use SSL encryption for downloading signatures from BEA Support, select Require SSL
in your Guardian Preferences. This also sets SSL encryption for uploading the signature
usage statistics.
To use SSL encryption for opening support cases with Oracle Support, select Require SSL
in your Guardian Preferences.
Using a Proxy Server
Proxy between
Guardian client and
domains.
1
3
2
Select proxy during

domain activation.
Using a Proxy Server

The Preferences page allows you to customize the Guardian environment. Select Preferences
from the Window menu. The Preferences page is a dialog box that allows you to select from
categories.
The following steps describe how to add a proxy server for Guardian to use when activating or
modifying a domain:
1. Click Add Proxy Servers in the Domain Activation Wizard or click Add in the Guardian >
Proxy category of the Preferences page.
2. In the Proxy Properties dialog box, enter the proxy servers host name, listen port,
username, and password. Click OK to add the proxy server to the proxy servers list on the
Proxy Servers page.
3. Click Add for as many proxy servers as you need to add. Click OK to return to the Domain
Activation Wizard or the Preferences page. When you use the Domain Activation Wizard
or the Domain Properties dialog box later, you can select from any of the proxy servers
that you just added.
Guardian from the Command Line
Use the guardianHeadless.cmd/sh file to help script the

following Guardian tasks:
Activating or deactivating a domain
Evaluating a domain against a signature bundle
Creating and executing an evaluation shortcut
?
General Guardian command-line syntax:
guardianHeadless g<command> -data <workspaceDir> <additionalArgs>
1
011
Guardian from the Command Line

You can access the Guardian Command Line Interface with a Windows Command Prompt
window or a Linux terminal window. The Guardian command interpreter is an executable .cmd
batch file for Windows and a .sh shell script for Linux. Both the Windows batch file and the
Linux shell script are wrappers that accumulate and organize arguments to the underlying Java
application. Run the guardianHeadless.cmd (for Windows) or the
guardianHeadless.sh (for Linux) executable file located in the installation directory that
you specified when you installed Guardian.
If you have not previously set your Guardian Workspace location when starting the Graphical
User Interface, the Guardian Command Line Interface uses a default Guardian Workspace
location, unless you specify otherwise in each command. The default Guardian Workspace
location is in your home directory, for example, C:\Documents and Settings
\<username>\guardianWorkspace on Windows.
The Guardian Command Line Interface accepts a variety of commands that perform almost
every task available within the Graphical User Interface. To see a list of the commands that are
available and their syntax, enter guardianHeadless -ghelp. Note that the Guardian
Command Line Interface commands are case-sensitive.
The output of each command is not sent to the console window by default. Instead, it is
redirected to the output file, headless_output.txt. This output file is created in your
THESE current directoryARE
eKIT MATERIALS andFOR
is overwritten
YOUR USE INeach time
THIS you run the
CLASSROOM script.
ONLY. COPYING eKIT MATERIALS FROM THIS
Summary
In this appendix, you should have learned to:

List the features of Guardian
Install Guardian and initialize a workspace
Inventory and evaluate domains to detect potential
problem signatures
Create a support case using Guardian
Index
A
Administration Console 1-30, 1-32, 1-33, 1-40, 1-42, 1-59, 2-4,
2-11, 2-12, 2-29, 2-34, 2-40, 2-42, 2-43, 2-48, 2-52, 2-55, 2-65,
2-76, 2-77, 2-78, 2-79, 2-80, 2-82, 2-84, 2-91, 2-92, 2-95, 2-96,
2-98, 2-101, 2-110, 2-113, 2-116, 2-121, 2-127, 2-128, 2-130, 2-131, 3-4,
3-5, 3-6, 3-9, 3-12
Administration Port 2-77, 2-109, 3-67, 3-74, 3-75, 3-76, 3-77,
3-78, 9-81
Administration Server 1-26, 1-27, 1-30, 1-31, 1-32, 1-33, 1-34,
1-35, 1-36, 1-38, 1-40, 1-42, 1-57, 1-59, 2-4, 2-5, 2-6, 2-7,
2-12, 2-14, 2-18, 2-29, 2-34, 2-35
Application Deployment 2-7, 2-76, 2-84, 2-116, 4-16, 4-29, 4-49,
4-54, 10-7, 10-8, 10-10, 10-20, 14-5
Auto deployment 4-29
B
Boot Identity 2-49, 2-50, 2-129, 3-18
C
Cluster 1-22, 1-30, 1-33, 1-34, 1-36, 1-37, 1-38, 1-39, 1-58,
1-60, 2-4, 2-5, 2-6, 2-7, 2-9, 2-12, 2-15, 2-16, 2-17, 2-18,
2-46, 2-57, 2-76, 2-81, 2-85, 2-93, 2-108, 2-110, 3-4, 3-5, 3-37,
3-66, 3-68, 4-21, 4-34, 4-35, 4-36, 4-44, 4-61, 4-64, 5-13, 6-17,
6-23, 6-29, 7-20, 7-22, 7-23, 7-28, 7-31, 7-40, 8-20, 8-21, 9-79,
10-5, 10-6, 10-15, 10-33, 11-1, 12-1, 12-2, 13-1, 13-2, 14-1, 14-2, 15-1, 15-2
Configuration Wizard 1-32, 1-53, 2-7, 2-8, 2-9, 2-12, 2-14,
2-17, 2-20, 2-21, 2-27, 2-35, 2-37, 2-40, 2-42, 2-49, 2-60, 2-61,
2-62, 2-65, 2-71, 2-72, 2-101, 2-119, 2-121, 2-127, 3-28, 3-40, 11-37,
12-13, 12-14, 12-24, 12-25, 12-31, 12-34, 12-35
Connection Pool 2-21, 2-114, 6-6, 6-9, 6-14, 6-20, 6-21, 6-22,
6-23, 6-25, 6-28, 6-32, 6-40, 6-41, 6-44, 7-7, 7-38, 13-28, 13-29,
13-30, 13-31, 15-4, 15-11
Cross-Cluster Replication 13-37, 13-38, 13-39
Oracle WebLogic Server 10g
COMPUTER R3: System
IS STRICTLY Administration Index - 2
PROHIBITED
D
Data Source 1-30, 2-9, 2-10, 2-12, 2-19, 2-20, 2-21, 2-22, 2-23,
2-24, 2-81, 4-21, 4-39, 4-42, 4-45, 6-2, 6-3, 6-5, 6-6, 6-7,
6-8, 6-9, 6-11, 6-17, 6-18, 6-19, 6-20, 6-21, 6-22, 6-23, 6-25,
6-26, 6-27, 6-28, 6-29, 6-30, 6-31, 6-32, 6-33, 6-37, 6-38, 6-39,
6-40, 6-41, 6-42, 6-43, 6-44, 7-17, 7-39, 8-26, 8-27, 8-28, 8-29,
8-30, 8-32, 10-5, 10-7, 10-32, 13-28, 13-30, 13-38, 13-39, 13-49, 15-15,
15-16, 15-17, 15-18, 15-63, C-14
Deployment Plan 4-52, 4-66, 4-76, 4-78, 4-80, 6-7, 10-2, 10-3,
10-4, 10-5, 10-6, 10-7, 10-8, 10-9, 10-10, 10-11, 10-12, 10-13, 10-14,
10-15, 10-16, 10-17, 10-20, 10-22, 10-24, 10-41, 10-44
Domain 1-15, 1-26, 1-27, 1-28, 1-29, 1-30, 1-32, 1-33, 1-34, 1-35,
1-38, 1-39, 1-40, 1-49, 1-53, 1-55, 1-57, 1-58, 1-60, 1-64, 2-2,
2-3, 2-4, 2-5, 2-6, 2-7, 2-8
Domain Log 2-6, 2-53, 2-54, 2-55, 2-76, 2-130, 3-52, 3-54, 3-60,
3-62, C-19
Domain Template 2-2, 2-3, 2-8, 2-9, 2-23, 2-37, 2-39, 2-58,
2-59, 2-60, 2-61, 2-62, 2-63, 2-64, 2-65, 2-66, 2-67, 2-71, 2-72,
2-73, 2-75, 2-101, 2-103, 2-107, 2-108, 2-119, 2-131, 2-132
E
Embedded LDAP 2-93, 2-122, 9-15, 9-18, 9-19, 9-20, 9-21, 9-29,
9-46, 9-47
F
FastSwap 4-57, 4-58
File Replication 13-12, 13-33, 13-35, 13-36
H
HttpClusterServlet 11-21, 11-22, 11-24, 11-28, 12-31, 12-32, 12-34, 12-36,
12-37, 12-38, 12-39, 12-40, 12-41, 12-54, 13-13, 13-21, 13-25
I
In-Memory Replication 4-21, 4-44, 13-11, 13-12, 13-13, 13-19, 13-20,
13-21, 13-22, 13-23, 13-25, 13-26, 13-27, 13-38, 13-49, 13-50, 15-4
Installation 1-26, 1-41, 1-44, 1-45, 1-46, 1-47, 1-48, 1-49, 1-50,
1-51, 1-52, 1-56, 2-7, 2-11, 2-18, 2-27, 2-33, 2-34, 2-35, 2-51,
2-78, 3-14, 3-17, 3-19, 3-20, 3-24, 3-29, 3-30, 3-31, 3-32, 3-33,
3-34, 4-52, 4-61, 4-64, 4-76, 6-11, 6-16, 9-33, 10-15, 10-19, 10-20,
12-4, 12-43, 12-46, 13-27, 13-36, C-5, C-6, C-7, C-8, C-24
COMPUTER R3: System
PROHIBITED
J
JDBC 1-8, 1-12, 1-14, 1-17, 1-23, 1-30, 1-53, 1-54, 2-9, 2-10,
2-12, 2-19, 2-20, 2-21, 2-22, 2-23, 2-24, 2-60, 2-65, 2-88, 2-89,
4-39, 4-41, 4-42, 4-45, 4-53, 4-75, 5-5, 6-1, 6-2, 6-3, 6-4,
6-5, 6-6, 6-7, 6-8, 6-9, 6-10, 6-11, 6-12, 6-13, 6-14, 6-15,
6-16, 6-17, 6-19, 6-20, 6-21, 6-22, 6-23, 6-24, 6-26, 6-27, 6-28,
6-29, 6-32, 6-33, 6-34, 6-35, 6-37, 6-38, 6-39, 6-40, 6-41, 6-44,
JDBC Drivers 1-53, 1-54, 2-21, 6-5, 6-11, 6-16, 6-17, 6-26, 6-37,
8-11, 8-15, 8-30, C-4
JMS 1-8, 1-14, 1-15, 1-23, 1-45, 2-9, 2-10, 2-12, 2-20, 2-25,
2-26, 2-60, 2-65, 2-88, 2-103, 2-108, 4-39, 4-41, 4-42, 4-45, 4-53,
4-75, 5-5, 5-7, 5-13, 7-1, 8-10, 8-14, 8-31, 9-48,
9-73, 10-26, 10-43, 11-5, 11-6, 11-10, 11-11, 15-2
JNDI 1-8, 1-13, 1-23, 2-21, 4-34, 4-36, 5-1, 5-2, 5-3, 5-4,
5-5, 5-6, 5-8, 5-9, 5-10, 5-11, 5-12, 5-13, 5-14, 6-6, 6-20,
6-23, 6-24, 6-25, 6-26, 6-30, 6-37, 6-38, 6-43, 7-9, 7-10, 7-19,
7-21, 7-22, 7-23, 7-25, 7-29, 7-44, 8-27, 8-28, 9-4, 9-6, 9-7,
9-27, 9-54, 10-5, 10-32, 11-10, 11-38, 11-41, 12-29, 15-2, 15-3
JTA 1-8, 1-14, 1-23, 7-11, 7-22, 8-6, 8-18, 8-19, 8-23, 8-24,
8-25, 8-26, 8-31, 8-34, 8-35, 8-36, 8-38, 8-39, 11-8, 11-10, 15-6,
15-7, 15-8, 15-20, 15-22, 15-24, 15-28, 15-29, 15-30, 15-31, 15-32, 15-33,
15-35, 15-36, 15-48, 15-56
K
keytool utility 9-52, 9-58, 9-60
L
Log Filter 3-60, 3-61, 3-62
M
Machine 1-6, 2-3, 2-5, 3-2, 3-3, 3-4, 3-5, 3-6, 3-7, 3-8, 3-9, 3-10, 3-11, 3-12, 3-13, 3-14,
3-15, 3-16, 3-17, 3-21, 3-25, 3-31, 3-32, 3-33, 3-35, 3-36, 3-37, 3-38, 3-39,
3-41, 3-42, 3-48, 3-56, 3-69, 3-77, 3-81, C-6, C-14, C-20
Managed Server 1-26, 1-30, 1-31, 1-33, 1-34, 1-35, 1-36, 1-40,
1-42, 1-57, 1-60, 2-2, 2-3, 2-4, 2-5, 2-6, 2-7, 2-9, 2-12,
2-14, 2-15, 2-17, 2-18, 2-28, 2-29, 2-39, 2-40, 2-41, 2-43, 2-44,
2-45, 2-46, 2-47, 2-48, 2-49, 2-50, 2-52, 2-53, 2-54, 2-55, 2-56,
2-58, 2-60, 2-75, 2-83, 2-93, 2-96, 2-101, 2-124, 2-125, 2-126, 2-127,
2-128, 2-129, 2-130, 2-132, 3-4, 3-5, 3-6
COMPUTER R3: System
PROHIBITED
M
Managed Server Independence 2-2, 2-3, 2-39, 2-52, 2-53, 2-54,
2-58, 2-75, 2-132, 3-6, 3-11
N
Network Channel 2-86, 3-2, 3-3, 3-49, 3-67, 3-68, 3-70, 3-71,
3-82, 4-65, 12-12, 12-15, 13-37, 13-39
Node Manager 1-36, 1-40, 1-41, 1-42, 1-60, 2-4, 2-18, 2-34, 2-35,
2-43, 2-46, 2-48, 2-50, 2-54, 2-83, 2-85, 2-130, 3-2, 3-3, 3-4,
3-5, 3-6, 3-7, 3-8, 3-9, 3-10, 3-11, 3-12, 3-13, 3-14, 3-15,
3-16, 3-17, 3-18, 3-19, 3-20, 3-25, 3-26, 3-27, 3-28, 3-29, 3-30,
3-31, 3-32, 3-33, 3-34, 3-35, 3-36, 3-37, 3-38, 3-39, 3-40, 3-41,
3-42, 3-43, 3-44, 3-45, 3-46, 3-47, 3-48, 3-76, 3-80, 3-81, 3-82,
9-52, 13-49, 15-9, 15-31
P
Persistent JDBC Replication 13-29
Production Redeployment 10-2, 10-3, 10-22, 10-24, 10-25, 10-26, 10-27,
10-28, 10-29, 10-30, 10-31, 10-32, 10-33, 10-39, 10-40, 10-44, 13-3, 13-7
Proxy Server 1-20, 1-21, 2-17, 2-77, 9-53, 11-3, 11-21, 11-24, 11-46,
12-2, 12-3, 12-9, 12-13, 12-31, 12-34, 12-35, 12-36, 12-37, 12-39, 12-54,
12-55, 13-20, 13-26, C-11, C-23
R
Replication Group 13-11, 13-15, 13-16, 13-17, 13-18, 13-22, 13-24, 13-26,
13-40, 13-49
S
Server Log 2-54, 3-46, 3-47, 3-48, 3-50, 3-51, 3-52, 3-53, 3-54,
3-56, 3-60, 3-79, 15-23, C-19
T
Transaction Log 8-3, 8-16, 8-20, 8-21, 8-22, 8-25, 15-21, 15-24,
15-25, 15-26, 15-32, 15-33, 15-35, 15-53, 15-58
W
weblogic.Deployer utility 4-54, 4-75, 7-20, 10-15, 10-16
WLST 1-32, 1-33, 1-42, 1-53, 2-8, 3-5, 3-6, 3-7, 3-8, 3-25, 3-26, 3-31,
3-32, 3-48, 3-51, 3-80, 4-54, 4-58, 4-78, 4-79, 4-80, 5-13, 6-7,
7-17, 7-18, 7-41, 8-34, 9-9, 9-30, 10-8, 10-43, 12-13, 12-14, 12-27,
C-9
COMPUTER R3: System
PROHIBITED

D56082GC10 sg3

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

D56082GC10 sg3

Încărcat de

Drepturi de autor:

Formate disponibile

Oracle University and African Legend Indigo (PTY) LTD use only

Oracle WebLogic Server 10g R3:

Volume III Student Guide

Vishal Parashar Disclaimer

This document contains proprietary information and is protected by copyright and

Editors Restricted Rights Notice

Graphic Designer U.S. GOVERNMENT RIGHTS

Publishers Trademark Notice

2 Configuring Oracle WebLogic Server Environment

3 Managing and Monitoring the Oracle WebLogic Server Environment

7 Setting Up Java Message Service (JMS) Applications

9 Securing WLS Resources and Applications

14 Clustering EJB Objects

Appendix A: Practices and Solutions

Appendix B: Virtual Host

Appendix C: Getting Started with BEA Guardian

Copyright 2009, Oracle. All rights reserved.

After completing this lesson, you should be able to do the

Copyright 2009, Oracle. All rights reserved.

Deploying Applications to Clusters

Copyright 2009, Oracle. All rights reserved.

When you deploy applications to a single Managed Server,

Copyright 2009, Oracle. All rights reserved.

Applications are deployed using two-phase deployment

Copyright 2009, Oracle. All rights reserved.

All nodes must be running before an application is

Copyright 2009, Oracle. All rights reserved.

Deploying Applications to a Cluster

When you use production redeployment of an application

Copyright 2009, Oracle. All rights reserved.

Production Redeployment in a Cluster

Copyright 2009, Oracle. All rights reserved.

Deploying Applications to a Cluster

Deploying Applications to a Cluster (continued)

Deploying Applications to a Cluster (continued)

Deploying Applications to Clusters

Copyright 2009, Oracle. All rights reserved.

Web applications use HTTP sessions to track information

Copyright 2009, Oracle. All rights reserved.

HTTP Session Failover

Oracle WebLogic Server provides clustering support for

Copyright 2009, Oracle. All rights reserved.

HTTP Session State Replication

In Oracle WebLogic Server, machine names are used to

Copyright 2009, Oracle. All rights reserved.

A replication group is a logical grouping of related servers

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Replication Groups (continued)

Select each server in a cluster and assign each a pair of

Configuring Replication Groups

The distribution of secondary sessions across cluster members

Does the server reside Is the server part of a Secondary

Copyright 2009, Oracle. All rights reserved.

Each users session always exists on two servers:

Server Server Server

Copyright 2009, Oracle. All rights reserved.

Oracle WebLogic Server uses nonpersistent cookies to

Copyright 2009, Oracle. All rights reserved.

In-Memory Replication and Proxy Servers

ServerA ServerB ServerC ServerA ServerB ServerC

Copyright 2009, Oracle. All rights reserved.

In-Memory Replication: Example