Weblogic 9 Ï Í ÜÀí

Module 1
BEA Systems, Inc.

Presents
BEA WebLogic Server 9/10: System

Administration
Course WLS-A11-100-01
Overview-1 © 2007 BEA Systems, Inc. 1

Skills Learned
 At the end of this course, you will be learn about
installing and configuring WebLogic Server 10 by:
– Setting up the WebLogic Server Environment
– Configuring a WebLogic Server Environment
– Managing and Monitoring a WebLogic Server Environment
– Understanding JNDI
– Deploying Applications
– Setting up JDBC
– Setting up JMS Applications
– Managing Transactions
– Securing WebLogic Server Resources and Applications
– Configuring and Managing a Cluster
– Clustering EJB Objects and Services
Course Topics
 The course presents:

– Core WLS concepts such as domains, machines, managed
servers and virtual hosting
– Application Deployment
– Resource management, such as JNDI, JDBC and JMS
– Security planning and implementation
– Clustering

Course Objectives
 At the end of this course you should be able to:

– Describe the architecture of WebLogic Server including
domains, servers and machines
– Install, configure and use WebLogic Server
– Perform everyday WLS system administration functions for
databases, Web sites, application deployments, security and
other services
– Set up a cluster of servers and distribute applications and
resources to the cluster
– Take advantage of cluster capabilities such as load balancing
and failover

Target Audience
 This seminar is targeted to individuals who will be:

– Administering WLS application server environment
– Deploying applications

Introductions
 Please tell us about yourself:

– Name
– Job responsibility
– Experience with BEA products and technologies, and with
Java & J2EE
– Course objectives

Course Schedule…
Session Module
1: Overview
A.M. 2: Setting up a WebLogic Server Environment
Day
1 3: Configure a WebLogic Server Environment
P.M. 4: Managing and Monitoring a WebLogic Server Environment
5: Basic Deployment
A.M.
Day 6: Understanding JNDI
2 7: Setting up JDBC
P.M.
8: Setting up JMS Applications
8: Setting up JMS Applications (Contd.)
A.M.
Day 9: Managing Transactions
3 10: Securing WebLogic Server Resources and Applications
P.M.
11: Advanced Deployment

Course Schedule
Session Module
12: Introduction to Clustering

A.M.
Day 13: Configuring a Cluster
4
P.M. 14: Managing Clusters
A.M. 15: Clustering EJB Objects

Day
5 16: Clustering Services
P.M.
17: Virtualization

Course Workshops
 During the course, you will complete various hands-on

workshops:
– Installing and configuring WebLogic Server
– Monitoring transactions in the Administration Console
– Setting up JDBC and JMS
– Setting up users, groups and policies for security
– Deploying Web, EJB and Enterprise Applications
– Setting up a cluster
– Deploying resources to a cluster
– Load balancing and failing over resources and applications in
a cluster

Module 2
Setting Up a WebLogic Server
Environment
At the end of this module you will be able to:

 Explain the motivation behind distributed systems
 List the major components of the J2EE specification
 Know the terminology used throughout the course
 Understand WebLogic Server architecture
 Install and run WebLogic Server
Setting Up a WebLogic Server Environment-1 © 2007 BEA Systems, Inc. 15

Road Map
1. Distributed Architecture
– J2EE Technologies
– Web and WLS Terms
2. Setting Up a WebLogic Server Environment

The J2EE Standard
 Java Platform 2 Enterprise Edition (J2EE) helps to

overcome distribution liabilities.
 Applications deployed with J2EE technologies are:
– Standardized
– Adherent to specification guidelines
– Written in Java
– Deployable in any compliant application server

The J2EE Architecture
WebLogic Server Directory Service

J2EE Application Server
Web Client Web Container
Servlets
EJB Container
Applet JSPs Session RDBMS

EJBs
Entity CORBA
Client
EJBs
Application
Java App
JAX-RPC
RMI-IIOP
JDBC
JAAS Message Queue
JNDI
JMS
JMX
JTA
Web Service

Java Message Service (JMS)
 JMS is a Java API for Producer Producer

accessing message-oriented
middleware.
 The interface supports:
– The point-to-point domain JMS
– The publish/subscribe domain Server
– Guaranteed message delivery Destination
– Transactional participation
– Dynamically configurable
services
– Application- or system-scoped
resources
– Interoperability with other
messaging systems Consumer Consumer Consumer

JMX
 The Java Management Extensions (JMX):

– Defines a standard infrastructure to manage a device from
Java programs
– Decouples the managed device from the management tools
 The specification describes MBeans, which are the
building blocks of JMX.
WebLogic Server
Management Tool MBeans
MBean
MBean
MBean
MBean

Proxy Server
 Forwards requests to other

machines
Server
 Can be used as a level of A
indirection and security
 Can be used to load Proxy Server
Client
balance a system Server B
Server
C

Web Server
 Web servers:
– Provide Web content
– Communicate via HTTP, FTP, and so forth
– Can handle CGI requests
– Proxy some requests to application servers
Web Server
Web
Server
HTTP HTTP
WebLogic
Server
HTTPS Plug-in HTTPS

Application Servers
WebLogic Server
 Provide services that J2EE Application Server
support the execution and
Web Container
availability of deployed
applications Servlets
EJB Container
JSPs
 Handle heavier processing Session
EJBs
chores than Web servers
Entity
EJBs
JAX-RPC
RMI-IIOP
JDBC
JAAS
JNDI
JMS
JMX
JTA

A Web App Server Configuration
Firewall
Client Firewall Web Application
Server Servers
Server
A
World
Wide WLS Server
Client
Web Plug-In B
Server
Client C
Inner Network
Your Network

An Application Server Configuration
Firewall Firewall App Server
Extranet
Client
or
App
Internet
Database
Client Local
App Client
App
Your Network

Definition: Domain
 A domain is a logically «domain»

related group of WebLogic «machine» «machine»
Server resources that you
manage as a unit. «server»
 A domain provides one «cluster»
point of administration.
«server»
 A WebLogic Server «server»
domain can logically «server»
separate:
– Development, test, and
production applications
– Organizational divisions

Why Use Domains?
 A domain is an administration feature that:

– Is transparent to applications
– Can be configured and administered, for technical or
business reasons, even after applications are developed or in
production
 WebLogic Server domains can be used to separate:
– Development, test and production applications
– Administration and operational responsibilities
– Organizational or business divisions

Definition: Server
 A server is an instance of «domain»

weblogic.Server
executing in a JVM. «machine» «machine»
«server»
 A server:
– Runs on a designated «cluster»
WLS machine
«server»
– Has a dedicated amount «server»
of RAM «server»
– Is multithreaded

Definition: Administration Server
 Is the central point of «domain»
control for a domain «machine»
 Stores the configuration «server»

config.xml
information and logs for «logs»
a domain «admin server»
 Runs the WebLogic

Administration Console «server»
«logs»
«logs»
«machine»
«server»
«logs»

Definition: Managed Server
 Is any server in a domain «domain»
that is not the admin «machine»

server
config.xml
«server»
 Contacts the admin «logs»
server for configuration «admin server»
information
 Runs business «server»
«logs»
«logs»
applications in a
«machine»
production environment
«server»
«logs»

Definition: Machine
 Is a computer that hosts «domain»

WebLogic Server(s) «machine» «machine»
 Runs a supported
«server»
operating system
platform «cluster»
 Can host multiple «server»

WebLogic Server «server»
instances «server»

Definition: Cluster
 A cluster is a logical «domain»
group of WLS servers. «machine» «machine»
 WebLogic clusters «server»

provide automatic:
– High Availability «cluster»
– Load balancing «server»

«server»
 A cluster is transparent «server»
to a client.

Section Review
In this section we discussed:

 The ways that distributed systems improve availability,
scalability, and maintainability
 The ways that standards for distributed systems
improve the cost effectiveness of software development
projects
 The J2EE architecture and many J2EE technologies
 The terms used to discuss Web architectures
 The terms used to describe WebLogic Server features

Road Map
1. Distributed Architecture
2. Setting Up a WebLogic Server Environment
– WebLogic Server Architecture
– Installing and Running WebLogic Server

WebLogic Server Installation
 You can install WebLogic Server in three different

ways:
– Graphical User Interface mode
– Console mode
– Silent mode
 The BEA installer program supports a number of
platforms including:
– Windows 2000,
2003 Server, XP
– Sun Solaris
– HP-UX
– Linux

GUI-mode Installation
Read the Welcome Screen
Accept the License

Agreement
Choose a BEA Home

Choose an Install Type
 Select the software to be installed on your system.

Select Optional Tools
 Choose the Mercury profiling tool as an option only for

the development environment.

Choose the Product Directory
 Choose the target directory for WebLogic Server 10.
Installation complete!
Console-mode Installation
 Console-mode installation is the text-based method of

executing the BEA installation program.
 A WebLogic Server installer for a UNIX platform
takes one of two forms:
– A UNIX-specific Java installer which includes JDK 1.5.0_06
• Has a filename ending in .bin
– A platform-independent Java installer without a JDK
• Has a filename ending in .jar
 The installation steps are similar to GUI-based
installation.

Post Installation: BEA Directory
Directory and Files Description
bea BEA Home directory
jdk150_06 Prepackaged 1.5.0_06 JDK/JRE
jrockit90_150_06 Prepackaged JRockit 1.5.0_06

user_projects Default location of user domains
utils Additional/utility JAR files
wlserver_10.0 WebLogic Server home directory
license.bea License file

registry.dat Record of all installed BEA products
UpdateLicense.cmd Updates license.bea file

WebLogic Directory Structure
Directory / File Description
wlserver_10.0 WLS 10 product components
common
bin
Files shared by WLS 10 components including
lib template JAR files used by the Configuration
nodemanager Wizard when creating domains
templates
samples Sample code and resources

server Server software components
bin Executables
db Oracle Database ddl files for v8.1.7 & v9.2.0
ext XML JAR files, alternative JDBC Drivers, etc
lib WebLogic Server JAR files
uninstall Code required for uninstalling WLS 10

Samples Directory Structure
samples Sample code and resources
domains Sample domains
medrec Sample domain for medrec application

wl_server Sample domain for wl_server application
workshop Sample domain for workshop application
server
docs
Source code for sample domain
examples examples installed with WebLogic Server
medrec

Section Review

 WebLogic Server product overview
 WebLogic Server installation
 The WebLogic Server directory structure

Exercise
Install BEA Software

 In this lab you will install WLS and set up your
working environment. You will also run WLS for the
first time.
 For details on the exercise, refer to the Lab Guide.
 If questions arise, ask the instructor.
 The instructor will determine the stop time.

Exercise
Set up the BEA Ed.Lab Environment


Module Review
In this module we discussed:

 Distributed architecture and J2EE technologies
 Web and WebLogic terminology
 WebLogic Server in a Web-based distributed
system
 How to install and configure WebLogic Server

Module 3
Configuring a WebLogic Server

Environment
 Configure domains, machines, and managed servers
 Start the WebLogic Server Administration Console
 Start managed servers at boot time
 Set Basic properties using the Administration Console
 Perform basic Administration from the Command Line
 Administer servers and managed servers
Configuring a WebLogic Server Environment-1 © 2007 BEA Systems, Inc. 61

Road Map
1. Configuring Domains
– How WebLogic Server Domain works
– Domain Directory Structure and Files
– Creating a Domain
2. Configuring Servers
3. Domain Templates
4. Console Administration
5. Command Line Administration

Domain Overview
 A domain is the basic administration unit for

WebLogic Server.
 A domain always includes one WebLogic Server
instance that is configured as an Administration Server.
 All other optional WebLogic Server instances in a
domain are called Managed Servers.
 A domain may also
include clusters of
server instances that
work together.

Domain Overview
Domain Cluster
Domain Log
Get Configuration
at Startup Managed
LOG Server 1
Critical Domain LOG Local Logging

Notifications
Domain Log
Messages Managed
Console Administration
Server 2
Server
LOG Local Logging
GET / SET
Managed
Monitor/
Server 3
Update
Configuration LOG Local Logging
Repository
Configuring a Domain
 After installation, you configure a WLS domain on

which to develop and deploy applications.
 When you create a domain, you define a collection of
resources, such as:
– Managed servers
– Clusters
– Database connections
– Security services
– J2EE applications
 You use the Configuration Wizard to create and
configure WLS domains.

Starting Configuration Wizard
 Scripts in <WEBLOGIC_HOME>/common/bin directory

 Graphical mode
– Windows Start menu
– [Windows] config.cmd
– [Unix/Linux] config.sh
 Console mode
– [Windows] config.cmd –mode=console
– [Unix/Linux] config.sh –mode=console

Configuration Wizard – Graphical Mode
 The graphical version of the domain configuration

wizard walks the user through each step.

Domain Directory Structure
Directory Column Head
1 domain-name The name of this directory is the name of the domain.
0 autodeploy In development mode, WLS automatically deploys any applications
or modules that you place in this directory.
0 bin The scripts for starting and stopping the Administration Server and
the Managed Servers in the domain.
0 config The current configuration and deployment state of the domain.
config.xml.
0 console-ext Console extensions.
0 init-info Domain initialization information.
0 lib JAR files added to the classpath of each server instance.
0 pending Domain configuration changes that have been requested, but not
yet activated.
0 security Domain-wide security-related files.
1 servers One subdirectory for each server in the domain.
0 server-name The server directory for the WLS instance with the same name.

JVM Run-Time Arguments
 WebLogic Server can be executed with most Java

Virtual Machines.
 WebLogic Server supports JDK 1.5.0
Syntax for running a virtual machine:

java options FullyQualifiedJavaClass ProgramOptions
Some virtual machine options:
-Xms The minimum size of the dynamic heap
-Xmx The maximum size of the dynamic heap
-Dprop=val An environment variable accessible by the
program
-classpath classpath The list of files/directories containing
dependent classes 10
0101
1110

WebLogic Server Dependencies
 To run WLS, you must configure:

– PATH to include all executable programs (including the Java
interpreter)
– CLASSPATH to include dependencies
 These parameters can be set:
– In your computer’s environment settings
– In a custom batch file or shell script
To see an exhaustive list of DOS environment properties:
set
To set a DOS environment variable:

set VAR_NAME=VALUE
10
0101
1110

Configuring Your CLASSPATH
 The WLS CLASSPATH is completely configured by

the Java system CLASSPATH environment variable.
Files that must be in the CLASSPATH:

%WL_HOME%/server/lib/weblogic.jar
Any additional service pack jar files (See release notes)
Files that can be in the CLASSPATH:

%WL_HOME%/common/eval/pointbase/lib/pbclient51.jar
%WL_HOME%/common/eval/pointbase/lib/pbtools51.jar
%WL_HOME%/common/eval/pointbase/lib/pbembedded51.jar
%WL_HOME%/server/lib/xmlx.jar
JDBC drivers
Startup classes, shutdown classes
3rd-party libraries
Other common classes 10
0101
1110

Starting WebLogic Server
 Start WebLogic Server by running the

weblogic.Server class.
Minimal syntax:
java -server –Xms256m –Xmx512m -classpath "%CLASSPATH%"
-Dweblogic.Name=%SERVER_NAME% -Dplatform.home=%WL_HOME%
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy
weblogic.Server
Arguments:
%SERVER_NAME% - The name of the server to start.
10
0101
1110

Example: Starting WLS Directly
To start WebLogic Server by hand (Windows):

java -server –Xms256m –Xmx512m -classpath "%CLASSPATH%"
-Dweblogic.Name=myServer –Dplatform.home=C:\bea\wlserver_10.0
-Dweblogic.management.username=system
-Dweblogic.management.password=weblogic
weblogic.Server
To start WebLogic using the default domain script (Windows):

c:\>cd bea\user_projects\domains\someDomain
c:\...>startWebLogic.cmd
Execute the start script

from the appropriate directory!
10
0101
1110

Initial Output
Enter password

Section Review

 How a WebLogic Server domain works
 The domain directory structure
 Domain files
 How to create a domain
 How to start WebLogic Server
from the command line

Road Map
– Configuring Managed Servers
– Starting Managed Servers
– Running Multiple WLS Instances
3. Domain Templates

Configuring Managed Servers
 Managed Servers can be configured using:

– Domain Configuration Wizard
– Administration Console
– Command Line (WLST)
1 2

Starting Managed Servers…
Domain
Domain Log Get configuration Cluster
at startup (http/https)
LOG ServerA
192.168.1.2:7001
Critical Domain
Get configuration LOG Local Logging
Notifications
at startup (http/https)
Admin Server
192.168.1.1:7001 ServerB
192.168.1.1:7002 192.168.1.3:7001
GET / SET LOG Local Logging
Get configuration Proxy

at startup (http/https) 192.168.1.4:7001
Configuration
LOG Local Logging
Repository
…Starting Managed Servers
 To start a managed server, you must:

– Specify a server name
– Specify an administration server URL from which to load
configuration information
To start a managed server:

java -server –Xms256m –Xmx512m
1 -Dweblogic.Name=%SERVER_NAME% -Dplatform.home=C:\bea\wlserver_10.0
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
2 -Dweblogic.management.server=%ADMIN_URL%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
weblogic.Server
10
0101
<startManagedWeblogic.cmd> 1110

Creating a Boot Identity File
 Create a file called boot.properties located in the

<DOMAIN_HOME>\servers\servername\security
directory containing two lines:
– username=username
– password=password
 The first time you start the server, the server reads the
Boot Identity file and overwrites it with an encrypted
version of the username and password.
 Thereafter, the server will remember your identity for
the subsequent startup cycles.

Managed Server Independence…
 By default, managed servers can function

independently of the administration server.
 You configure the Managed Server Independence
mode from the WebLogic Administration Console:

…Managed Server Independence
 If the administration server is unavailable at boot time,

managed servers search for:
– config.xml
– SerializedSystemIni.dat
– boot.properties(optional)
 Each managed server looks in its local config
directory for config.xml - a replica of the domain's
config.xml.

What If an Admin Server Is Down?
 The administration server:

– Can go down without affecting the operation of managed
servers
– Can be restarted while managed servers are still running
 When an administration server goes down:
– Domain log entries are lost while it is down
– Managed servers can start in independent mode
– The administration console and management tools are
unavailable

Administration Server Backup
 WLS allows the creation of a backup of the server as

follows:
– Install (if necessary) WLS on a backup machine
– Copy application files to a backup machine
– Copy configuration files to a backup machine
– Restart the Administration server on a new machine
 The new Administration server will contact managed
servers and inform them that it is running on a new IP
address.

Running Multiple WLS Instances
 You can run multiple instances of WLS using different

configurations on the same physical machine at the
same time by either:
– Assigning multiple IP addresses to a machine (multihoming)
and defining each server to use a unique IP address
– Specifying the same IP address but using different listen
ports

Multihoming
 A multihomed machine:
– Is a machine with multiple IP addresses
– Can run a different WLS instance bound to each IP address
– Can be used to configure a cluster on a single machine
192.168.1.1
192.168.2.2
Machine

Section Review

 How to define and start an administration server
 How to create and start a managed server
 Managed server
independence
 Administration server
backup

Road Map
3. Domain Templates
– Creating Customized Domain Templates

Custom Domain Templates
 A domain template defines the full set of resources

within a domain.
 Although BEA provides templates for creating any
platform domain, you may wish to create your own or
customize an existing template.
 The Domain Template Builder lets
you define templates:
– Define a domain and replicate it across multiple projects
– Distribute a domain packed with an application that has been
developed to run in it

Creating a Domain Template
To create a domain template:

1. Create a new template using Domain Template Builder
2. Select Configuration Template Source
3. Describe the template.
4. Add files to the Template.
5. Add SQL Scripts to the Template
6. Configure the Administration Server, Username and Password.
7. Specify Start Menu entries.
8. Review Domain Template
9. Create Template

Starting Domain Template Builder
 Using the GUI mode in Windows environment or

 Using script config_builder.cmd or
config_builder.sh under \common\bin
directory.

Create a New Template

Select Configuration Template Source

Describe the Template

Add Files to the Template
Add
script to
domain

Add SQL Files to the Template

Configure the Administration Server

Configure Administrator Username
and Password

Specify Start Menu Entries

Replacement Variables

Review Domain Template

Create Template

Domain Template Created

Section Review
In this section, we learned how to:

 Understand the benefits of using a custom domain
template
 Create a custom domain template

Exercise
Create a Domain Template


Road Map
3. Domain Templates
– WebLogic Server Administration Console
– Setting Basic Properties via the Console

Using the Administration Console
 Using the Administration Console you can:

– Configure attributes of resources
– Deploy applications or components
– Configure, collect and view diagnostic information
– Start and shut down servers or perform other management
actions

Starting the Console
 After starting the administration server, you can start

the console in the browser of your choice:
Starting the Administration Console:

http://hostname:port/console (unsecure)
https://hostname:secureport/console (secure)
hostname := The name or IP address of the administration server

port := The port number the administration server is listening on
secureport := The SSL port number the administration server is listening on
Example URLs:
http://localhost:7001/console
http://adminDNSName:7001/console
https://127.0.0.1:7002/console
10
0101
1110

Console Login
 Enter the user name and password that you set when
creating your domain.

Using the Console

Using the Administration Console…

Setting Basic Properties
 Changing the Stdout severity threshold:
2
3

Shutting Down a Server

Advanced Options in Console
 The WebLogic Server Administration Console hides

options that are not frequently used.
 To display the Advanced Options section, click
Advanced.
 If you do not want to see the Advanced Options on

the console display, click Advanced one more time.

XML Schema for config.xml
 The config.xml file adheres to an XML schema

that can be used for validation.
 config.xml aggregates configuration information
from other configuration files representing WLS
subsystems, which adhere to their own XML schemas.
 config.xml is now located (by default) in the
user_projects/domains/domain_name/con
fig folder.
 Subsidiary configuration files are located in subfolders.

Configuration Directory Structure
Directory Column Head

1 config The current domain configuration and deployment
state (config.xml).
0 configCache Cached configuration information.
1 deployments The staging area for staged applications.
0 diagnostics System modules for instrumentation in the WebLogic
Diagnostic Service.
0 jdbc System modules for JDBC.
0 jms System modules for JMS.
0 nodemanager Node Manager configuration information.
0 security System modules for the security framework.

Predictable Distribution of Domain
Configuration Changes
 Change management features of WLS enable you to

distribute configuration changes throughout a domain
securely, consistently, and predictably.
 Change management behavior is the same, regardless
of whether you are using:
– The WLS Administration Console
– The new WebLogic Scripting Tool
– JMX
 To use change management, use the Change Center
region in the WLS Administration Console.

The Configuration Change Process
 WLS configuration change management process loosely
resembles a database transaction.
 The domain configuration is represented two ways:
– On the file system by a set of XML configuration files, centralized in the
config.xml file
– At run time by a hierarchy of Configuration MBeans
 When you edit the domain configuration, you edit a separate
hierarchy of Configuration MBeans that resides on the
administration server.
 When you activate changes, it's a 2-phase commit (2PC) process:
– Each server determines whether it can accept the change.
– If all servers are able to accept the change, they update their working
configuration hierarchy and the change is completed.

Configuration Management
Architecture
Administration Server Managed Server
edit read read
File-based distribution
using Administration
Config.xml channel Config.xml
Edit works
on separate • Simple beans (not remote)
copy of files • File-based change distribution
• Separation of edit and activation

Section Review
In this section we discussed how to:

 Start the WLS Administration Console
 Set basic properties using the console

Exercise
Using the Administration Console

 In this lab you will configure and stop WLS using the
console.
 Ask the instructor for any clarification.
 The instructor will
determine the stop time.
Lab Exercise

Road Map
3. Domain Templates
– Managing WebLogic Server via the Command Line
WLST Tool

The WebLogic Scripting Tool (WLST)
 Command-line tools are useful:

– For automating administration using scripts
– As an alternative to the administration console
 WLST provides a command-line interface that:
– Configures WLS instances and domains
– Manages and persists WLS configuration changes
 WLST enables you to:
– Retrieve domain configuration and run-time information
– Edit the domain configuration and persist the changes in
config.xml
– Automate configuration tasks and application deployment

Built on Jython
 Jython advantages include:

– 100% pure Java implementation of Python
– Simple and clear syntax
– Fast and reliable
– Highly extensible (create your own commands, use any
existing Java classes)
 WLST interprets commands in two ways:
– Interactively, supplied one-at-a-time from a command
prompt
– In a batch supplied in a file (script) or embedded in your Java
code

Online and Offline Modes
 Online (connected to a running server):

– WLST provides simplified access to MBeans.
– You can perform administrative tasks and initiate WLS
configuration changes while connected to a running server.
 Offline (not connected to a running server):
– WLST limits access to only persisted configuration
information.
– You can create a new domain or update an existing domain
without connecting to a running WLS—this functionality
resembles that of the Configuration Wizard.

Modes of Operation
 Interactive
– When you enter a command in the WLST console and view
the response immediately
 Script
– When you create a text file with the .py extension that
contains a series of WLST commands
 Embedded
– When you instantiate an instance of the WLST interpreter in
your Java code and use it to run WLST commands

Simplified Command-Line Access
 WLST includes the capabilities of:

– weblogic.Admin (deprecated in 9.X)
– weblogic.Deployer
– wlconfig Ant tasks
– Configuration wizard (silent mode)
 It allows you to navigate the WLS MBean tree like a file system.
 To access WLST:
– In a non-secure environment, use: java weblogic.WLST
– In a secure environment, use:
java -Dweblogic.security.SSL.ignoreHostnameVerification=true
-Dweblogic.security.TrustKeyStore=DemoTrust weblogic.WLST

Setting Environment
 Install and configure the WebLogic Server software.

 Add WebLogic Server classes to the CLASSPATH
environment variable.
– DOMAIN_HOME\bin\setDomainEnv.cmd can be used
to set this
 Add WL_HOME\server\bin to the PATH
environment variable.

WLST Example

WLST Command Requirements
 Use case sensitive names and arguments of commands.
 Use arguments enclosed in single or double quotes.
 Precede the quoted string by r while specifying backslash (\) in a
string.
– Example: readTemplate(r'c:\mytemplate.jar')
 Note these invalid characters in object names while using WLST
offline:
– Period (.)
– Forward slash (/)
– Backward slash (\)
 You cannot access security information through WLST while
updating a domain.
 Display help
– Example: wls:/mydomain/serverConfig> help(‘disconnect’)

Running Scripts
 WLST incorporates two Jython functions that support

running scripts:
– java weblogic.WLST filePath.py, which invokes WLST and
executes a script file in a single command
– execfile(―filePath.py‖) which executes a script file after you
invoke WLST

Import WLST as a Jython Module
1) Invoke WLST:
c:\>java weblogic.WLST
wls:/offline>
2) Use the writeIniFile command to convert WLST
definitions and method declarations to a .py file:
wls:/offline> writeIniFile("wl.py")
3) Open a new command shell and invoke Jython
directly by entering the following command:
c:\>java org.python.util.jython
4) Import the WLST module into your Jython module
using the Jython import command:
>>>import wl
5) Now you can use WLST methods in the module. For
example, to connect WLST to a server instance:
wl.connect('username','password')

Exiting WLST
Exit WLST:
wls:/mydomain/serverConfig> exit()
Exiting WebLogic Scripting Tool ...
c:\>

Some WLST Commands…
Command Description Syntax
connect(‘weblogic’,
connect Connects to a server ’weblogic’,
instance (online mode) ’t3://localhost:7011’)
disconnect Disconnects from a server disconnect()

instance (online mode)
exit Exits WLST (online mode) exit()
Opens an existing domain readDomain('c:/bea/user_pro

readDomain
for updating (offline mode) jects/domains/onlinestore')
Updates and saves the
updateDomain current domain (offline updateDomain()
mode)

…Some WLST Commands
Command Description Syntax

Start a managed server instance start('mycluster',
start
or a cluster (online mode) 'Cluster')
Suspends a running server suspend(‘mainserver’)
suspend (online mode)
Gracefully shuts down a WLS
shutdown(‘myCluster’,
shutdown instance or a cluster (online ’Cluster’)
mode)
startServer(‘adminserver’,
Starts the administration server ’humanresources’,
startServer
(offline mode) ’t3://localhost:7011’)
Resumes a server that is in the resume(‘mainserver’)
resume
ADMIN state (online mode)

Section Review

 Managing WebLogic Server from the command line

Exercise
Using Command-line Administration

 In this exercise you are going to gain experience using
the command-line administration utility.
Lab Exercise

Module Review

 The WebLogic Server Administration Console
 Domain concepts
 How to create domains
 How to create and start
the Administration server and
managed servers
 The creation and use of domain
templates

Module 4
Managing and Monitoring a WebLogic
Server Environment
 Understand machines and Node Manager
 Describe simple logging
 Use commands to get attributes from an MBean
 Explain basic SNMP concepts
 Configure the WLS SNMP agent
 Use the WLS SNMP management command-line
tools
Managing and Monitoring a WLS Environment-1 © 2007 BEA Systems, Inc. 139
Road Map
1. Remote Administration
– Configuring Machines
– Node Manager
– Configuring Node Manager
2. Logs and Monitoring
3. SNMP Concepts
4. WLS SNMP Agent
5. WLS SNMP Management Tools
6. Network Channels
Node Manager
 Node Manager (NM):

– Lets you start and kill managed servers remotely: one server,
a domain, a cluster
– Is available as either a Java-based or (for UNIX or Linux) a
script-based process.
– Monitors and acts on server health
– Runs on the same computers as the managed servers
– Can be run automatically in the background, as a Windows
service or a Unix daemon
What Node Manager Can Do
 You can use Node Manager to:

1. Start, Shut Down, and Restart an Administration Server.
2. Start, Shut Down, Suspend, and Restart Managed Servers.
3. Automatically Restart Administration and Managed Servers
on failure.
4. Monitor Servers and collect log data.
Node Manager Architecture
Machine A
WLST Node Admin
Manager Console
JMX
Client Admin
Server
Node
Node
Manager
Manager
Managed
Managed
Server 1 Secure Server 2
Machine C Connection
Machine B
How Node Manager Starts an
Administration Server
1. Issues command
to start 4. NM creates
Admin Server Node process for AS
Admin
WLST
Manager Server
3. NM obtains
startup properties
for AS
5. AS obtains
domain
2. NM determines configuration
domain directory,
authenticates user
Machine A
How Node Manager Starts a Managed
Server
1. Issues command
to start MS1 Admin
Admin
Console Server
4. MS1 obtains
configuration
Machine A
Managed 3. NM creates
Server 1 MS1 process
5. MS1 caches 2. AS invokes NM,

configuration Node provides startup
Manager properties
Machine B
How Node Manager Restarts an
Administration Server
3. NM creates
AS process Admin
Server
Node 1. NM determines
Manager AS needs restart
4. AS
2. NM obtains remote obtains domain
start username/ configuration
password,startup
properties for AS
Machine A
How Node Manager Restarts a
Managed Server
4. MS1 obtains Admin

configuration Server
Machine A
3. NM creates
Managed
MS1 process
Server 1
(5. If AS is not Node 1. NM determines

Available, MS1 obtains MS1 needs restart
Manager
cached configuration)
2. NM obtains remote
start username/password,
startup properties for MS 1
Machine B
How Node Manager Shuts Down a
Server Instance
Machine A
1. User issues shutdown
Admin Command for MS1 Admin
Console Server
Machine B
2. AS tries to 3. AS sends
Shut down shutdown
MS1 Operating command
System` for MS1 to
NM
5. Kill MS1 4. NM tries to
Managed shut down MS1
Server 1 Node
Manager
Versions of Node Manager
 There are two versions of Node Manager

1. Java-Based Node Manager
2. Script-Based Node Manager
 Java-based Node Manager runs within a Java Virtual
Machine (JVM) process
 Script-based Node Manager (used only for UNIX and
Linux systems)
– Script-based does not have as much security, but provides
the ability to remotely manage servers over a network using
Secure Shell (SSH).
Node Manager Configuration
 NM must run on each computer that hosts WLS

instances that you want to control with NM.
 You should configure each computer as a machine in
WLS, and assign each server instance to be controlled
by NM to the machine it runs on.
 NM should run as an operating system service, so that
it automatically restarts upon system failure or reboot.
Node Manager Default Behaviors
 After WebLogic Server installation, Node Manger is

“ready-to-run” if the Node Manager and
Administration Server are on the same machine.
 By default, the following behaviors are configured:
– The administration console can use the Node Manager to
start managed servers.
– Node Manager monitors the Managed Servers that it started.
– The automatic restart of Managed Servers is enabled.
Configuring Java-Based Node Manager
 BEA recommends configuring NM to run as an

operating system service.
 Configuration tasks for Java-based Node Manager
include:
– Reconfiguring startup service for Windows installation
– Daemonizing Node Manager for UNIX systems
– Configuring Java-based Node Manager security
– Reviewing nodemanager.properties
– Configuring Node Manager on multiple machines
Reconfigure Startup Service for
Windows Installation
1. Delete the service using uninstallNodeMgrSvc.cmd.

2. Edit installNodeMgrSvc.cmd to specify NM‟s
Listen Address and Listen Port.
3. Run installNodeMgrSvc.cmd to reinstall NM as a
service, listening on the updated address and port.
Daemonizing NM for UNIX Systems
1. Remove NM daemon process setup from WLS installation.

2. Reinstall NM daemon.
3. Configure NM:
– Set WL_HOME
– Set NODEMGR_HOME
– Add JDK and WL directories to system path
– Add JDK and WL jars to classpath
– Set LD_LIBRARY_PATH
– Set JAVA_VM
– Set NODEMGR_HOST
– Set NODEMGR_PORT
– Set PROD_NAME=BEA WebLogic Platform 10
Configuring Java-Based Node Manager
Security
 NM Security relies on a one-way SSL connection

between client and server.
 WLST uses the nmConnect command to establish a
connection to the Java Node Manager.
 The nmConnect command requires a username and
password, which is verified against the
nm_password.properties file.
Administration Console NM Security
Remote Server Start Security for Java-
Based Node Manager
 Credentials for Managed Servers and Administration

Servers are handled differently.
– Managed Servers – When you invoke NM to start a Managed
Server, it gets its remote username and password from the
Administration Server.
– Administration Servers – When you invoke NM to start an
Administration Server, the remote start username come from
either the command-line or the boot.properties file.
Reviewing nodemanager.properties
 You can specify properties for a Java-based Node

Manager process either at the command line or in the
nodemanager.properties file.
 Values supplied on the command line take precedence
over those in the nodemanager.properties file.
 To configure the Node Manager to use a start script, in
the nodemanager.properties file:
1. Set the StartScriptEnabled property to true.
2. Set the StartScriptName property to the name of your
script.
Configuring Node Manager on Multiple
Machines
 Node Manager has to be installed and configured on

each machine on which there is a Managed Server.
 You can do this with the WLST nmEnroll command
to copy all required domain and configuration
information from one machine to another.
nmEnroll([domainDir], [nmHome])
 This command downloads the following files from the
Administration Server:
– nm_password.properties, which contains the
encrypted username and password that is used for server
authentication
– SerializedSystemIni.dat file
Configuring Script-Based Node
Manager
 The SSH Node Manager is a shell script,

wlscontrol.sh, located in
NM_HOME/common/bin.
 An executable SSH client must reside on each machine
where Node Manager or Node Manager client runs.
– An SSH client is typically a standard part of a Unix or Linux
installation.
 Configuration tasks for a script-based Node Manager
include:
– Using SSL with Script-based Node Manager
– Creating a Node Manager user
– Configuring script-based Node Manager security
Using SSL with Script-based NM
 Script-based Node Manager communicates with

Administration Servers and Managed Servers using
one-way SSL.
 The default WLS installation includes demonstration
Identity and Trust keystores that allow SSL to be used
out of the box.
 To configure SSL for the production environment,
identity and trust must be obtained for the Node
Manager, the Administration Server, and all Managed
Servers.
Creating a Node Manager User
 Before running Node Manager, you should create a

dedicated UNIX user account for performing Node
Manager functions.
 You should add this user to all machines that will host
the SSH Node Manager and to all machines that will
host a Node Manager client, including the
Administration Server.
Configuring Script-based Node
Manager Security
 The Node Manager SSH shell script relies on SSH

user-based security to provide a secure trust
relationship between users on different machines.
 Authentication is not required.
 You create a UNIX user account – typically one per
domain – for running Node Manager commands and
scripts.
 A user logged in as this user can issue Node Manager
commands without providing a username and password.
Additional Configuration Information
 Other Node Manager configuration tasks include:

– Configuring a machine to User Node Manager
– Configuring nodemanager.domains file
– Configuring remote startup arguments
– Ensuring that the Administration Server address is defined
– Setting Node Manager environment variables
Configuring a Machine to Use Node
Manager
 A WLS Machine resource maps a machine with the

server instances it hosts.
Configuring the nodemanager.domains
File
 The nodemanager.domains file specifies the domains

that a Node Manager instance controls.
 When a user issues a command for a domain, NM
looks up the domain directory from this file.
 nodemanager.domains provides additional security
by restricting Node Manager client access to the
domains listed in this file.
Configuring Remote Startup
Arguments
Ensuring Administration Server
Address Is Defined
 You must define a Listen Address for each

Administration Server that will connect to the Node
Manager process.
Setting Node Manager Environment
Variables
Environment Description
Variable
JAVA_HOME Root directory of JDK that you are using for Node Manager. For example:
set JAVA_HOME=c:\bea\jdk1.5.0_06
Node Manager has the same JDK version requirements as WebLogic Server.
WL_HOME WebLogic Server installation directory. For example:

set WL_HOME=c:\bea\wlserver_10.0
PATH Must include the WebLogic Server bin directory and path to your Java executable. For example:
set PATH=%WL_HOME%\server\bin;%JAVA_HOME%\bin;%PATH%
LD_LIBRARY_ For HP UX and Solaris systems, you must include the path to the native Node Manager libraries.
PATH Solaris example:
(UNIX LD_LIBRARY_PATH:$WL_HOME/server/native/solaris:$WL_HOME/server/lib/solaris/oci816_8
only) HP UX example:
SHLIB_PATH=$SHLIB_PATH:$WL_HOME/server/native/hpux11:$WL_HOME/server/lib/hpux11/oci816_8
CLASSPATH You can set the Node Manager CLASSPATH either as an option on the java command line used to start Node
Manager, or as an environment variable.
Windows example:
set CLASSPATH=.;%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar
Node Manager Configuration and Log
Files
Server configuration files:

boot.properties
startup.properties
Node manager configuration files: Server state files:
nodemanager.properties server_1.lck
nodemanager.hosts server_1.pid
nodemanager.domains server_1 server_1.state
nm_data.properties Server log files:
server_1.out
Node
Manager
Server configuration files:
boot.properties
Node manager log files startup.properties
nodemanager.log
Server state files:
server_2.lck
server_2.pid
server_2 server_2.state
Server log files:
server_2.out
Node Manager Configuration and Log
Files
 Node Manager config files include:

– nodemanager.properties
– nodemanager.hosts
– nodemanager.domains
– nm_data.properties
– nm_password.properties
– boot.properties
– startup.properties
– server_name.lck
– server_name.pid
– server_name.state
 Node Manager log files include:
– nodemanager.log
– server_name.out
Section Review

 The way to create a machine definition
 The way to target servers to a machine
 The benefits of Node Manager
 The steps to setting up Node Manager
Exercise
Configuring Servers and Machines

 In this lab you are going to create and configure two
machines.
Lab Exercise
Exercise
Starting Servers Using Node Manager

 In this lab you will use Node Manager to control
managed servers.
Lab Exercise
Road Map
– Using Log Files
– Monitoring Servers
3. SNMP Concepts
4. WLS SNMP Agent
6. Network Channels
Using Logs
 Logs can aid in the discovery of:

– Frequently accessed resources
– Activity by day and time interval
– The amount of data sent and received
– The IP addresses of users accessing the site
– The number of actual “hits”
– The problems servicing requests
– Performance statistics
Main Server Logs
 A server log:
– Logs all server activity
– Is stored in serverName\logs\<serverName>.log
by default
 A domain log:
– Logs all domain activity
– Is stored in
<AdminServer>\logs\<domainName>.log
by default
 These logs are independently configured.
Configuring Server Logging
Messages Forwarded to Domain Log
Forwarded to
Severity Domain Log Meaning
by Default
Trace No Used for messages from the Diagnostic Action Library.
Info No Used for reporting normal operations.
Notice Yes An informational message with a higher level of importance
A suspicious operation or configuration has occurred but it
Warning Yes
may not have an impact on normal operation.
A user error has occurred. The system or application is able
Error Yes to handle the error with no interruption and limited
degradation of service.
A system or service error has occurred. The system is able
Critical Yes to recover but there might be a momentary loss or
permanent degradation of service.
A particular service is in an unusable state while other parts
of the system continue to function. Automatic recovery is
Alert Yes
not possible; the immediate attention of the administrator is
needed to resolve the problem.
The server is in an unusable state. This severity indicates a
Emergency Yes
severe system failure or panic.
Debug Yes A debug message was generated.
Message Attributes…
####<May 2, 2007 2:42:36 PM EDT> <Notice> <Security> <Ivory05>
<AdminServer> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
<1178131356062> <BEA-090078> <User johndoe in security realm myrealm
has had 5 invalid login attempts, locking account for 30 minutes.>
Attribute Description
The time and date when the message originated, in a format that is
Timestamp
specific to the locale.
Indicates the degree of impact or seriousness of the event reported by the
Severity
message.
This attribute denotes the particular subsystem of WebLogic Server that
Subsystem
was the source of the message, for example, EJB, RMI, JMS.
These attributes identify the origins of the message.

•Server Name is the name of the WebLogic Server instance on which the
Machine Name message was generated.
Server Name •Machine Name is the DNS name of the computer that hosts the server
Thread ID instance.
•Thread ID is the ID that the JVM assigns to the thread in which the
message originated.
…Message Attributes
User ID The user from the security context when the message was generated.
Transaction ID Present only for messages logged within the context of a transaction.
Diagnostic Context information to correlate messages coming from a specific request or
Context ID application.
Raw Time Value The timestamp in milliseconds.
A unique six-digit identifier. Message IDs through 499999 are reserved for
Message ID
WebLogic Server system messages.
For WebLogic Server messages, this contains the Short Description as
Message Text defined in the system message catalog. For other messages, this is text
defined by the developer of the program.
Log Filters
 Log filters provide control over the log messages that

get published.
– You can filter out messages of a certain severity level, from a
particular subsystem, or according to specified criteria
 You can create separate filters for the messages that
each server instance writes to:
– Its server log file
– Standard out
– Memory buffer
– Domain-wide log
Creating Log Filters
3
4
Assigning a Log Filter
Message Catalog
 Message catalogs are available in HTML format on e-

docs as part of the documentation deliverable. You can
search for messages by error number using the search
engine.
Message Catalog
Using the Console to Monitor
 The Administration Console offers some monitoring

capabilities:
Many of the Console’s objects have a Monitoring
tab that allows you to view monitoring
information for that object.
The monitoring view can be customized by

clicking Customize this table…
Monitoring Running Servers
Customizing views
 Columns can be customized on views.
Monitoring Individual Servers
Section Review

 Using log files
 Monitoring servers
Road Map
3. SNMP Concepts
– Architecture, MIB, OID
– SNMP Agent
– Trap Notifications
– SNMP Features of WLS
4. WLS SNMP Agent
6. Network Channels
SNMP
 The Simple Network Management Protocol (SNMP) is

a protocol for managing distributed devices.
 Examples of devices include:
– Bridges
– Routers
– Servers
– Printers
SNMP Architecture
 SNMP works by monitoring devices through software

known as agents.
 Agents report information to a manager:
– On demand (polling)
– Automatically (traps)
MIBs
Agent Management
Console
Managed
Device
Management Information Base (MIB)
 A “managed object” is a value that can be monitored

by an Agent.
 A MIB is a file that:
– Contains a list of these objects
– Is related to a single device type
– Is used by the manager to:
• Determine the available objects that can be polled
• Make sense of values returned by trap notifications
SNMP Polling
Management
Console SNMP polling
MIBs is done on
UDP port 161.
1 Manager "polls" for a
specific managed
object (asks for value)
4
Agent returns
data to requestor 2 Agent interacts Managed
with device to get Device
Agent requested data
Data is
3 returned to agent
SNMP Traps
Management SNMP traps

Console
MIBs are sent on
UDP port 162.
1 Manager is 2 Custom trap

registered to events may
the agent be defined
Managed
Agent
Device
3 Agent
4 monitors the
Alert generated
events
OIDs
.1
 Each managed object is represented by an
identifier, called the Object IDentifier (OID). .2 .3
 The OIDs:
.6
– Are represented as dot-separated integers
(for example: .1.3.6.1.4.1.140 …) .0 .9
– Are hierarchical .1
– Refer to single objects (leaf) or groups (branches)
.4
.1 .8
.140
The Root for WLS OIDs
 The base for all objects in WLS is:

.1.3.6.1.4.1.140.625
 All WLS SNMP objects are located on some
hierarchical level under the root, for example:
To know the current operating system, you can query the
managed object jvmRuntimeOSName, located under the
OID .1.3.6.1.4.1.140.625.340.1.45
WebLogic Server 10.0 MIB Reference
 You can look up the available managed objects and

their OIDs online:
– http://e-docs.bea.com/wls/docs100/snmp
 You can locate the OID root for an object and write it
down.
 Your SNMP manager tool can then use this OID root
to poll objects under it.
WebLogic Server 10.0 MIB Reference
WLS SNMP Support
 WLS provides an SNMP Agent that:

– Provides monitoring capability to SNMP managers
– Generates standard and user-defined trap notification sent to
registered managers
– Runs inside the administration server (weblogic.Server)
– Doesn‟t support the SET operation
WLS SNMP Architecture
Request
SNMP
 The WLS SNMP Managemet
Response SNMP Service
(SNMP Agent)
Agent: Station Traps
– Caches its data GET

and refreshes the Cache Proxy
cache regularly
Admin Server
– Has the ability to
proxy other Request Response
SNMP agents Non-WLS
SNMP
Agent
Admin Server Host
GET GET
Managed Managed
Server Server
WLS Managed Objects
 The WLS MIB supports polling for hundreds of

managed objects, for example:
– Domain, Web server, clustering
– Deployment
– Applications (enterprise, EJB, Web)
– Execute queues
– JDBC, JMS, JTA services
– JVM information
WLS Traps
 The WLS MIB defines standard trapping notifications

for:
– Server start
– Server shutdown
– MBean attribute changed
– Logging notification
– MBean monitoring notification (gauge, string, counter)
 The last three allow user-defined trap notifications
monitored by the agent.
SNMP and WLS MBeans
 In WLS, SNMP and MBeans are closely related

because:
– Internally, managed objects map to MBean attributes
– User-defined traps test MBean attributes for certain
conditions
MBeans MIB
WLS SNMP Management Tools
 WLS comes with command-line management utilities

that can:
– Poll information (one managed object, or all of them under a
branch)
– Alert the user of all trap notifications
– Generate trap events for testing
SNMP Vendors
 Some SNMP management systems compatible with

WLS 10 include:
– IBM Tivoli
– HP Openview
– Sun Domain/SunNet/Site Manager
– CA Unicenter
Section Review

 SNMP definitions:
– Agent
– Manager
– Managed object
– MIB
– OID
– Polling
– Traps
 WLS support for SNMP
Road Map
3. SNMP Concepts
4. WLS SNMP Agent
– Activating the SNMP Agent
– Registering Managers to Receive Traps
– Setting Up Traps
6. Network Channels
Turning On the WLS SNMP Agent
Restart the server!
Registering Managers for Traps
Creating User-Defined Traps
Section Review

 Configuring the WLS SNMP Agent
 Registering managers to receive traps
 Setting up custom traps
Road Map
3. SNMP Concepts
4. WLS SNMP Agent
– Overview
– Using snmpwalk and snmptrapd
6. Network Channels
SNMP Tools
 WebLogic Server supports five testing tools for testing

SNMP:
– snmpwalk: return all data using SNMP GET and
GETNEXT request for tabular data.
– snmptrapd: receive and dump SNMP traps.
– snmpv1trap: generate a test SNMP trap.
– snmpget: return information from an agent using SNMP
GET.
– snmpgetnext: return information using SNMP GETNEXT.
Getting All Objects In a Branch
 snmpwalk traverses all managed objects in a branch

and writes them out.
Syntax:
java snmpwalk [-p <port>] [-c <community>] <host> <OID>
Arguments:
port The port for the trap notifications; see agent‟s configuration. The default is 161.
community The password-like identifier that this manager tool will use. The default is „public.‟
host The address of the agent to poll.
OID The full numeric object identifier of the branch to traverse.
10
0101
1110
Listening to Trap Notifications
 snmptrapd listens to trap notifications from an agent

and displays them.
Syntax:
java snmptrapd [-p <port>] [-c <community>]
Arguments:
port The port for the trap notifications; see agent‟s configuration. The default
is 162.
community The password-like identifier which this manager tool will use. The
default is „public‟.
10
0101
1110
Example: Polling an Object
OID root for jvmRuntimeOSName
“Complete” OID
Value of this object
Example: Catching a Trap
WLS has started
A server has started
Section Review

 WLS-provided SNMP management tools
 The use of snmpwalk and snmptrapd
Exercise
Using SNMP with WebLogic Server

 In this lab you will set up SNMP managers, agents and
trap destinations.
Lab Exercise
Road Map
3. SNMP Concepts
4. WLS SNMP Agent
6. Network Channels
– Addressing Features
– Administration Port
Network Addressing Features…
 Adds flexibility to networking configuration:

– Multiple NICs for a single WLS server.
– Specific NICs or multiple port numbers on a NIC for specific
WLS servers.
– Multiple IP addresses can be used with each server.
– A single IP address can be used with multiple ports.
– The ability to configure the cluster multicast port number
independently of the port numbers used by cluster members.
– Multiple SSL configurations on one server.
…Network Addressing Features
 Adds flexibility to networking configuration:

– Administration traffic only port
– Interoperability with previous WLS versions
Machine Machine
Default Channel
NIC1 Server A NIC1
Channel 1
Server C
Default Channel
NIC2 Server B NIC2
Channel 2
Network Channels
 Network channels:
– Define a set of basic attributes of a network connection to
WLS.
– Can assign multiple channels to a single server (segment
network traffic).
– Can prioritize internal (non-URL) connections.
– Can separate incoming client traffic from internal server to
server traffic in a domain.
• “Default” channel gets generated when a server is created.
Configuring Network Channels
Using Channels Example 1
Server A
 Multiple NICs per server NIC_A1
StandardChannel 192.168.1.100 8001
– Each server has 2 NICs.
NIC_A2
– Each NIC has one channel, SecureChannel 192.168.1.101 8002
hence there are 2 channels per server.

– Types of channels
• StandardChannel Server B
NIC_B1
– Enables HTTP
StandardChannel 192.168.1.200 8001
– Disables other protocols
NIC_B2
• SecureChannel SecureChannel 192.168.1.201 8002
– Enables HTTPS
– Disables other protocols
Using Channels Example 2
 Separate Internal and External traffic:

– AppChannel is common between servers
• Used for internal communications
• OutgoingEnabled attribute is enabled
– ClientChannel is used for external access
• Clients can only connect to public IP address 192.168.1.100
• OutgoingEnabled attribute is disabled
Client
Edge Server Support Server
Servlet EJB
NIC
ClientChannel 192.168.1.100
NIC NIC
192.168.1.105 AppChannel AppChannel 192.168.1.200
Administration Port…
 WLS allows configuration of a dedicated

administration port:
– Accepts only secure, SSL traffic.
• All connections via the port require authentication by a server
administrator.
– Generates an Administration channel.
– Specifies that channel settings are as the default channel
except if:
• Separate SSLListenPort value is defined
• Non-SSL ListenPort is disabled
– Allows only admin traffic from the Administration Console,
weblogic.Admin, and Managed Servers
– Enables to start the server in Standby mode
…Administration Port
Override Administration Port
Section Review

 Network channels
 Administration port
Exercise
Configuring Network Channels/Network

Access Points
 In this lab you will configure Network Channels.
Lab Exercise
Module Review

 The benefits of Node Manager
 The way to monitor domains
and servers
 SNMP concepts
 The WLS SNMP Agent
 WLS-provided SNMP
manager commands
 The Network
Channels configuration
Module 5
Basic Deployment

 Describe the Web server capabilities of WebLogic
Server
 Use static and dynamic deployment
 Work with the built-in WebLogic Server servlets
 Define and work with enterprise applications
Basic Deployment-1 © 2007 BEA Systems, Inc. 237

Road Map
1. Web Servers
– Web Servers Defined
– HTTP
– Static and Dynamic Content
2. Web Applications
3. EJB Applications
4. Enterprise Applications
5. Deployment

The Role of Web Servers
 Web servers are responsible for handling HTTP

requests from clients.
 Web servers typically return:
– Static content (HTML pages, graphics, …)
– Dynamic content (Servlet, JSPs, CGIs, …)

A Typical Web Interaction
Example client request header:
POST /Servlet/ProductInfoServlet HTTP/1.1
1 WLS
Accept: text/plain
User-agent: MyApplication Retrieves
HTTP Resource
Request Host: localhost:80
Connection: keep-alive 2
Example client request body:

product=Weblogic%20Server&version=10
WebLogic
Server
Web Client
Example server response header:

4 content-type: text/plain 3
Web Client content-length: 37
Displays HTTP
Results Example server response body: Response
WLS 10 is a full-featured Web server

MIME Types
 Multipurpose Internet Mail Extensions (MIME) is a

protocol for identifying and encoding binary data.
 All HTTP response data is encoded with a MIME
content type.
 Browsers interpret HTTP response data differently
depending upon the MIME type of the data:
– HTML pages are parsed and displayed.
– PDF documents can be sent to Adobe Acrobat.
– Application code can be directly executed.

HTTP Status Codes
 HTTP status codes:

– Indicate to the client whether or not the request was
successful
– Provide the client a reason for a failed request
– Are used by clients to provide alternate behavior
Indicating success:
The default status code is 200, which indicates success.
Reason for failure:
A status code of 404 tells the client the requested resource was not found.
Providing alternate behavior:
If a browser receives a 401 status code, the browser can prompt the user for an ID
and password to login. WLS 10 is a full-featured Web server.

Static Content
 Static content documents are predefined on the server

and do not change.
 WebLogic Server can be used to serve static content
such as:
– HTML documents
– Images
– PDF documents
 WebLogic Server can serve static documents:
– Over standard HTTP
– Through SSL using HTTPS

Dynamic Content
 Dynamic content documents may change based on the

client's request.
 HTML documents can be created by using:
– Servlets
– JSPs
– Common Gateway Interface (CGI) programs

Section Review

 The role of Web servers
 HTTP requests, responses, MIME types, status codes
 Serving static HTML, images
and files
 Serving JSP and
servlet requests

Road Map
1. Web Servers
2. Web Applications
– Web Applications
– Directory Structure and Deployment Descriptors
– Using the Console to Deploy Web Applications
– Monitoring Web Applications
3. EJB Applications
5. Deployment

What Is a Web Application?
 A Web application is a group of server-side resources

that create an interactive online application.
 Server-side resources include:
– Servlets (small server-side applications)
– JavaServer Pages (dynamic content)
– Static documents (HTML, images)
– Server-side classes
– Client-side applets and beans

Packaging Web Applications
 Before deploying an application package and

registering it with a WLS server, follow these steps to
package a Web App:
1. Arrange resources in a prescribed directory structure.

2. Develop web.xml Deployment Descriptor (or copy as required).
3. Develop weblogic.xml Deployment Descriptor (WLS-Specific).
4. Archive Web App into .war file using jar.
5. Deploy Web App onto WLS.
6. Configure Web App with WLS Administration Console.

Web Application Structure
 The structure of Web applications is defined by the

Servlet specification.
 A Web application can be either:
– An archived file (.war file)
– An expanded directory structure
Directory/File Description
Document root of Web application
Information for archive tools (manifest)
Private files that will not be served to clients
Server-side classes such as servlets and applet
.jar files used by Web app
Web app deployment descriptor
WLS-specific deployment descriptor

Configuring Web Applications
 Web applications are configured through deployment

descriptors web.xml and weblogic.xml which:
– Define run-time environment
– Map URLs to servlets and JSPs
– Define application defaults such as welcome and error pages
– Specify J2EE security constraints
– Define work managers for applications
– Set the context-root for the application

The web.xml File
 The web.xml file is a deployment descriptor for

configuring:
– Servlets and JSP registration
– Servlet initialization parameters
– JSP tag libraries
– MIME type mappings
– Welcome file list
– Error pages
– Security constraints and roles
– Resources
– EJB references
The weblogic.xml File
 The weblogic.xml is a WebLogic Server-specific

deployment descriptor for configuring:
– JSP properties
– JNDI mappings
– security role mappings
– HTTP session parameters
– Work managers
– Context root
– Virtual directory mappings
– Logging parameters
– Library modules
weblogic.xml Deployment Descriptor
 Example of weblogic.xml deployment descriptor.
<?xml version='1.0' encoding='utf-8'?>

<weblogic-web-app
xmlns="http://www.bea.com/ns/weblogic/100"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
</weblogic-web-app>

Web Application Archive…
 Web application archives (.war files)

– Are compressed files that contain directory structures that
represent Web applications
– Simplify the distribution and sharing of Web applications
across a network
– Can share common resources
– Can be combined into larger applications
 For ease of development and debugging, Web
applications are not archived until the end of
production.

…Web Application Archive
 Web archives are created using the jar utility:
Static Resources:
HTML, text images
Deployment
Descriptiors
HTML
HTML
HTML
XML
web.xml
weblogic.xml
jar .war
JSP
JSP
JSP
JSPs
Servlet
Servlets, JavaBeans
and other classes
URLs and Web Apps
 The URL used to reference a resource in a Web

application must include the name of the Web
application.
Accessing a resource in a Web application:
http://hostname:port/MyWebApplication/resource
Where:
Host name mapped to virtual host or
Hostname hostname:port
Name of the Web application; not
MyWebApplication necessary if this is the default Web
application
resource Static page, Servlet mapping, or JSP

Virtual Directory Mappings
 Virtual directories:
– Can be used to refer to physical directories
– Let you avoid the need to hard-code paths to physical
directories
– Allow multiple Web applications to share common physical
directories for specific requests such as images
– Decrease duplication of files across applications
– Are configured in weblogic.xml

Virtual Directory Mapping Example
Virtual Directory Mapping Example:

<virtual-directory-mapping>
<local-path>c:/usr/gifs</local-path>
<url-pattern>/images/*</url-pattern>
<url-pattern>*.jpg</url-pattern>
</virtual-directory>
<virtual-directory-mapping>
<local-path>c:/usr/common_jsps.jar</local-path>
<url-pattern>*.jsp</url-pattern>
</virtual-directory>
10
0101
1110

Archive vs. Expanded Directory
 Archive Web applications if:

– In production phase
– Deploying to several machines
 Do not archive Web applications if:
– In development/debugging phase
– Application will be updated frequently
– Deploying to a single machine (Administration Server)

Section Review

 Web applications
 Deployment descriptors
 Deployment and monitoring of Web application
 The way to update production
Web applications
 Virtual directories

Road Map
1. Web Servers
2. Web Applications
3. EJB Applications
– Major EJB Types and Their Purpose
5. Deployment

Enterprise JavaBeans™
 Enterprise JavaBeans™ (EJB) standardizes

development and deployment of Java server
components.
 The EJB specification defines relationships between:
– The EJB and its container
– The container and the application server
– The container and the client

Types of EJBs
EJB Type Description Example
Check validity of stock
Do not maintain state
Stateless symbol
Are synchronous
Session Calculate billing of a
Are maintained in memory
phone call
Conversational interaction Book a flight & car rental

Stateful Maintain state for client for travel
Session
Are synchronous Manage a shopping cart
Represent a player’s
Represent persisted data statistics
Entity
Are synchronous Represent a stock’s
history
Message Asynchronous & stateless
Store logging messages
Driven Consume JMS messages

EJB Application Directory Structure
 EJB components come packaged in JAR files.

 EJBs are configured by modifying deployment
descriptors.
EJB App JAR Format:

EJB Administrator Tasks with WLS
 EJB administrator tasks include:

– Configure and deploy
– Resolve JNDI and other infrastructure issues
– Monitor EJB caches and pools

Section Review

 EJB applications
 Major types of EJBs

Road Map
1. Web Servers
2. Web Applications
3. EJB Applications
– Enterprise Application Concepts
– Enterprise Archive (.ear) File Structure
– Enterprise Application Configuration
5. Deployment

What Is an Enterprise Application?
 An enterprise application is a grouping of several

resources into one deployable unit packaged in
an .ear file.
 These resources include:
– Web applications (.war)
– EJB applications (.jar)
– Java applications (.jar)
– Resource adapters (.rar)

J2EE Enterprise Application
Deployment descriptor
EJB
EJB module
EJB (JAR) ejb-jar.xml J2EE Enterprise
weblogic-ejb-
EJB jar.xml Application
(EAR)
Web application
application.xml
Web module weblogic-pplication.xml
(WAR) web.xml
weblogic.xml
Web
Application client EJB-JAR
module
weblogic- WAR
(JAR) appclient.xml
JAR
Resource adapter
module weblogic-ra.xml RAR
(RAR)
J2EE Modules
Why Enterprise Applications?
 Use enterprise applications to:

– Avoid name space clashes
– Declare application-wide security roles
– Deploy an application as one unit
– Share application-wide EJB resources
– Configure local JDBC data sources
– Configure local JMS resources
– Configure local XML resources

EAR File Structure
 An example directory structure of an enterprise

application is shown below:
Document root of enterprise application
META-INF directory
Enterprise application deployment descriptor
WLS Enterprise application deployment descriptor
An EJB module
Another EJB module
A Java module
Another Java module
A Web application module
Another Web application module

Configuring WLS Specific Features
 Configure enterprise-wide WLS-specific features with

the weblogic-application.xml deployment
descriptor:
– XML parsers
– XML entity mappings
– JDBC data sources
– JMS connection factories and destinations
– Security realms

WLS Application Class Loader
 Each application receives its own class loader

hierarchy with the system class loader as its parent.
System Classpath
Class Loader
App A Class Loader App B Class Loader

loads all EJBs loads all EJBs
Web App 1 Web App 2 Web App 3

Class Loader Class Loader Class Loader
Enterprise App A Enterprise App B

EAR Class Libraries
 Extending the J2EE spec, BEA has added

APP-INF/lib and APP-INF/classes to the standard
J2EE ear file structure.
 When the application is initialized, paths extracted are
prefixed to the beginning of the application’s class path.
 Classes are added to the root classloader of the
application.

J2EE Library Support
 To make things easier, you can create a library of J2EE

modules, package them into an Enterprise application
(EAR), and then deploy and register it with the
application container.
 Afterwards, other applications can use the modules as
if they were packaged in their own EAR files.
 This allows for more reusability between applications.

Section Review

 The structure of enterprise applications
 The deployment of enterprise applications

Road Map
1. Web Servers
2. Web Applications
3. EJB Applications
5. Deployment
– Auto-deployment
– Console Deployment
– Command-line Deployment

Deployment Process Overview
 Deploying an application involves the following tasks:

1. Preparing - Choosing whether to package the application
as an archived file or keep it in an exploded directory
2. Configuring – Creating a deployment plan to maintain
configuration changes without changing the deployment
descriptors
3. Deploying – Targeting and distributing the application to
WebLogic servers in a domain

Deployment Methods
 WLS supports three deployment methods:

– Auto-deployment
– Console deployment
– Command-line deployment
 You can deploy:
– Enterprise applications – EJB components
– Web applications – Resource adapters
– Web services – Optional packages
– J2EE libraries – Client application archives
– JDBC, JMS and Diagnostic Framework modules

 Applications and EJBs can be deployed:
– In an archived file (.ear, .war, .jar)
– In exploded (open) directory format

Auto-Deployment – Copying Files
 If Production Mode is OFF:

– You can install an application simply by copying it
(manually or using the console) to the ‘autodeploy’ folder
of the domain.
– The Administration Server monitors this folder for new,
changed, or removed applications.
– This configures, targets and deploys the application to the
Administration server only.
Location of Applications Directory:

%BEA_HOME%\user_projects\domains\domain_name\autodeploy 10
0101
1110

Development vs. Production Modes
 An Administration Server starts either using:

– development mode, which turns auto-deployment on
– production mode, which turns auto-deployment off
 The Administration server starts in the mode selected at
domain creation time.
 The mode is set for all WebLogic servers in a given
domain.

Production Mode Flag
 When Production mode is disabled, applications can be

dynamically deployed.
– Application poller will be enabled in Development Mode.

Console Deployment Method…
 Deploying with the console allows full administrator

control:
– Installation from a location of your choice
– Manual configuration of application name
– Targeting of application to individual servers and/or clusters
– Configuring the application without targeting it
– Activating deployment when desired

…Console Deployment Method
 Best used with Production Mode

Console Deployment…
3

…Console Deployment…


10

…Console Deployment
11

DD Editing
 Some deployment descriptor elements are editable via

the console.

Application Monitoring
1

Application Testing
 You can test a deployed application using the

administration console.

Application Update and Delete…
 Using the console, you can either update or redeploy

applications after configuration or component changes,
or delete or undeploy them.
 All concurrent deployment activity is tracked by the
Administration server in a series of tasks:
– Task progress and outcome can be queried for each
application.
– Reasons for failure are logged.

…Application Update and Delete…

…Application Update and Delete

Command-Line Deployment
 The weblogic.Deployer utility allows you to

perform deployment operations similar to those
available in the console.
 weblogic.Deployer actions can also be scripted
with the Ant task wldeploy
weblogic.Deployer Syntax:
% java weblogic.Deployer [options]
[-deploy|-undeploy|-redeploy|-start|-stop|-listapps]
[file(s)]
10
0101
1110

weblogic.Deployer Examples…
weblogic.Deployer Examples:
To deploy a new application:

java weblogic.Deployer -adminurl t3://localhost:7001
-username system -password weblogic
-name app -source /myapp/app.ear
-targets server1,server2 -deploy
To redeploy an application:
-username system -password weblogic -name app –redeploy
To redeploy part of an application:
-username system -password weblogic
-targets server1,server2 -redeploy jsps/*.jsp
To undeploy an application:
java weblogic.Deployer -adminurl t3://localhost:7001 10
0101
-username system -password weblogic -undeploy 1110
-name myapp –targets server1,server2

…weblogic.Deployer Examples
More weblogic.Deployer Examples:
To list all deployed applications:

-username system -password weblogic -listapps
To list all deployment tasks:
java weblogic.Deployer -adminurl http://localhost:7001
-username system –password weblogic -listtask
To cancel a deployment task:
java weblogic.Deployer -adminurl http://localhost:7001
-username system –password weblogic -cancel -id tag
10
0101
1110

Deploying Applications with WLST
 WLST provides a number of deployment commands.

 You can use these commands to:
– Deploy, undeploy, and redeploy applications and standalone
modules to a WebLogic Server instance
– Update an existing deployment plan
– Start and stop a deployed application

Deploying an Application with WLST
Deploy an application (deployapp.py):

# #
# WLST script for Deploying J2EE Application #
# #
# Connect to the server

print 'Connecting to server .... '
connect('system','weblogic','t3://localhost:7001')
appname = "mbeanlister"
applocation = "c:/domains/dizzyworld/apps/mbeanlister"
# Start deploy
print 'Deploying application ' + appname
deploy(appname, applocation, targets='myserver',
planPath='c:/myapps/plan/plan.xml')
print 'Done Deploying the application '+ appname
exit()

Section Review

 Auto-deployment
 Console deployment
 Command-line deployment

Exercise
Deploying & Undeploying Web Applications

 In this lab you will learn about deploying and
Undeploying Web applications.
Lab Exercise

Module Review

 Web server and Web application basics
 Packaging and deploying Web applications
 Enterprise JavaBeans concepts
 EJB configuration
 Enterprise application concepts

Module 6
Understanding JNDI

 Describe naming and directory services
 Detail the high-level architecture of JNDI
 Define basic terminology
 View the JNDI tree in WebLogic Server
 Use the Administration Console to deploy a
startup or shutdown class
Understanding JNDI-1 © 2007 BEA Systems, Inc. 305

Road Map
1. Introduction to JNDI
– What Are Directory and Naming Services and How Do
They Work
– The High-level Architecture of JNDI
– Viewing JNDI Tree via the Administration Console and
the Command Line
2. Startup and Shutdown Classes

What Is JNDI?
 The Java Naming and Directory Interface is an API for

accessing different naming and directory services
uniformly.
 This is a major step forward because:
– Different services use vastly different naming schemes
– Java applications will be able to navigate seamlessly across
databases, files, directories, objects and networks

Why JNDI?
 In WebLogic Server, JNDI serves as a repository and

lookup service for J2EE objects including:
– EJB home stubs
– JDBC DataSources
– JMS connection factories, queues and topics
– RMI stubs

JNDI Structure
Written by
Application Code Developer
JNDI API
Naming Manager JNDI API
JNDI SPI
WLS LDAP File Sys DNS
Other Purchased
Driver Driver Driver Driver
WLS LDAP File DNS

Other Service
Server Server System System

Naming Service
 A naming service provides a ID1
Objects
method for mapping identifiers to
entities or objects: ID2
ID3
ID4
 Naming Service vocabulary:
Term Definition Example

www.bea.com is
Association of an atomic name bound to
Binding
and an object 209.10.217.38
A set of unique names in a www.bea.com/
Namespace products
naming system

A JNDI Tree
Root R
Context
A binding associates an IC Initial Context

object with a logical
name and a context
Context “B”
is bound to
A B Initial Context
O1
Object “O1”
is bound to
Initial C
Context O2 O3 O3 O4
Object “O2” Object “O3”
is bound to is bound to both
Context “A” Context “A” and “B”
Contexts and Subcontexts
 Subcontexts are referenced through dot delimiters (.)

 Subcontexts must be created before objects are placed
into them.
 Typically when objects are bound to the JNDI tree,
subcontexts are automatically created based on the
JNDI name.
If the following context exists:
com.bea.examples
you cannot bind:

com.bea.examples.ejb.SomeObject
without first creating:

com.bea.examples.ejb 10
0101
1110

JNDI for Administrators
 Administrators need to understand JNDI because it will

be their job to:
– Verify objects are bound in the JNDI tree
– Set security on contexts within the JNDI tree

Viewing the JNDI Tree
4 5

Listing JNDI Contents
 WLST provides a command line utility for viewing

JNDI bindings.
 jndi() changes to the jndi tree and ls() lists the
bindings.
wls:/offline> connect("weblogic","weblogic","t3://localhost:7001")
wls:/base_domain/serverConfig> jndi()
wls:/base_domain/jndi> cd('AdminServer')
wls:/base_domain/jndi/AdminServer> ls()
dr-- ejb
dr-- javax
dr-- weblogic
-r-- cgDataSource weblogic.rmi.cluster.ClusterableRemoteObject
-r-- cgDataSource-nonXA weblogic.rmi.cluster.ClusterableRemoteObject
-r-- mejbmejb_jarMejb_EO weblogic.rmi.cluster.ClusterableRemoteObject
-r-- samplesDataSource weblogic.rmi.cluster.ClusterableRemoteObject
10
0101
1110

Section Review

 Directory and naming services and how they work
 The high-level architecture of JNDI
 The view of the JNDI tree via
the Administration Console
and the command line

Road Map
1. Introduction to JNDI
2. Startup and Shutdown Classes
– What Are Startup and Shutdown Classes and How
Do They Work
– Deploying a Startup or Shutdown Class Using the
Administration Console

What Is a Startup Class?
 A startup class is a class that is loaded and executed

when WebLogic Server boots.
 You can use a startup class to:
– Initialize objects in memory
– Reconstruct a JNDI tree
– Load critical values from the database
– Recover the system to the state that existed before shutdown

What Is a Shutdown Class?
 A shutdown class is a class that gets executed when

WebLogic Server is shutting down.
 Shutdown classes are usually used to free resources
obtained by startup classes.

Defining Startup/Shutdown Classes…
3
4

…Defining Startup/Shutdown Classes

When Are Startup Classes Loaded?
 By default, startup classes are loaded after the J2EE

deployment units.
 J2EE deployment units load in this order: JDBC, JMS,
Connectors, EJBs, Web Applications.
 If “Run Before Application Deployments” is checked,
then startup class are loaded right before deploying
JDBC Data Sources.

Section Review

 What startup and shutdown classes are and how they
work
 How to deploy a startup or shutdown class using the

Exercise
Working With Startup Classes and JNDI

 In this lab you are going to deploy a startup class that
binds objects into the JNDI tree.
Lab Exercise

Module Review

– Naming and directory services
– The high-level architecture of JNDI
– Terminology used in naming and directory services
– How to view the JNDI tree in WebLogic Server
– How to deploy a startup
or shutdown class
via the Administration Console

Module 7
Setting Up JDBC
 Describe the high level architecture of JDBC
 List the four driver types and those provide by WLS
 Describe and configure Data Sources
 Use the administration console to manage JDBC
resources
Setting Up JDBC-1 © 2007 BEA Systems, Inc. 327

Road Map
1. Overview of JDBC
– High Level Architecture of JDBC and the Driver Model
– Four Different Driver Types
– Differences Between Two-tier and Multi-tier Models
– Drivers Provided by WebLogic Server
2. Data Sources
3. Monitoring and Testing Data Sources

What Is JDBC?
 JDBC is an API for accessing databases in a uniform

way.
 JDBC provides:
– Platform independent access to databases
– Location transparency
– Transparency to proprietary database issues
– Support for both two-tier and multi-tier models for database
access
Data

JDBC Architecture
Client
Java Application
JDBC API
JDBC-ODBC JDBC-Native JDBC-Net All Java
Bridge Bridge Bridge JDBC Driver
(Type 1) (Type 2) (Type 3) (Type 4)
ODBC Native API
Driver (C, C++)
Network
Server
DBMS

Road Map
1. Overview of JDBC
2. Data Sources
– Describe a Data Source and How It Works
– Use the Administration Console to Create a Data Source

What Is a Data Source?
 A data source object provides a way for a JDBC client

to obtain a database connection from a connection pool.
 A data source:
– Is stored in the WLS JNDI tree
– Can support transactions
– Is associated with a connection pool

What Is a Connection Pool?
 A connection pool is a group of ready-to-use database

connections associated with a data source.
 Connection pools:
– Are created at WebLogic Server startup
– Can be administered using the administration console
– Can be dynamically resized to accommodate increasing load

Benefits of Data Sources Plus
Connection Pools
 Some advantages of this approach are:

– Time and overhead are saved by using an existing database
connection.
– Connection information is managed in one location in the
administration console.
– The number of connections to a database can be controlled.
– The DBMS can be changed without the application developer
having to modify underlying code.
 A connection pool allows an application to “borrow” a

DBMS connection.

JDBC Data Source Architecture
WebLogic Server
JNDI JDBC Conn. Pool
« DataSource»
JDBC Conn. Pool

: Connection
« DataSource»
« Application» : Connection
: Connection
« Component» : Connection
JDBC Conn. Pool

« DataSource»

Modular Configuration and
Deployment of JDBC Resources
 JDBC configurations in WLS are stored in XML

documents:
– All JDBC configurations must conform to the new
weblogic-jdbc.xsd schema.
– IDEs and other tools can validate JDBC modules based on
the schema.
 You create and manage JDBC resources either as
system modules or as application modules.
 JDBC application modules are a WLS-specific
extension of J2EE modules and can be deployed either
within a J2EE application or as standalone modules.

How Data Sources Are Used
 A client retrieves a data source through a JNDI lookup

and uses it to obtain a database connection.
WLS
Lookup 1
Client Data Source
Connection
Pool
Return Data Source 2
JNDI
3 getConnection()
DataSource Return Connection 4
DBMS
Connection 5 Database Access

Creating a JDBC Data Source
2
1

Creating a Data Source: Properties

Creating a Data Source: XA Options
10
11
12

Creating a Data Source: Connection
Properties
13
14
15
16
17
18
Creating a Data Source: Test Database
Connections & Select Targets
20
19
22
21

Configuring a Connection Pool

Configuring Settings of a Connection
Pool…

…Configuring Settings of a
Connection Pool

Connection Pool Checklist
 You can modify a connection pool after the data source

has been created
 Before modifying a connection pool, you should
understand:
– The JDBC URL of the database
– The connection properties used to authenticate a user or
optionally configure the driver
 Ask your DBA for:
– The maximum number of connections your application will
be allowed

JDBC URLs
 Database locations are specified using a JDBC

Uniform Resource Locator (URL).
The syntax for a JDBC URL is:
jdbc:<subprotocol>:<subname>
Where:
<subprotocol> identifies the database connectivity mechanism
<subname> identifies the data source. The subname can vary depending on
the subprotocol
10
0101
1110

JDBC URL Examples
Example 1. This URL could be used to access a PointBase database:
jdbc:pointbase:server://dbhost:9092/HRDATABASE
The subprotocol is “pointbase:server;” the subname is a location of

PointBase database named “HRDATABASE.”
10
0101
1110
Example 2. This URL specifies that the “oracle:thin” subprotocol should be

used to connect to an Oracle database:
jdbc:oracle:thin:@dbhost:1521:SALESINFO
10
0101
1110

Connection Properties…
 Are key/value pairs

 Are used to configure JDBC connections and are
passed to the driver during connection setup
For a complete list, see your driver documentation!

…Connection Properties
 A partial list of connection properties for the supplied

drivers:
Driver Some Connection Properties
Oracle User, Password, ServerName, ServiceName, PortNumber
User, Password, ServerName, DatabaseName,

Sybase
PortNumber
MSSQL
PortNumber
Informix
PortNumber
cache.size, crypto. communication, database.home,
PointBase*
database.pagesize

Multi Data Sources…
 Multi data source:
– Is an abstraction around a group of data sources
– Determines which data source to use to satisfy the request
depending on the algorithm selected in the multi data source
configuration:
• Load balancing
Or
• Failover
– Is bound to the JNDI tree
 XA support for multi data sources
– The WLS JDBC supports using multi data sources in XA
transactions.
– You can configure the data sources contained within the
multi data source to use XA JDBC drivers.

… Multi Data Sources
WebLogic Server
JNDI
JDBC Conn. Pool
Multi Data Source
« DataSource»
JDBC Conn. Pool

: Connection
« DataSource» : Connection
« Application»
: Connection
: Connection
« Component»
JDBC Conn. Pool
« DataSource»

Section Review

 Data source definition and workings
 Data source management with the administration
Console
 Multi data sources

Road Map
1. Overview of JDBC
2. Data Sources
– Monitoring
– Testing

Monitoring Data Sources: Statistics
 The administration console provides two types of data

source monitoring: statistics and testing.

Monitoring Data Sources: Testing
 The administration console provides a mechanism for

manually testing individual data sources.

Section Review

 Monitoring statistics and the testing of an individual
data source.

Exercise
Configuring Data Sources
 In this lab you will work with configuring and

monitoring data sources.
Lab Exercise

Module Review

 JDBC high-level architecture
 WebLogic Server provided JDBC driver types
 Data source definition and workings
 Connection pool definition
and workings
 Managing JDBC resources
with the administration
console

Module 8
Setting Up JMS (Java Message Service)

Applications
At the end of this module, you will be able to:
 Understand how WebLogic Server JMS is
implemented
 Configure JMS administered objects using the
administration console
 Configure persistent messages
 Use the WLS administration console to monitor
JMS
Setting Up JMS Applications-1 © 2007 BEA Systems, Inc. 371

Road Map
1. WebLogic Server JMS Administration

– Messaging Fundamentals
– Point-to-Point (PTP) and Publish-Subscribe (Pub/sub)
Domains
– Configuring JMS Objects
– Fine-Tuning WLS JMS
2. Configuring Persistent Messaging
3. Monitoring JMS in WLS

Message-Oriented Middleware
 Message-oriented middleware refers to an

infrastructure that supports messaging.
 Typical message-oriented middleware architectures
define these elements:
– Message structure
– The way to send and receive messages
– Scaling guidelines

Point-to-Point Queue
 Many producers can serialize messages to multiple

receivers in a queue.
Messages are delivered
to one client
Distribution 3
Sender Receiver
Queue
1
9 8 7 6 5 4 Receiver
Queue Manager 2
Sender Receiver
WebLogic Server

Publish-Subscribe Topics
 Publishing and subscribing to a topic decouples

producers from consumers.
Messages are delivered
to more than one client
Distribution
Publisher 3 2 1
Topic Subscriber
9 8 7 6 5 4
3 2 1
Subscriber
Topic Manager
Publisher 3 2 1
WebLogic Server
Subscriber

WebLogic Server JMS Features
 WebLogic Server JMS supports:

– PTP and pub/sub domains
– Guaranteed and transactional message delivery
– Durable subscribers
– Distributed destinations
– Recovery from failed servers

JMS Architecture: Connecting
Client WLS
lookup
ConnectionFactory ConnectionFactory 1
3Create a Connection JNDI

Destination: Queue
Connection
Destination: Topic
JMS Server
4Create a Session
Session
To send messages,
these are required:
Look up a Destination 3 - Connection
Destination
- Session
- Destination
Destination Returned 4

JMS Architecture: Sending Messages
Connection, Session and

Destination are used to
send a message
Destination: Queue
Connection
5
Session
Message
Destination Destination: Topic
Producer JMS Server

WLS
Client
Database

Transacted Messaging
 A JMS client can use JTA to participate in a distributed

transaction.
 Alternatively, a JMS client can demarcate transactions
local to the JMS Session, through a transacted session.
 Participation in a transaction is optional.
Begin Transaction 1 Begin Transaction 2
Producer Consumer
All messages arrive Messages are removed

at destination from destination
Commit Commit

Administrative Tasks
 Administrative tasks include these:

– Creating and monitoring JMS servers
– Creating connection factories
– Creating and monitoring destinations
– Creating JMS stores
– Configuring thresholds and quotas
– Configuring durable subscriptions
– Managing JMS service failover

WLS JMS Server
 In WLS, the messaging service is implemented through

a JMS server.
 A JMS server receives and distributes messages.
Queues
Queues
Queues
JMS Client JMS Client
Topics JMS
Topics
Topics Server A
JMS Client JMS Client
… Queues
Queues …
Queues
JMS Client Topics JMS JMS Client
Topics
Topics Server B
WebLogic Server
Persistence

Create a JMS Server

Target a JMS Server

Configure a JMS Server

JMS Resources
 JMS resources are managed as either system modules

or application modules.
«domain»
config.xml
«deploy»
«EAR»
«weblogic-
application.xml DD»
«demo-jms.xml»
«MyJMSDescriptor-
jms.xml»
System Module
Application Module

Modular JMS Resource Configuration
and Deployment...
 JMS configurations in WebLogic Server are stored as

JMS modules.
– Defined by an XML file that conforms to the weblogic-
jmsmd.xsd schema
– Similar to standard J2EE modules
 An administrator can create and manage JMS modules
as:
– Global system resources
– Global standalone modules
– Modules packaged with an enterprise application

...Modular JMS Resource
Configuration and Deployment
 An advantage of modular deployment is simplified

migration between environments, such as:
– From development to integration
– From system test to production
 You can migrate your application and the required
JMS configuration:
– Without opening an EAR file
– Without extensive manual JMS reconfiguration

Connection Factory
 A connection factory:
– Encapsulates connection configuration information
– Is used to create pre-configured connections
– Is stored in JNDI
– Can be targeted to servers or clusters
 WLS provides a default connection factory that is
bound in JNDI to weblogic.jms.ConnectionFactory.
 When a new configuration is required, a new
connection factory can be created.

Create a Connection Factory…
1
2

…Create a Connection Factory…



…Create a Connection Factory
11
10

Configure Connection Factory: Default
Delivery

Configure Connection Factory: Client

Configure Connection Factory:
Transactions

Configure Connection Factory:
Flow Control

Destination
 A destination is a lightweight object stored in JNDI.

 It is the target on a JMS server for sending or receiving
messages.
 The JMS destination types are:
– Queue
– Topic

Create a Queue Destination…

…Create a Queue Destination…

…Create a Queue Destination

Threshold and Quota
 A threshold and a quota can be set for Server and

Destination objects.
 A quota is a limit defined for JMS administered objects;
it includes these values:
– The maximum number of bytes that can be stored
– The maximum number of messages that can be stored
 A threshold is a limit that triggers message paging,
flow control, and logged warnings, using:
– Upper and lower values for the number of bytes
– Upper and lower values for the number of messages

Configuring Thresholds and Quotas
2`

Section Review

 Identify message-oriented middleware domains
(PTP, publish and subscribe)
 Understand WLS JMS messaging for the PTP and
publish and subscribe domains
 Administer JMS from the console
 Fine-tune WLS JMS with
thresholds and quotas

Road Map

– Persistent and Non-Persistent Messages
– Persistent Backing Stores Using the Console
– Durable Subscriptions
– Durable Subscriptions Using the Console

Durable Subscribers and
Subscriptions
 Durable subscribers register durable subscriptions to

guarantee message delivery even if subscribers are
inactive.
 A subscriber is considered active if the Java object that
represents it exists.
 By default, subscribers are non-durable.
 Administrators configure:
– Where messages are persisted
– Persistent connection factories and destinations

When to Use Persistent Messaging
 Persistent messaging permits messages in memory to be

written out to a persistent store.
 Configure persistent messaging if:
– Development requires durable subscriptions (use durable
subscribers in the application)
– You require that in-progress messages persist across server
restarts

How a Durable Subscription Works
 If a subscriber client is active, messages are delivered

normally:
Topic A Associated
Publisher Client
(A Durable Subscription) with
Persistent Store
Database or File
JMS Server
Client Registers ID When client is active,

messages are delivered.
Active Client
(A Durable Subscriber)
 When the client becomes active again, its ID is used to

retrieve and redeliver messages.

Configure a Durable Subscription
 To configure durable subscriptions, an administrator

must:
– Create and configure a JMS store
– Configure connection factories or destinations as persistent
– Associate the JMS store with the JMS server
 The JMS store can be configured to use either:
– A file store
– A JDBC store (a connection pool)

Create a JMS File Store…

…Create a JMS File Store

Create a JMS JDBC Store…
 To configure JMS JDBC persistence:

– Create a JDBC DataSource.
– Create a JMS store and refer to the JDBC DataSource.
– Refer to the JMS store from the JMS server configuration.
 The required infrastructure (tables, and so on) is
created automatically.

…Create a JMS JDBC Store

Assign a Store to a JMS Server

Persistent Connection Factory

Configure a Persistent Destination

Section Review

 Distinguish between persistent and non-persistent
messages
 Configure persistent backing stores using the console
 Manage durable subscriptions

Road Map

– Using the Administration Console to Track JMS Statistics

Statistics for JMS Objects
 Statistics are provided for the following JMS objects:

– JMS servers
– Connections
– Destinations

Monitor JMS Servers…

…Monitor JMS Servers

Monitor Destinations

Section Review

 Use the administration console to display JMS statistics

Exercise
Configuring JMS Servers and Destinations


Module Review

 Understand messaging concepts
 Understand WebLogic Server’s JMS support
 Configure JMS servers, queues, and topics
 Monitor JMS servers, queues, and topics

Module 9
Managing Transactions

 Configure transactions using the console
 Monitor transactions using the console
Managing Transactions-1 © 2007 BEA Systems, Inc. 427

Road Map
1. Configuring and Monitoring Transactions

– Configuring Transactions
– Monitoring Transactions
– The Transaction Log

What Is a Transaction?
 A transaction is a mechanism to handle groups of

operations as though they were one.
 Either all operations in a transaction occur or none at
all.
 Operations involved in a transaction might rely on
multiple servers and databases.

ACID Properties of a Transaction
 A transaction is formally defined by the set of properties

known by the acronym ACID.
 Atomicity: A transaction is done or undone completely. In the
event of a failure, all operations and procedures are undone,
and all data rolls back to its previous state.
 Consistency: A transaction transforms a system from one
consistent state to another consistent state.
 Isolation: Each transaction occurs independently of other
transactions occurring at the same time.
 Durability: Completed transactions remain permanent, even
during system failure.

Transaction Management
SQL server PointBase

Messaging Database Database
Server (Resource) (Resource)
Resource Manager Resource Manager
Resource Manager JTA

WebLogic Manages
Server
Transactions
Transaction Manager End-to-End
Application 1

Transferring Without Transactions
 Successful transfer (A)

 Unsuccessful transfer (accounts are left in an inconsistent state)
(B)
$500
1) Withdraw: $100 Account 1 -$100
$400
A ATM
Transfer: $100
Bank
Account 2 $1000
From: Acct 1 2) Deposit: $100 +$100
To: Acct 2 $1100
$500
Account 1 -$100
1) Withdraw: $100
$400
B ATM
Transfer: $100
Bank
Failed Account 2
From: Acct 1 Deposit $1000
To: Acct 2

Successful Transfer with Transactions
 Changes within a transaction are buffered. (A)
 If a transfer is successful, changes are committed (made
permanent). (B)
Transaction Started by Bank $500

1) Withdraw: $100 -$100
Account 1 $400
A ATM
Transfer: $100
Bank $1000
2) Deposit: $100 Account 2 +$100
From: Acct 1
$1100
To: Acct 2
Transaction Started by Bank
Commit Account 1 $400

B ATM
Transfer
Bank
Successful Commit Account 2 $1100

Unsuccessful Transfer with Transactions
 Changes within a transaction are buffered. (A)

 If a problem occurs, the transaction is rolled back to the previous
consistent state. (B)
Transaction Started by Bank $500

-$100
1) Withdraw: $100 Account 1 $400
A ATM
Transfer: $100
Bank
Failed Account 2 $1000
From: Acct 1 Deposit
To: Acct 2
Transaction Started by Bank
Rollback Account 1 $500

B ATM
Error
Bank
Rollback Account 2 $1000
message

Types of Transactions
 A local transaction deals with a single resource

manager. They use the non-Extended Architecture
(non-XA) interface between WebLogic Server and
resource managers.
 A distributed transaction coordinates or spans multiple
resource managers.
 Global transactions can deal with multiple resource
managers. They use the Extended Architecture (XA)
interface between WebLogic Server and resource
managers.
– You need to create non-XA or XA resources for local
transactions. However, for global transactions, you only need
to create XA resources.

The Two-Phase Commit Protocol
 The Two-Phase Commit (2PC) protocol uses two steps

to commit changes within a distributed transaction.
– Phase 1 asks RMs to prepare to make the changes
– Phase 2 asks RMs to commit and make the changes
permanent, or to roll back the entire transaction
 A global transaction ID (XID) is used to track all
changes associated with a distributed transaction.

Extended Architecture Protocol
 The Extended Architecture (XA) protocol:

– Is the interface used between WLS and RMs
– Implements the 2PC protocol
– Allows programs to control RMs that are involved in
distributed transactions
XA
RM1
Transaction
Client
Manager RM2
XA

Transaction and Resource Managers
 A transaction manager coordinates multiple resource managers.

 The 2PC protocol is used to coordinate the transaction.
 The XA protocol implements 2PC.
Resource
Manager Database
XA
Transaction XA Resource
Application Printer
Manager Manager
XA Resource Another
Manager App
Transaction Context started by Transaction Manager

Successful Two-Phase Commit
pre-commit Resource
Application Manager Database
Transaction Resource
Printer
Manager Manager
Resource Another
TLOG Manager App
ready
Phase 1
Phase 2
commit Resource
Manager Database
Application
Printer
Manager Manager
Resource Another
TLOG committed Manager App

Unsuccessful Two-Phase Commit
pre-commit Resource
Application Manager Database
Printer
Manager ready Manager
Resource Another
TLOG not Manager App
ready
Phase 1
Phase 2
abort Resource
Manager Database
Application
Printer
Manager Manager
Resource Another
TLOG Manager App
prepare/ ready/ not rolled

abort committed ready back

Java Transaction API (JTA)
 WLS uses JTA to implement and manage transactions.

 WLS JTA provides the following support:
– It creates a unique transaction identifier (XID).
– It supports an optional transaction name.
– It tracks objects involved in transactions.
– It notifies databases of transactions.
– It orchestrates 2PC using XA.
– It executes rollbacks.
– It executes automatic recovery procedures when failure.
– It manages time-outs.

Configuring Transactions

Configuring the Transaction Log…
 Each server has a transaction log that stores

information about committed transactions coordinated
by the server that may not have been completed.
– WebLogic Server uses the transaction log when recovering
from system crashes or network failures.
 You cannot directly view the transaction log as the
records are in a binary format.
 T-log files must be migrated if migrating to a new
machine.

…Configuring the Transaction Log
 .tlog files are stored in the default persistent store

for the server.
 Directory represents the path name to the file system
directory where the file store maintains its data files.

JTA Configuration Options…
Field Description
Timeout Seconds Specifies the time in which a transaction will
timeout, if uncommitted
Abandon Timeout Seconds Specifies the maximum time that a transaction
manager will persist in attempting to complete a
transaction during the second phase of the
transaction
Before Completion Iteration Specifies the maximum number of cycles that
Limit the transaction manager will perform the
beforeCompletion() synchronization
callback for this WebLogic Server domain
Max Transactions Specifies the maximum number of

simultaneous in-progress transactions allowed
on a server in the domain
Max Unique Name Statistics Specifies the maximum number of unique
transaction names for which statistics will be
maintained

…JTA Configuration Options
Field Description
Checkpoint Interval Seconds Specifies the interval at which the transaction
manager creates a new transaction log file and
checks all old transaction log files to see if they
are ready to be deleted
Forget Heuristics Specifies whether the transaction manager will

automatically perform an XAResource forget()
operation for heuristic transaction completions
Unregister Resource Grace Specifies the grace period, in seconds, that the
Period transaction manager waits for transactions
involving the resource to complete before
unregistering a resource
Security Interoperability Mode Specifies the security mode to use for XA calls in
inter-domain transactions

Creating XA Resources

Creating Non-XA Resources…

…Creating Non-XA Resources

Logging Last Resource
 You can configure a JDBC data source to enable the Logging

Last Resource (LLR) transaction optimization, which:
– Enables one non-XA resource to participate in a global transaction
– Has improved performance and the same ACID guarantee as XA
 The LLR optimization improves performance by:

– Removing the need for an XA JDBC driver to connect to the database.
XA JDBC drivers are typically inefficient compared to non-XA JDBC
drivers
– Reducing the number of processing steps to complete the transaction,
which also reduces network traffic and I/O
– Removing the need for XA processing at the database level (if the
database is the one non-XA resource)

Transacted Messaging
 A JMS client can use JTA to participate in a distributed

transaction.
 Alternatively, a JMS client can demarcate transactions
local to the JMS Session through a transacted session.
 Participation in a transaction is optional.
Begin Transaction 1 Begin Transaction 2
Producer Consumer
All messages arrive Messages are removed

at destination from destination
Commit Commit

Monitoring Transactions

Monitoring Transactions by Resource
 For a particular resource, the console provides

monitoring of transactional outcomes:
– Number of transactions attempted
– Number of commits/rollbacks
– Number of heuristic outcomes

Monitoring Transactions

Section Review

 Configuring transactions
 Monitoring transactions
 Logging transactions

Exercise
Data Sources and Transactions

 In these labs you will work with monitoring Data
Sources.
Lab Exercise

Module Review

 Configuring transactions using the console
 Monitoring transactions in WebLogic Server

Module 10
Securing WLS Resources and
Applications
 Describe WLS security architecture
 Configure users, groups, and roles
 Configure security realms
 Secure Web applications with declarative security
 Configure policies and SSL
 Create and manage certificates
 Protect WLS against several types of attacks
Securing WLS Resources and Applications-1 © 2007 BEA Systems, Inc. 461
Road Map
1. WLS Security Architecture Overview

– Security Architecture
– Security Terminology
– Compatibility with Previous WLS Versions
4. Protecting Communications
5. Protecting Against Attacks
Architecture Goals
 Using Java standards (where applicable) create an

architecture that unifies security enforcement and
present it as a service to other components.
 Provide a security framework that allows integration of
3rd party security products with minimum restrictions
on functionality.
 Provide consistent and unified protection for all
resources hosted on WebLogic Server:
– EJBs – Web services
– Web applications – Miscellaneous J2EE Resources
(Servlets, JSP) • RMI objects JDBC, JNDI, MBeans
Security Architecture
Client Client
EJBs Web Apps
WLS Security API Java 2 Security

Application Developer
WebLogic Security Service Provider Interfaces (SSPIs)

Authentication Authorization Auditing Adjudication
SSPI SSPI SSPI SSPI
Role Mapping CertPath Credential Mapping
SSPI SSPI SSPI
Security Vendor or Sophisticated Application Developer
WebLogic Security Providers

Authentication Authorization Auditing Adjudication
Role Mapping Certificate Registry Credential Mapper
Administrator
Process Architecture
Directory Service
Agent (LDAP)
Web Server
HTTP(s) MBeans JNDI
Connection Filter
Proxy
Plug-in
Web Client
HTTP(s)
Security Service
Client EJB WebApp App

WebLogic Server
Road Map

– What Is Secure Socket Layer (SSL)
– Configuring SSL
– Certificates
– keytool
What Is SSL?
 Secure Socket Layer (SSL) is a protocol that enables:

– Connection security through encryption
– A server to authenticate to a client
– A client to authenticate to a server (optional)
– Data integrity such that data that flows between a client and
server is protected from tampering by a third party
Trust and Identity
 SSL and keystore are configured independently.

 For the purpose of backward compatibility, this
release of WebLogic Server supports private keys
and trusted CA certificates stored in files, or in the
WebLogic Keystore provider
 Identity
– Private Key and Digital Certificate (can now be looked
up directly from the keystore, not necessarily as a
standalone file outside the keystore)
 Trust
– Certificates of Trusted Certificate Authorities
Using an SSL Connection
 WLS uses SSL to secure HTTP and t3 communication.

 To use SSL, clients access WLS via the https or t3s
protocols.
– https://localhost:7002/orderStock
– t3s://localhost:7002/useCreditCard
HTTPS or t3s WebLogic Server
Enabling Secure Communication
 With SSL, data is encrypted using a negotiated

symmetric session key.
 A public key algorithm is used to negotiate the
symmetric session key.
 In SSL, digital certificates are used to provide a trusted
public key.
WebLogic Server SSL Requirements
 To enable WebLogic Server SSL, you must:

– Obtain an appropriate digital certificate
– Install the certificate
– Configure SSL properties
– Configure two-way authentication (if desired)
• SSL impacts performance
The keytool Utility
 keytool is a standard J2SE SDK utility for managing:

– The generation of private keys and corresponding digital
certificates
– Keystores (databases) of private keys and associated
certificates
 The keytool utility can display certificate and
keystore contents.
 For documentation, see:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/
windows/keytool.html
http://java.sun.com/j2se/1.5.0/docs/tooldocs/
solaris/keytool.html
Obtaining a Digital Certificate:
keytool Examples
Generate a new self-signed digital certificate:

keytool –genkey –alias dwkey –keyalg RSA –keysize 512
-keystore dw_identity.jks
Generate a CSR:
keytool –certreq -v –alias dwkey –file dw_cert_request.pem
-keypass dwkeypass -keystore dw_identity.jks
–storepass dwstorepass
Import a signed certificate reply from a CA:

keytool –import –alias dwkey –file dw_cert_reply.pem
-keypass dwkeypass -keystore dw_identity.jks
–storepass dwstorepass
1
011
Configuring SSL for a WebLogic
Server
Configuring Keystores
Section Review

 Using the Secure Socket Layer
 Configuring SSL
 Creating certificates
 Managing certificates
with keytool
Exercise
Configuring SSL
 In this lab you are going to configure Secure Socket
Layer.
Lab Exercise
Road Map

2. Users and Groups
3. Protecting Application Resources
– Types of Attacks
– Protecting Against Man in the Middle Attacks
– Protecting Against Denial of Service Attacks
– Protecting Against Large Buffer Attacks
– Protecting Against Connection Starvation
Protecting Against Attacks
 WLS can help protect applications against several

attacks:
– Man in the middle attacks
– Denial of service (DoS) attacks
– Large buffer attacks
– Connection starvation attacks
 The slides that follow detail the countermeasures WLS
provides to address these attacks.
Man in the Middle Attacks
 In a man in the middle attack, a third party poses as a

destination host intercepting messages between the
client and the real host.
 Instead of issuing the real destination host's SSL
certificate, the attacker issues his own hoping that the
client accepts it as being from the real destination host.
Man in
the Middle
Host
Client
Server
Man in the Middle Countermeasures
 Man in the Middle attacks can be resisted by using

a host name verifier.
 A Host Name Verifier validates that the host to which an
SSL connection is made is the intended
or authorized party.
 WLS provides a Host Name Verifier by default.
 A custom Host Name Verifier can be created by
implementing the interface
weblogic.security.SSL.HostnameVerifier
Configuring Hostname Verifier
Denial of Service Attacks
 DoS attacks are attempts by attackers to prevent

legitimate users of a service from using that service.
 There are three basic types of attack:
– Consumption of scarce, limited, or non-renewable resources
– Destruction or alteration of configuration information
– Physical destruction or alteration of network components
DoS Countermeasures
 Harden WLS against Denial of Service attacks by:

– Filtering incoming network connections
– Configuring consumable WLS resources with appropriate
threshold and quotas
– Limiting access to configuration information and backing up
configuration files
– Preventing unauthorized access by protecting passwords
against password guessing attacks
Filtering Network Connections
 WLS can be configured to accept or deny network

connections based on the origin of the client.
 This feature can be used to:
– Restrict the location from which connections to WLS are
made
– Restrict the type of connection made, that is, only allow SSL
connections and reject all others
 To filter network connections, create a class that
implements the ConnectionFilter interface and
install it using the administration console.
Connection Filter
Consuming WLS Resources
 Denial of Service can come from consuming server-

side resources used by Web applications:
– Intentionally generating errors that will be logged consuming
disk space
– Sending large messages, many messages, or delaying
delivery of messages in an effort to cripple JMS
– Disrupting network connectivity by "connection starvation"
– Consuming system memory through "large buffer attacks"
 The effect of these attacks can be reduced by setting
appropriate quotas and threshold values.
Large Buffer Attacks…
 Individuals can try and take down a Web site by

sending a large buffer of data, which starves the system
of memory.
 Administrators can combat this attack by setting a
threshold for incoming data.
…Large Buffer Attacks
Connection Starvation…
 Individuals can try and take down a Web site by

sending small, incomplete messages that cause
the server to wait.
 Administrators can combat this attack by setting
a threshold.
 Connections time out while waiting for the remainder
of the data if they have reached the threshold set by the
administrator.
…Connection Starvation
User Lockout
 Individuals attempt to hack into a computer using

various combinations of usernames and passwords.
 Administrators can protect against this security attack
by setting the lockout attributes.
 The administrator has an option to unlock a locked
user through the console.
Configuring User Lockout
Unlocking Users
Protecting the Admin Console…
 You can configure a separate administration port for all

admin traffic.
 You can change the Context Path of the console.
 You can disable the Console (application).
…Protecting the Admin Console
Section Review

 Types of attacks
 Protecting WLS against man in the middle attacks
 Protecting WLS against denial of service attacks
 Protecting WLS against
large buffer attacks
 Protecting WLS against
connection starvation
attacks
 Protecting the admin console
Exercise
Protecting Against Attacks

 In this lab you are going to configure WLS features for
hardening against password attacks.
Lab Exercise
Module Review
 In this module we discussed:

– Using the WLS security architecture
– Configuring users, groups, and roles
– Configuring security realms
– Securing Web applications with declarative security
– Configuring policies and SSL
– Creating and managing
certificates
– Protecting WLS against
several types of attacks
Module 12
Introduction to Clustering
 Understand the uses of a cluster
 Describe the basic cluster architecture
 Describe the multi-tier cluster architecture
 Understand how clusters communicate
Introduction to Clustering-1 © 2007 BEA Systems, Inc. 571

Road Map
1. Cluster Architecture
– Cluster Definition
– Basic Cluster Architecture
– Multi-tier Cluster Architecture
– Proxy Servers
2. Networks and Clusters
3. Cluster Communication

Definition: Clustering
 A cluster is a group of WebLogic Server instances,

working in coordination.
 Clustering provides: domain
– High availability
machine machine
– Load balancing
server
– Scalability Admin
server
DNS cluster
Round
Robin server
client
Internet Proxy
client Server server
server
client Load
Balancer

Benefits of Clustering
 There are two main benefits of clustering together

WebLogic servers:
– Scalability
– High Availability
 Scalability is the ability to provide more capacity for an
application, in this case, by adding additional servers
without having to make major architectural changes.
 High Availability ensures that when a server (in a
cluster) fails, there are other servers to take over the
work so the client is not affected.

Key Capabilities
 The key capabilities of a WebLogic cluster are:

– Application failover
When an object in an application performing a task becomes
unavailable, another object will take over and finish the job.
– Site failover
When all the services and applications in a single site fail,
they can switch to a separate site and continue processing.
– Server migration
When a server fails, pinned services can be migrated to
another server in a cluster.
– Load balancing
The even distribution of tasks and communications across
multiple servers.
Cluster Architecture
 Applications are generally broken into multiple tiers,

each representing their distinct functionality:
– Web tier
– Presentation tier
– Business or object tier
 WebLogic provides clustering support for all three tiers.
 Other services, such as JMS and JDBC, can take
advantage of clusters but load-balancing and failover is
a little different.

Deciding on a Cluster Architecture
 Good architecture is somewhat subjective but there are

a few global considerations:
– Performance
– Efficient state persistence
– Optimal load balancing
– Effective failover
– Reliable communication
 There are two primary cluster architectures to choose
from:
– Basic cluster architecture
– Multi-tier architecture
Basic Cluster Architecture
 A basic cluster architecture combines static HTTP,

presentation logic, business logic and objects into one
cluster.
domain
server 1
web ejb
container container
Load
Balancer server 2
web ejb
container container
Firewall Cluster

Multi-Tier Cluster Architecture
 The web tier and the business logic with services can
be separated into two clusters.
domain
server 1 server 3
web EJB
container container
Load
Balancer
server 2 server 4
web EJB
container container
Firewall Cluster A Cluster B

When to Use Multi-tier Architecture
 The multi-tier cluster is recommended for Web

Applications that require:
– Load balancing for method calls to clustered EJBs
– Flexibility for load balancing between servers that provide
HTTP content and servers that provide clustered objects
– Higher availability (fewer single points of failure)
– More flexible security

Basic Cluster Architecture Advantages
and Disadvantages
 The basic cluster architecture has these advantages:

– Easy administration
– Flexible load balancing
– Robust security
 The basic cluster architecture has these disadvantages:
– It cannot load balance EJB method calls.
– Load balancing across the tiers may become unbalanced.

Multi-tier Advantages and
Disadvantages
 The multi-tier architecture has these advantages:

– Improved load balancing
– Load balancing of EJB methods
– Higher availability
– Improved security options
 The multi-tier architecture has these disadvantages:
– Can create a bottleneck when presentation tier makes
frequent calls to the business logic
– Increased licensing cost
– Added firewall configuration complexity

Proxy Servers
 Proxy servers are used to provide load balancing and

failover for a cluster. They also
– Are the client’s first level of interaction with the cluster
– Give the cluster its single server appearance
 A proxy server can be either software-based or
hardware-based.
 A software-based proxy server may be an internal
WebLogic servlet or a third-party application.
 A hardware-based proxy server is typically a physical
load balancer.

Basic Cluster Proxy Architecture
 It is similar to the basic cluster architecture, except

static content is hosted on non-clustered HTTP servers.
domain
server 1
HTTP Servlet/ ejb
container
Server JSP
Load Plug-in
Balancer
server 2
HTTP
Servlet/ ejb
Server container
JSP
Plug-in
Firewall
Cluster

Multi-Tier Cluster Proxy Architecture
 It is similar to the multi-tier cluster architecture, except

static content is hosted on non-clustered HTTP servers.
domain
server 1 server 3
web ejb
HTTP container container
Server
Load Plug-in server 2 server 4

Balancer
web ejb
HTTP container
container
Server
Plug-in Cluster A Cluster B

Firewall

WLS HttpClusterServlet
 HttpClusterServlet:
– Is deployed in the default
Web application of the
proxy server domain
– Delivers client requests

machine machine
in round-robin style to
servers in the cluster server
Admin
server
cluster
server
client
Internet WLS Proxy Server
client HttpClusterServlet server
server
client

WLS Plug-Ins…
 WLS is compatible with major Web servers using the

following plug-ins:
– Sun Java System Web Server plug-in (formerly Netscape
iPlanet or Sun One Web Server)
– IIS plug-in (Microsoft IIS)
– Apache plug-in

…WLS Plug-Ins
 Plug-ins:
– Delegate dynamic content requests to WLS
– Round-robin across a cluster
– Support routing based on the URL path or on MIME type of
the requested file or both
– Route HTTP requests to back-end WLS instances based on
session cookie or URL rewriting
– Avoid failed servers in the cluster

Proxy Plug-in vs. Load Balancer
 There are many advantages to using a physical load

balancer instead of the proxy plug-in:
– There is no need to configure client plug-ins.
– Eliminating the proxy layer reduces the number of
connections.
– There are more sophisticated load balancing algorithms.
 There are a number of disadvantages as well:
– Additional administration
– Explicit configuration of “sticky” sessions for stateful Web
applications

Architecture Recommendations
 If possible, place static web content on separate web

servers in the DMZ.
 Use a combined tier architecture if your presentation
and control tier makes multiple invocations of the
business tier.
 Make sure that your architecture choice supports
passing active and passive cookies between the cluster
and client application.

Section Review

 Describe the uses of a cluster
 Describe a basic cluster architecture
 Understand the use of a proxy server
 Use a multi-tier architecture
 Decide on the best cluster architecture to use

Road Map
– Local Area Networks
– Metropolitan Area Networks
– Wide Area Networks

Cluster in Networks
 WebLogic Server clusters can be created in three

different kinds of networks:
– Local Area Networks (LAN)
– Metropolitan Area Networks (MAN)
– Wide Area Networks (WAN)
 When you are configuring your cluster, you will need
to keep in mind the type of network you are using.

Local Area Networks
 A local area network serves a local set of computers.

– They usually use high quality, high-speed communication
links.
– Typical data transmission speeds are 100 megabits/second.
 Most clusters exist within a single LAN.

Metropolitan Area Networks
 A MAN is a network that usually spans a campus or a

city.
 You can have different clusters located reasonably
close to each other within a MAN.

Wide Area Networks
 A WAN usually spans a wider geographical area and

can be made up of smaller MANs and LANs.
 You can have different clusters located in different
regions within a WAN.
– A cluster can be located in different LANs within a MAN or
within a WAN.

Section Review

 Describe different types of networks that a cluster can
operate in

Road Map
– One-to-many communications
– Peer-to-peer communications

Server Communication in a Cluster
 WebLogic Server instances in a cluster communicate

with one another using two different techniques:
– Multicast (UDP)
– Sockets (peer-to-peer TCP)
 IP multicast broadcasts one-to-many communications
among clustered instances.
 IP sockets are used for peer-to-peer communications
between servers.

Detecting a Failure
 WebLogic clusters detect a failure of a server instance

in the following ways:
– Through the use of IP sockets
– Through the WebLogic Server heartbeat
 If a server in the cluster unexpectedly closes its socket,
it will be marked as "failed" and its services will not be
used.
 Server instances use multicast to broadcast heartbeats
every 10 seconds to other server instances in the cluster.
– If three heartbeats are missed from a peer server, the server is
marked as "failed" and its services will not be used.

One-to-Many Communications
 WebLogic Server uses one-to-many communication for:

– Cluster-wide JNDI updates
– Cluster “heartbeats”
 Because all one-to-many communications occur over IP

multicast,when designing a cluster, consider these factors:
– If your cluster spans multiple subnets, you network must be configured to
reliably transmit messages.
– A firewall can break IP multicast transmissions.
– The multicast address should not be shared with other applications.
– Multicast storms may occur.

Peer-to-Peer Communications
 WebLogic Server uses peer-to-peer communications

for:
– Accessing non-clustered objects that reside on a remote
server instance in the cluster
– Replicating HTTP session states and stateful session EJB
states between a primary and a secondary server
– Accessing clustered objects that reside on a remote server
instance (typically, in a multi-tier cluster architecture)

Multi-Tier Communications
 Multi-tier clusters will require more IP sockets than a

combined-tier cluster:
– One socket for replicating session states
– One socket for each WebLogic Server in the EJB cluster, for
accessing remote objects
 As an example, using a three-node cluster, the worst-
case scenario would be five open sockets per server:
– One primary and secondary replicated session
– Each server simultaneously invokes a remote EJB method on
each node in the cluster

Communication in a WAN
 In a WAN, the servers in your cluster may span

multiple subnets.
 In order for multicast messages to reliably transmit
across the WAN, your network must meet the
following requirements:
– Full support of IP multicast packet propagation
– A network latency that allows for multicast messages to
reach their destination in 200 to 300 milliseconds
– A multicast time-to-live value high enough to ensure that
routers do not discard multicast packets

Section Review

 Describe how servers communicate in a cluster
 Understand how multi-tier clusters communicate

Module Review
In this module, we learned how to:

 Describe the differences between a basic cluster
architecture and a multi-tier cluster architecture
 Use a proxy server to load balance requests to a cluster
 Describe how servers in a cluster communicate

Module 13
Configuring a Cluster
 Prepare your environment for a cluster
 Create and configure a cluster
 Create and configure a proxy server
Configuring a Cluster-1 © 2007 BEA Systems, Inc. 607

Road Map
1. Preparing for a Cluster

– Cluster License
– Cluster Architecture
– Network and Security Topology
– Machines
– Names and Addresses
2. Configuring a Cluster
3. Configuring a Proxy Server

Preparing Your Environment
 Before you can configure a cluster, there are steps you

need to take to prepare your environment.
– Obtain a cluster license.
– Determine your cluster architecture.
– Understand your network and security topologies.
– Choose the machines for the cluster installation.
– Identify IP Addresses or DNS names, and port numbers for
the server instances in the cluster.

Cluster License
 Clustered WebLogic server instances must have a valid

cluster license.
 To update your current license, use the
UpdateLicense.cmd in the main BEA directory.
– UpdateLicense <new_license_file>
<license
component="Cluster"
cpus="unvalued"
expiration="never"
ip="any"
licensee="BEA Internal Development"
serial="616351266349-1844896394531"
type="SDK"
units="5"
signature="MC0CFQCQrk+Kbddfz3RHVH6uGfj"
/>

Cluster Architecture
 Will you be using a single tier or a multi-tier

architecture?
 How are you going to do your load balancing?
– Are you going to use basic WebLogic server load balancing?
– Will you use a third-party load balancer?
 Are you going to use demilitarized zones with firewalls?

Network and Security Topology
 Will your cluster exist in a single LAN?

 Will your cluster span a MAN or a WAN?
 Depending on the network topology you choose, your
security requirements will change.
– Some network topologies can interfere with multicast
communications.
– Avoid deploying server instances in a cluster across a
firewall.

Security Options for Cluster
Architectures
 For proxy architectures you could have:

– A single firewall between untrusted clients and the Web
server layer
– A firewall between the proxy layer and the cluster
 When using a load balancer, in addition to the security
features provided with the load balancer, you may want
to place a firewall between it and untrusted clients.
 When you use a single database supporting both
internal and external data:
– Place an additional firewall in front of the database server

Hardware
 You may set up a cluster on a single, non-multihomed

computer for demonstration or development.
– This is not practical for production environments.
 The machine cannot have a dynamically assigned IP
address.
 There is no built-in limit for the number of server
instances in a cluster.
– The only limitation is your license.
– Large, multi-processor servers can host large clusters.
– The recommendation is one WebLogic Server instance for
every two CPUs.

Clustering on One Piece of Hardware
 To set up a cluster on one machine, the server is not

required to be multi-homed; the servers in a cluster can
use one IP address.
 All servers in a cluster can use a dedicated multicast
port number for inter-server communication:
– Required, if servers are using a single IP address
– Useful for segmenting multicast traffic among specific NICs

Names and Addresses
 Location information will be needed for:

– The administration server
– Managed servers
– Multicast location
 For a production environment, use DNS names, as
opposed to IP addresses.
– Firewalls can cause IP address translation errors.
 Each WebLogic server resource should have a unique
name.
 The multicast address should not be used for anything
other than cluster communications.

Cluster Address
 The cluster address is used in entity and session beans to

construct the host name portion of request URLs.
 You can explicitly define the address of a cluster.
– The cluster address should be a DNS name that maps to the IP addresses
or DNS names of each WebLogic server instance in the cluster.
 You can also have WebLogic Server dynamically generate an

address for each new request.
– Minimizes configuration
– Ensures accurate cluster address
 The dynamic cluster address is created in the form of:
listenaddress1:listenport1,listenaddress2:listenport2,listen
address3:listenport3

Section Review

 Prepare the environment for a cluster

Road Map

– Configuration Wizard
– WLST
– Ant

Configuration Options
 There are multiple ways to create and configure a

WebLogic Server cluster:
– Ant
– WLST

Creating a Cluster Using the
Administration Console…
1
2

…Creating a Cluster Using the

Configuring Multicast

Adding Servers…

…Adding Servers

Creating a Cluster with the
Configuration Wizard

Using the Cluster MBean
 The Cluster MBean is used to create a cluster using Ant

or command-line tools.
 Configuring the cluster from the command line requires
the combined use of Cluster and Server MBeans.
 To create new clusters within a domain, use:
weblogic.management.configuration.ClusterMBean

Creating a Cluster with WLST
connect('system','weblogic', 't3://localhost:7001')
edit()
startEdit(-1,-1,'false')
cd('/')
cmo.createCluster('dizzyworldCluster')
cd('/Clusters/dizzyworldCluster')
set('MulticastAddress','239.192.0.0')
set('MulticastPort','7050')
cd('/')
cd('/Servers/dizzy1')
cmo.setCluster(getMBean('/Clusters/dizzyworldCluster'))
activate()
disconnect()
exit()
1
011

Creating a Cluster with Ant
<wlconfig url="t3://localhost:7001" username="system"

password="weblogic">
<create type="Cluster" name="dizzyCluster">
<set attribute="MulticastAddress" value="234.0.0.1"/>
<set attribute="MulticastPort" value="7070"/>
<set attribute="ClusterAddress“
value="127.0.0.1,127.0.0.1,127.0.0.1"/>
<set attribute="DefaultLoadAlgorithm" value="round-robin"/>
</create>
<set attribute="Cluster"
value=“dizzyworld:Name=dizzyCluster,Type=Cluster"
mbean=" dizzyworld:Name=dizzy1,Type=Server"/>
value="dizzyworld :Name=dizzyCluster,Type=Cluster"
mbean="development:Name=dizzy2,Type=Server"/>
value="dizzyworld:Name=dizzyCluster,Type=Cluster"
mbean="development:Name=dizzy3,Type=Server"/> 1
011

Starting Servers in a Cluster
Servers in a cluster start just like

managed servers.
Servers boot and join the cluster.

Section Review

 Configure a cluster in the administration console
 Create a cluster using the configuration wizard
 Configure a cluster using WLST
 Configure a cluster using Ant

Road Map

– HTTPClusterServlet
– Apache

WebLogic Proxy Servers
 The WebLogic HTTPClusterServlet runs within

a Web application deployed on a WebLogic server.
– The servlet proxies requests to other servers in a cluster.
– It should run on a separate, non-clustered managed server.
 A WebLogic proxy server can be created initially using
the Configuration Wizard.
– You can also manually set up the Web application with the
HTTPClusterServlet and deploy it on the managed server.

Create the WebLogic Proxy Server with
the Configuration Wizard

Creating the WebLogic Proxy Server
Manually
 The HttpClusterServlet is specified in the

web.xml file of the default Web application on the
proxy server.
 This file must reside in the \WEB-INF directory of the
web application directory.
 The proxy servlet needs to be defined as the default
Web application for the managed server.
– This is defined in the weblogic.xml deployment
descriptor located in the \WEB-INF directory of the Web
application.

Configuring the HttpClusterServlet
 The HttpClusterServlet is specified in the

web.xml file of the default Web application on the
proxy server.
HttpClusterServlet Declaration:
<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>
weblogic.servlet.proxy.HttpClusterServlet
</servlet-class>
… …
</servlet>
10
0101
<web.xml> 1110

Specifying Initial Parameters
Declaring initial parameters:

<servlet>
<servlet-class>
weblogic.servlet.proxy.HttpClusterServlet
</servlet-class>
<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>
serverA:7001:7002|serverB:7001:7002|serverC:7001:7002
</param-value>
</init-param>
<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ON</param-value>
</init-param>
</servlet>
10
0101
<web.xml> 1110

Servlet Mapping
Configuring servlet mapping:

<servlet>
…
</servlet>
<servlet-mapping>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
10
0101
<web.xml> 1110

HttpClusterServlet Initialization
Parameters…
Default
Parameter Usage
Value
(Required) A list of host names and port
WebLogicCluster numbers of the servers to which requests (none)
are proxied.
ON/OFF ON enables SSL between
secureProxy HttpClusterServlet and the server it OFF
proxies to.
ON/OFF ON lets you query the
DebugConfigInfo HttpClusterServlet for debugging OFF
information.
Maximum time in seconds that the servlet 0
ConnectTimeoutSecs should attempt to connect to the WebLogic (infinite
Server host. timeout)
Interval in seconds that the servlet will sleep
ConnectRetrySecs between attempts to connect to a server 5
instance.

…HttpClusterServlet Initialization
Parameters
Default
Parameter Usage
Value
pathTrim The string to trim from the beginning of the

none
original URL.
trimExt The file extension to trim from the end of the

none
URL.
pathPrepend The string to prefix to the original URL after

pathTrim is trimmed. none

Third-Party Proxy Servers
 If you are using a supported third-party web server,

instead of a WebLogic web server, you will need to set
up a proxy plug-in.
 The following are the supported third-party web
servers:
– Netscape Enterprise Server
– Apache
– Microsoft Internet Information Server

Configure Apache Plug-in…
 Install the Apache HTTP Server plug-in as a module in

your Apache HTTP Server installation.
 The module can be configured in two different ways:
– As a dynamic shared object
– As a statically linked module (1.3.x and higher)
 To configure the Dynamic Shared Object, select shared
object type
– mod_wl_20.so (Standard Apache Version 2.x)
– mod_wl_ssl.so (Apache with SSL/EAPI)

…Configure Apache Plug-in…
 Edit the httpd.conf file and include WebLogic Server

Modules.
– LoadModule weblogic_module
modules/mod_wl_20.so
 Add an IfModule block to define the WebLogic Cluster
Instance.
<IfModule mod_weblogic.c>
WebLogicCluster
127.0.0.1:7003,127.0.0.1:7005,127.0.0.1:7
007
</IfModule>

…Configure Apache Plug-in
 Add the proxy path.
<Location /weblogic>
SetHandler weblogic-handler
WebLogicCluster
127.0.0.1:7003,127.0.0.1:7005,127.0.0.1:7007
DebugConfigInfo ON
PathTrim /weblogic
</Location>

Apache Plug-in and SSL
 You can use the Apache Plug-in with SSL to guarantee

the confidentiality and integrity of data.
 The Apache HTTP Server Plug-In does not use the
transport protocol (http or https) specified in the HTTP
request.
 Even though you can use two-way SSL authentication
between the client and Apache, one-way authentication
will be used between Apache and WebLogic.

Configure Apache Plug-in SSL
 To enable SSL between Apache and WebLogic

– Configure WebLogic for SSL.
– Configure WebLogic Server’s SSL listen port.
– Set the WebLogicPort in httpd.conf to the WebLogic SSL
listen port.
– Set the SecureProxy parameter in httpd.conf to ON.
– Install a trusted certificate authority file on Apache. You
can use the DemoTrust.jks that comes with WebLogic.

Section Review

 Set up the HTTPClusterServlet for proxying
 Set up Apache for proxying

Exercise
Create a Cluster

Exercise
Configure Proxy Servers


Module Review

 Prepare your environment for clusters
 Configure a cluster using different tools
 Configure WebLogic Server and third-party proxy
servers

Module 14
Managing Clusters
 Deploy applications to a cluster
 Manage session state in a cluster
 Troubleshoot a cluster
Managing Clusters-1 © 2007 BEA Systems, Inc. 651

Road Map
1. Deploying Applications to Clusters

– Packaging Applications
– Two-Phase and Side-by-Side Deployment
– Deployment Best Practices
2. Session Management
3. Troubleshooting a Cluster

Packaging Applications
 When deploying applications to a single managed

server, they can be deployed in an exploded format.
 When deploying applications to a cluster of managed
servers, they must be packaged into a .war, .ear or .jar.

Two-Phase Deployment
 Applications are deployed using two-phase deployment

(TPD).
 Applications are copied to the cluster and activated in
two phases:
– Phase 1: distributes application components and modules to
the server
– Phase 2: deploys the application if phase 1 is successful and
permits client access
 This ensures that an application is available and active
on each node before clients can access it.

Deploying Applications to a Cluster
 All nodes must be running before an application can be deployed

to a cluster.
 If phase 2 of two-phase deployment fails, the application will
still be 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
was partitioned at the time of deployment.
– Avoid this by using the enforceClusterConstraints tag with
weblogic.Deployer
– Or check the Enable Cluster Constraints box in the console
 Do not change cluster membership while deploying applications
to the cluster.

Side-by-Side Redeployment in a
Cluster
 When using production redeployment of an application

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

Deploying Applications to a Cluster...

...Deploying Applications to a Cluster
3

Section Review

 Package applications for deployment in a cluster
 Deploy applications in a cluster

Road Map

– HTTP Session Clustering
– Replication Groups
– In-Memory Replication
– Persistent Replication
– Replication Within a MAN or WAN

HTTP Session State Replication
 WebLogic Server provides clustering support for JSPs and

Servlets by replicating 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.

Machines
 In WebLogic Server, machines names are used to

indicate that a managed server runs on a particular
piece of hardware.
 Machine definitions are one of the factors 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 lets you 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.

Configuring Replication Groups
 Select each server in a cluster, and assign each a pair of

replication groups.

Ranking Servers
 WebLogic Server ranks the servers in a cluster to

determine which server to use as the backup.
Is the Server a Does the Server Reside

Member of a Preferred on a Different Server Rank
Secondary Group? Machine?
Yes Yes 1
No Yes 2
Yes No 3
No No 4

In-Memory Replication…
 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 Primary
replication group and machine definition.
– The object is created immediately after
the primary object is created. Server 3
 Primary failure makes the backup Secondary

object the primary object.
Cluster

…In-Memory Replication
Server 1
Server 1
Primary
Primary
Server 2
Server 2
Primary
Secondary
Server 3 Server 3
Secondary
Cluster Cluster
Before After

Failover with Replication Groups
domain
machine 1
X
server A
servlet
primary
Load X state
Balancer machine 2
server B server C
servlet servlet
client primary secondary
state state
Firewall Cluster
Cookie
Primary: server A
Secondary: server B

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 HTTP session state,
clients must access the cluster using either:
– Load-balancing hardware (WLS aware)
– A collection of Web servers, or a single Web server, with
WebLogic proxy plug-ins (configured identically)
– WebLogic server configured with HTTPClusterServlet

Configuring In-Memory Replication
 To configure in-memory replication:

1. Configure a proxy server (if applicable).
2. Configure replication groups and/or machines (optional).
3. Specify the persistence type in the weblogic.xml
deployment descriptor:
Configuring in-memory replication session persistence:

<session-descriptor>
<persistent-store-type>replicated</persistent-store-type>
</session-descriptor>
10
0101
1110
<weblogic.xml>

Persistent JDBC Replication
– ALL server instances have Cluster Common access

access to ALL sessions. obtained via
Server 1
identical
– Subsequent requests from Servlet1 connection pools
same client can be handled Servlet2
by ANY server.
• Great failover capability Server 2
• Significant performance Servlet1
reduction
– Changing session objects Servlet2
causes (slow) DB Database
Server 3
synchronization. HttpSession objects
Servlet1
stored in database
Servlet2

Configuring JDBC Replication
 To configure JDBC replication:

1. Create a table in the database.
2. Create a connection pool that has read/write privileges for your database.
3. Configure your session persistence in the weblogic.xml deployment
descriptor.
Example of configuring session persistence:

<persistent-store-type>jdbc</persistent-store-type>
<persistent-store-pool>SessionDS</persistent-store-pool>
<persistent-store-table>WL_SERVLET_SESSIONS</persistent-
store-table>
10
0101
1110
<weblogic.xml>

JDBC Persistent Table Configuration
 A database table named WL_SERVLET_SESSIONS must

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

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

File Persistence
 Session state may also be stored in a file.

 For file-base persistence:
– You must create the directory in which to store the file.
– The file must have the appropriate access privileges.

Configuring File Persistence
 To configure file-based session persistence for a Web

application:
1. Create a folder shared by all servers on the cluster.
2. Specify the file persistence type in the weblogic.xml
deployment descriptor:
Example of configuring session persistence:

<persistent-store-type>file</persistent-store-type>
<persistent-store-dir>shared folder location</persistent-
store-dir>
10
0101
<weblogic.xml> 1110

Session State Replication Across
Clusters
 HTTP session state across clusters improves high-

availability and fault tolerance.
 Cross-cluster replication is achieved using global and
local hardware load balancers.
Global Load Balancer
Local Load Balancer Local Load Balancer
Replication Channel
Cluster A Cluster B
Domain A Domain B

Session Replication in a MAN
 In the case of a MAN, if you want session replication

between two cluster instances because they are
relatively close together, you can replicate session
states synchronously.
– Assumes there is a high-speed, low-latency connection
between the two clusters
– Uses in-memory replication
 MAN replication relies on a global load balancer to
maintain cluster affinity and a local load balancer to
maintain server affinity.

Session Replication in a WAN
 If you want to failover requests from one cluster to

another across a WAN in the event that one of the
clusters completely dies, you can use the WAN session
state replication.
 WAN session state replication entails:
– In-memory replication of the session state to a local server
instance
– Asynchronous JDBC persistence to a remote cluster instance

Configuration Requirements for Cross-
Cluster Replication
 Load balancers must be installed.

– They must be able to maintain session IDs.
– The cluster failover timeout should not be set too high.
– They must know which backup cluster to use when a primary cluster or
server fails.
 Domains must be configured.

– Each domain must be configured identically.
– Application deployment must be identical.
– The domains need to trust each other.
 In a WAN environment, there must be a data source setup to
maintain session state.
 The cluster must be configured for cross-cluster replication.

Configuring a Cluster for Cross-
Cluster Replication

State Management Best Practices
 Create WLS machines if you are replicating state

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

Section Review

 Configure HTTP session clustering
 Configure replication groups
 Configure in-memory replication
 Configure JDBC and file persistent replication
 Replicate session state within a MAN or WAN

Road Map

– Invalid License
– Server Versions
– Multicast
– CLASSPATH
– Thread Count
– Garbage Collection

Invalid License
 If a valid cluster-enabled license is not found in

license.bea when WebLogic Server starts, it will
not join a cluster.
– You will see the error message "Unable to find a license for
clustering."

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 utility
utils.MulticastTest
Valid IP Multicast Addresses:
224.0.0.0 to 239.255.255.255
IP Multicast Test Utility:
java utils.MulticastTest -N <name> -A <multicastAddress>
-N name (REQUIRED) -A address (REQUIRED)

-P port number -T timeout in seconds
-S send pause -L time to live 10
0101
1110

Example: Test Multicast

CLASSPATH
 The CLASSPATH value must be the same on all

managed servers in the cluster.
 The CLASSPATH is set by the setEnv script when
the startManagedWebLogic file is run.

Garbage Collection
 The frequency and length of the garbage collection can

affect a cluster.
 If garbage collection is taking too long, the servers will
not be able to make the heartbeat signals.
 Heap allocation can be tuned to adjust the length of
garbage collection.
– This can be changed using the –Xms and –Xmx parameters in
the server startup script.

Section Review

 Troubleshoot common issues with starting a cluster of
servers

Exercise
Manage HTTP Session States


Module Review

 Deploy applications to a cluster
 Manage and configure session state in a cluster
 Troubleshoot common issues in a cluster

Module 16
Clustering Services
 Set up whole server migration
 Understand JNDI clustering
 Understand JDBC clustering
 Migrate a JMS server
 Migrate transactions
Clustering Services-1 © 2007 BEA Systems, Inc. 721

Road Map
1. Clustering Services
– Clusterable Services
– Service Level Migration
– Server Level Migration
2. JNDI
3. JDBC
4. Transactions
5. JMS

Which Services Can Be Clustered?
 A clustered service is an API or interface that is

available on multiple servers in a cluster.
 WebLogic Server provides clustering services for:
– Web applications
– EJB and RMI objects
– JNDI tree
 WebLogic Server provides limited clustering services
for:
– JDBC connections
– JMS destinations

Service Failover
 Services that are deployed to all servers in a cluster

automatically have transparent failover.
 JMS and JTA cannot be deployed to all 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-Level Migration
 Service-level migration is performed manually.

 Pinned services are moved from the failed server to a
new server.
– The new server then takes over and processes any data left
over when the server failed, and then takes over any future
processing.
 A migratable service is accessed by clients using a
migration-aware RMI stub.

Server-Level Migration
 Server-level migration moves the whole clustered server

instance, in its entirety.
– It is an alternative to service-level migration.
– They should not be used together.
 Server-level migration is:

– Only supported using the Secure Shell (SSH) version of Node Manager
– Not supported on Windows
 Server-level migration can happen both manually and
automatically.
 When a migratable server fails:
– The server is automatically restarted on the same machine.
– If it cannot be started on the same machine, it moves to another machine.

Server Level Migration Services and
Resources
 Migratable servers
– Managed servers that host pinned services
 Cluster master
– One server instance that orchestrates the process of automatic server
migration
 Target machines
– Allowable or preferred hosts for migratable servers
 Node Manager
– A process that starts and stops server instances
 Lease table
– A database table where migratable servers persist their state information
 Administration Server
– Configures migratable servers and target machines as well as obtains the
state of migratable servers and orchestrates the manual migration process

Server Migration Environment
 Before configuring server migration, your environment

must be set up properly.
– Each managed server must use the same subnet mask for
multicast communications.
– Each server hosting migratable services should be time
synched.
– All operating system versions must support identical
functionality for ifconfig.
– Interface names for each server should be the same.
– The database you are using to support migration must be
supported.

Server Migration Configuration…
 To configure server migration:

– Configure each machine using server migration with a
floating IP address.
– Configure the SSH version of Node Manager on each
managed server (it must be running as well).
– Configure the database by creating the leasing tables used to
store machine-server associations.
– Configure a data source to point to the server migration
database.
– Grant superuser privileges to the wlsifconfig.sh script.
– Ensure that wlsifconfig.sh, wlscontrol.sh and
nodemanager.domains are included in your machine's
PATH.

…Server Migration Configuration…
 To configure server migration (continued):

– Ensure that the machines hosting migratable services trust
each other.
– Set the candidate machines for server migration.
– Edit wlscontrol.sh and set the Interface variable to the
name of your network interface.
– Configure the server properties to enable server migration.

…Server Migration Configuration

Server Migration Restrictions
 Each managed server must be configured to use the

same subnet mask.
 Channels/Network Access Points must not have
different Listen Addresses on a migratable server.
 There is no built-in mechanism for transferring files.
– You should store files on a different disk that is accessible by
all the machines.
 Node Manager security files must be copied to each
machine.
– You can use the nmEnroll() WLST command.

Migratable Server Startup Process
Machine A Machine B Machine C Database

Managed Managed
Admin Node Node Lease
Server Config Server Config
Server Manager Manager Table
1 2
Start cluster
Contact NM
Start MS1
Obtain configuration
Cache
Config
Obtain migratable server leases and cluster master lease
Renew leases (periodically)
Contact NM
Start MS2
Cache
Config
Obtain migratable server leases
Renew leases (periodically)

Automatic Server Migration
Machine C Machine B Database Machine A Machine D

Managed Managed Managed
Node Node Lease Admin Node
Server 2 Server 1 Server 2 Config
Manager Manager Table Server Manager
(migratable) Cluster Master (migratable)
Machine C fails Cluster Master detects

that Mged Server 2's
lease is expired
Cluster Master tries to contact NM
Cluster Master contacts NM

Start Mged
Server 2
Obtain lease
Cache config

Manual Server Migration
Machine A Machine C Database Machine D

Managed Managed
Admin Node Lease Node
Server 2 Server 2 Config
Server Manager Table Manager
(migratable) (migratable)
Initiate manual
migration
Contact NM
Stop Managed
Server 2
Give up lease
Contact NM
Start Managed
Server 2
Cache
config

Section Review

 Understand what services are clusterable
 Understand the difference between service-level
migration and server-level migration
 Set up server-level migration

Road Map
2. JNDI
– Cluster-Wide JNDI Server
– JNDI Naming Conflicts
3. JDBC
4. Transactions
5. JMS

JNDI Clustering Support
 The JNDI tree contains factory objects for accessing

these items:
– JDBC DataSources
– EJBs, RMI objects
– JMS connection factories
 WebLogic Server replicates clusterable objects to all
servers on a cluster, transparently.

Cluster-Wide JNDI Service
 Each WLS server issues messages

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

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

JNDI Naming Conflicts
 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 non-clustered.
 In a cluster, a naming conflict can occur when the
server tries to bind a clustered object with the same
name as a non-clustered 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 servers in the cluster.
– Deploy to the cluster itself, not the individual servers.

Section Review

 Understand how JNDI clustering works
 Deal with JNDI naming conflicts

Road Map
2. JNDI
3. JDBC
– JDBC Clustering
– Clustering vs. Multi-Data Sources
– Targeting a Data Source to a Cluster
4. Transactions
5. JMS

JDBC Clustering
 These 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.

Clustering vs. Multi Data Sources
Feature Cluster Multi Data Source
Local Clients Access via JNDI Access via JNDI
Remote Clients Access via JNDI Access via JNDI
Failover None On the same server (High-

Availability Algorithm only)
Load balance None On the same server (Load-

Balance Algorithm only)

Targeting a DataSource to a Cluster...
1 2

...Targeting a DataSource to a Cluster

Section Review

 Understand JDBC clustering capabilities
 Understand the difference between JDBC clustering
and multi data sources
 Deploy a JDBC data source to a cluster

Exercise
Cluster JDBC Data Sources


Road Map
2. JNDI
3. JDBC
4. Transactions
– Transaction Recovery Service
– Migrating JTA
5. JMS

Transaction Recovering After Failure
 The Transaction Manager (TM) makes every effort to

resolve prepared transactions even after multiple
crashes.
 The 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 Service
 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

Recovering JTA Without a Cluster
 To recover transactions from a non-clustered server:

– 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 Transactions in a Cluster
 When recovering 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 transaction log files from the failed server and
attempts to complete in-flight transactions.
• If TRS on the backup server successfully completes all incomplete
transactions, the server releases ownership of the TRS.
– Whole Server Migration
• Migrates the server in its entirety, along with all the services it hosts

Recovering Transactions for a Failed
Clustered Server (Manually)
 Manually migrate the TRS from the crashed server to
another server in the cluster using the admin console
or the command-line interface:
1. The TRS on the backup server takes ownership of the
transaction log from the failed server.
2. The TRS searches transaction log files from the failed server
for incomplete transactions and completes them.
3. If the TRS on the backup server successfully completes all
incomplete transactions from the failed server, it releases
ownership of the TRS (including transaction log files) for
the failed server, so the failed server can reclaim it upon
restart.

Configuring JTA Service Migration
 Before you can manually migrate JTA, you can define

which servers are available for migration.
 To set up the candidate servers, use:
Environment  Servers  Configuration  Migration

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

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 only processes incomplete transactions.
• The backup server does not accept new transaction work for the
failed server.
– The backup server does not process heuristic log files.

Section Review

 Understand how the transaction recovery service
recovers transactions after a failure
 Manually migrate transactions to another server in the
cluster

Road Map
2. JNDI
3. JDBC
4. Transactions
5. JMS
– Clustering JMS
– Distributed Destinations
– JMS Failover

JMS Clustering Support
 WebLogic Server supports targeting JMS connection

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

JMS Connection Factory Clustering...

...JMS Connection Factory Clustering

Distributed Destination
 A distributed destination has these 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 to and receive from
a distributed destination.
 WebLogic JMS distributes the load across the available
physical destinations within the distributed destination.

Distributed Queues
WebLogic Server 1
Senders JMS ServerA
...
s1 s3 m9 m8 m3 queue
Q
s2 Receivers
JMS ServerB
r1
Dest3
...
m7 m5 m4 queue r2
Q
r3
WebLogic Server 2
JNDI Tree r4
Dest1 JMS ServerC
Dest2
Dest3 ...
Dest4 m6 m2 m1 queue
Q

Distributed Topics
WebLogic Server 1
Persistent
Publishers JMS ServerA Storage
...
p1 p3 m3 m2 m1 topicT
p2 Subscribers
JMS ServerB
s1
...
Dest3 s2
m3 m2 m1 topicT
s3
WebLogic Server 2
JNDI Tree s4
Dest1 JMS ServerC
Dest2 ...
Dest3
Dest4 m3 m2 m1 topicT

Create a Distributed Topic…

…Create a Distributed Topic…

…Create a Distributed Topic

Distributed Destination Threshold and
Quota

Server Affinity
 WebLogic will try to establish new connections to the

same servers as existing connections.
 Applies to distributed destinations only.
For a new JMS connection distributed destination:

1. Attempts to create a connection on the same server as the JNDI
initial context, the original client connection server instance
2. Attempts to create a connection to a server with which the client
already has a connection, JMS or non-JMS. This may be JTA or
JMS transaction dependent.
3. Creates the connection on any server.

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 zero consumer.
 Persistent messages are put in a backing store.

…Zero Consumers
WebLogic Server 1
JMS ServerA
...
s1 s3 m6 m3 m2 queue
Q
s2
JMS ServerB
r1
Dest3 X queueQ
r3
WebLogic Server 2
JNDI Tree r4
Dest1 JMS ServerC
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 cluster-

wide JNDI service.
 Select Replicate JNDI Name in Cluster in the admin
console.
 Use the isJNDINameReplicated() method in the
JMSQueueMBean or JMSTopicMBean.
 Clients look up a destination on any server and receive
a connection on the actual server.

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.

JMS Server Migration
 JMS is an exactly-once service; each JMS server exists

on exactly one WebLogic server.
 When a WebLogic server fails, its JMS servers can be
migrated. 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 a WebLogic server that
already hosts distributed destination members.
 Migration may be a part of scheduled maintenance.

Performing Migration
 Services migrated to a non-running server will be

started when the server starts.
 Migration can be manually initiated or automatically
initiated.
– Automatic migration happens through whole server
migration only.
 It is possible to use third-party products to perform
migration:
– JMX
– Veritas HA

JMS Migratable Targets
 The JMS server can be manually migrated to any other

server in a cluster.
– Optionally, an administrator can limit which servers will
receive the migrated JMS server by specifying a defined set
of migratable targets within a cluster.

Migrate JMS Data
 For the JDBC store:

– If it is on the failed server, migrate the database to the new
server and change the JDBC URL for the JDBC store’s
DataSource.
– If it is not on the failed server, no changes are required.
 For the file store:
– Migrate to a new server.
– Ensure that the pathname is the same on the new server as the
original one.
 For transactions, also migrate the transaction logs.

Migration Configuration
 To configure a JMS migration:

1. Define migratable target servers in the cluster.
2. Create JMS Servers and assign to the migratable targets.
3. Create physical member destinations (use the auto-deploy
option for distributed destinations).

Configure a Migratable Target

Target JMS Server to a Migratable
Target

Migrate Services

Section Review

 Handle failover and load balancing of JMS connections
 Cluster a JMS connection factory

Exercise
Load Balance JMS Messages


Module Review

 Migrate a whole server
 Cluster JNDI objects
 Cluster JDBC data sources
 Cluster transactions
 Cluster JMS connection factories

Module 18
Introduction to BEA Ed.Lab

 Install a new course using Ed.Lab
 Execute commands against Ed.Lab
 Explain the components that implement Ed.Lab
Introduction to BEA Ed.Lab-1 © 2007 BEA Systems, Inc. 819

Road Map
1. Getting Started with Ed.Lab

– Install a Course
– Set Up a Lab Exercise
– Continue a Previous Lab Exercise
– Continue Your Current Work
2. Ed.Lab Internals

What Is Ed.Lab?
 Ed.Lab:
– Is an extensible Java framework used to install and execute
labs and demos within BEA courses
– Allows students and instructors to concentrate on a lab’s
learning objectives, not on its infrastructure
– Maximizes a student’s time to complete an exercise
– Avoids course-specific setup instructions and scripts
– Supports both Windows and Linux
 Ed.Lab consists of the following components:
– Course Installer
– Lab Framework

Install a Course
 Execute the native script install.cmd or

install.sh on the student media provided with
the course, such as a CD.
 Complete the following steps:
1. Supply a path to which the course will be installed.
2. Provide the path of your BEA HOME, such as c:\bea.
3. Provide the path of your WEBLOGIC 10.0 HOME, such as
c:\bea\wlserver_10.0
4. Provide the path of an existing Java 5 JDK, such as
c:\bea\jdk150_06

Installation Steps
 The Course Installer performs the following steps:

1. Extract the course contents to the supplied path.
2. Update variables for BEA, WEBLOGIC 10.0, and JDK
paths within the following files:
 bin/prompt.cmd
 bin/prompt.sh
 edlab/edlab.properties
 */pointbase.ini
3. Send the command setup_course to the Lab
Framework for any custom installation steps.
 A log file is also generated for debugging.

Reference Variables
 The following variables are used throughout the course to

refer to common files or directories.
Variable Description Examples
BEA_HOME BEA root installation C:\bea
directory D:\bea100
WEBLOGIC_HOME WebLogic product C:\bea\wlserver_10.0
installation directory D:\bea100\wlserver_10.0
JAVA_HOME Java 5 JDK installation C:\bea\jdk150_06
directory D:\java\jdk150_06
STUDENT Course installation C:\student\mycourse
directory D:\mycourse
CURRENT_LAB Resource directory <STUDENT>\labs\lab01
associated with the lab you <STUDENT>\labs\lab11
are currently working on

Lab Framework
 The Ed.Lab Lab Framework automates the

initialization of resources and infrastructure for a
specific lab:
– Create and update WebLogic Server domains
– Launch domain administration servers
– Launch database servers
– Update databases
– Update application source
– Deploy J2EE applications
 The Lab Framework maintains a backup copy of each
lab to allow students to restore previous work.
Start a New Lab
 To begin work on an exercise, perform the following

steps:
1. Execute bin/prompt.cmd (or .sh).
2. Change directories to the location associated with the lab:
cd lab01.
3. Type the following command:
ant setup_exercise.
 Lab resources, such as application source, will be

placed under the work directory.
 Any work from a prior lab will be backed up.

Continue an Existing Lab
 To continue working on a previously started exercise,

perform the following steps:
cd lab01.
ant continue_exercise.
 Backup resources will be restored to the work

directory.

Start a Lab Solution
 To begin working on the complete solution for a

given lab, perform the following steps:
cd lab01.
ant setup_solution.

Continue Your Current Work
 While working on a lab, some situation may result in

the shut down of your servers or databases, such as a
machine restart.
 To continue working on the current exercise, perform
the following steps:
2. Change directories to work:
cd ../work.
ant continue_work.

Start a New Demo
 To initialize and begin presenting a course

demonstration, perform the following steps:
2. Change directories to the location associated with the demo:
cd ../demos/demo01.
ant setup_demo.

Additional Documentation
 You can find additional Ed.Lab documentation at the

location <STUDENT>/edlab/docs.

Section Review

 Explain the capabilities of Ed.Lab
 Install a course
 Start a new lab
 Continue an existing lab

Road Map
1. Getting Started with Ed.Lab

2. Ed.Lab Internals (Optional)
– Course Layout
– Dispatcher
– edlab.properties

Course Layout
 The layout of a typical Ed.Lab course is shown below:
Directory Tree Description
Course root location, selected during installation

Native scripts, such as prompt.cmd
Resources for any course demonstrations
Lab Framework scripts and configuration files
Resources to initialize during course installation
Resources for any course labs
Workspace containing files for the current lab or demo

Lab Framework Implementation
3
1 «Ant»
«Ant» «Ant» «Ant»
«Ant» :Task
«Ant»
build.xml dispatcher.xml :Task
build.xml :Task
2
edlab.properties
:Event Handlers
:Tasks

Lab Framework Layout
Directory Tree Description

Lab Framework root directory
Resources (apps, etc.) common to all labs
Ed.Lab documentation
Lab Framework log files
Application init and deployment scripts

Database start and update scripts
Domain initialization and update scripts
Miscellaneous scripts
Server start script

Server update script
Lists the current lab
Dispatcher Ant script
Default Lab Framework configuration

Lab Framework Configuration…
 The Dispatcher determines how to process a request, or

event, using the file edlab.properties.
 You can also configure individual task scripts using
this file.
 A default edlab.properties is under the edlab
course directory.

…Lab Framework Configuration
 An individual lab or demo may have its own copy of

edlab.properties.
 Properties in this file will be merged with the default
configuration file.

Sample Configuration
jdkhome=d\:\\bea100\\jdk150_06
beahome=d\:\\bea100 Initialized by Installer
wlhome=d\:\\bea100\\wlserver_10.0
event.setup_exercise=handler2 Assign handlers

to events
event.continue_exercise=handler3
event.setup_exercise.path=exercise
handler.handler2=domainbackupwork,appbackupwork,setcurrentlab,
initdomain,startdb,startserver
Assign tasks
task.domainbackupwork=tasks/domain/backup_work.xml to handlers
task.appbackupwork=tasks/app/backup_work.xml
task.setcurrentlab=tasks/misc/set_current_lab.xml
task.initdomain=tasks/domain/init_domain.xml Register task
task.startdb=tasks/db/start_db.xml Ant scripts
task.startdb.db1.url=jdbc:pointbase:server://localhost:9093/demo
...
1
011
<edlab.properties>
Section Review

 Describe the components that make up the Lab
Framework
 Understand the purpose and contents of
edlab.properties

Module Review

 Explain the features of BEA Ed.Lab
 Use the Course Installer
 Use the Lab Framework

Module 19
Virtual Host

 Explain what virtual hosting is
 Create virtual hosts
 Configure virtual hosts
 Monitor virtual hosts
Virtual Host-1 © 2007 BEA Systems, Inc. 843

Understanding Virtual Hosts
 Virtual hosts:
– Have one or more Web addresses associated with them
(Domain name and IP address)
– Allow 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 more than one domain name.

The Big Picture of Virtual Hosting
Requests for www.example.com
Web Web
App 1 App 2
VirtualHost1 Web
App 3
VirtualHost2
Web Web
App 4 App 5
Requests for www.demo.com

WebLogic Server

Configuring Virtual Hosts
Steps to configuring a virtual host:

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
1
3
Virtual Host Application

Creating Virtual Hosts

Targeting Virtual Hosts to Servers

Targeting Applications to a Virtual Host

Configuring Virtual Host Logging

Review

 Creating virtual hosts
 Deploying Web applications to virtual hosts
 Targeting virtual hosts to servers
 Targeting virtual hosts
to clusters
 Monitoring virtual hosts

Weblogic 9 Ï Í ÜÀí

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Weblogic 9 Ï Í ÜÀí

Uploaded by

Copyright:

Available Formats

Module 1

BEA Systems, Inc.

BEA WebLogic Server 9/10: System

Overview-1 © 2007 BEA Systems, Inc. 1

 The course presents:

Overview-5 © 2007 BEA Systems, Inc. 5

 At the end of this course you should be able to:

Overview-6 © 2007 BEA Systems, Inc. 6

 This seminar is targeted to individuals who will be:

Overview-7 © 2007 BEA Systems, Inc. 7

 Please tell us about yourself:

Overview-8 © 2007 BEA Systems, Inc. 8

Overview-9 © 2007 BEA Systems, Inc. 9

12: Introduction to Clustering

A.M. 15: Clustering EJB Objects

Overview-10 © 2007 BEA Systems, Inc. 10

 During the course, you will complete various hands-on

Overview-11 © 2007 BEA Systems, Inc. 11

At the end of this module you will be able to:

Setting Up a WebLogic Server Environment-1 © 2007 BEA Systems, Inc. 15

Setting Up a WebLogic Server Environment-2 © 2007 BEA Systems, Inc. 16

 Java Platform 2 Enterprise Edition (J2EE) helps to

Setting Up a WebLogic Server Environment-5 © 2007 BEA Systems, Inc. 19

WebLogic Server Directory Service

Web Client Web Container

Applet JSPs Session RDBMS

JAAS Message Queue

Setting Up a WebLogic Server Environment-6 © 2007 BEA Systems, Inc. 20

 JMS is a Java API for Producer Producer

Setting Up a WebLogic Server Environment-13 © 2007 BEA Systems, Inc. 27

 The Java Management Extensions (JMX):

Setting Up a WebLogic Server Environment-15 © 2007 BEA Systems, Inc. 29

 Forwards requests to other

Setting Up a WebLogic Server Environment-18 © 2007 BEA Systems, Inc. 32

Setting Up a WebLogic Server Environment-20 © 2007 BEA Systems, Inc. 34

Setting Up a WebLogic Server Environment-21 © 2007 BEA Systems, Inc. 35

Setting Up a WebLogic Server Environment-22 © 2007 BEA Systems, Inc. 36

Firewall Firewall App Server

Setting Up a WebLogic Server Environment-23 © 2007 BEA Systems, Inc. 37

 A domain is a logically «domain»

Setting Up a WebLogic Server Environment-24 © 2007 BEA Systems, Inc. 38

 A domain is an administration feature that:

Setting Up a WebLogic Server Environment-25 © 2007 BEA Systems, Inc. 39

 A server is an instance of «domain»

Setting Up a WebLogic Server Environment-26 © 2007 BEA Systems, Inc. 40

 Is the central point of «domain»

control for a domain «machine»

 Stores the configuration «server»

 Runs the WebLogic

Setting Up a WebLogic Server Environment-27 © 2007 BEA Systems, Inc. 41

 Is any server in a domain «domain»

that is not the admin «machine»

Setting Up a WebLogic Server Environment-28 © 2007 BEA Systems, Inc. 42

 Is a computer that hosts «domain»

 Can host multiple «server»

Setting Up a WebLogic Server Environment-29 © 2007 BEA Systems, Inc. 43

 A cluster is a logical «domain»

group of WLS servers. «machine» «machine»

 WebLogic clusters «server»

– Load balancing «server»

Setting Up a WebLogic Server Environment-30 © 2007 BEA Systems, Inc. 44

In this section we discussed: