Web Logic

Weblogic
Administration Guide
Road Map
Weblogic Server Architecture
Installation & Configuration
Installation Prerequisites
Installation Modes

Weblogic Server Architecture.
Domain
A domain is a logically related group of weblogic server
resources that you manage as a unit.
A domain provides one point administration.
A weblogic server domain can logically separate:
Development, test and production applications.
Organizational divisions

Why use Domain ?
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 seprate :
Development, test and production applications.
Administration and operational responsibilites.
Organizational or business divisions.
Server
A server is an instance of
weblogic.server executing a
JVM.
A server:
Runs on a designated WLS
machine.
Has a dedicated amount of
RAM.
Is multi-threaded.

Administration Server
An administration server
(admin) is the central point of
control of a domain.
An admin server:
Store configuration
information and logs for
domain.
Runs weblogic administration
console.

Managed Server
A managed server is any
server in a domain that is not
admin server.
A managed Server:
Contacts admin server for
configuration information.
Runs business applications in
production environment.
Machine
A machine is a computer that
hosts Weblogic Servers (S).
A Machine :
Runs a supported Operating
system platform.
Can host multiple weblogic
server instances.
Cluster
A Cluster is a logical group of
WLS server.
Weblogic clusters provide
automatic :
Fault tolerance
High Availability
Load balancing
A cluster is transparent to
client.
Installation & Configuration
Weblogic server can be installed in three different ways.
Graphical user interface mode (GUI).
Console Mode
Silent Mode
BEA installer program supports a number of platforms
including :
Windows 2000, 2003, 7, XP
Sun Solaris
Linux
HP-Unix
AIX
Installation Prerequisites
Component Requirement
Platform configuration A supported configuration of
hardware, operating system, JDK, and
database specific to the product you
are installing.
Processor 1-GHz CPU
Hard disk drive A complete installation requires
approximately 3.5 GB of disk space.
Memory A Minimum of 1 GB RAM, although we
recommend 2 GB of RAM.
Color bit depth display and size For Graphical User Interface (GUI)
mode installation, 8-bit color depth
(256 colors) is required.
For console-mode and silent-mode
installation, there is no color bit depth
requirement.
JDK Version 7
Product distribution
.Net installer:- This type downloads a small setup file that enables you
to select the components to install on your system. The installer then
downloads only the components you select. The net installer eliminates
the need to download the entire product before installing it, and
thereby reduces the time needed to complete the download, the disk
space, and also the RAM required for installation
Package installer :- This type of installer downloads a standalone version
of the installation program.
For example, the Oracle WebLogic Server with Workshop for
WebLogic installer contains Oracle WebLogic Server and related samples,
Workshop and related samples, and the JRockit SDK and Sun JDK (for
Windows and Linux platforms only).
Generic installers (net and package):- This type of installer is a .jar file. It
is the same as the package and net installers, except that it does not
include JDKs. You can use this type of installer to install the product on
UNIX machines on which Java is already installed.
Link:-
http://www.oracle.com/technetwork/middleware/weblogic/downloads
/index.html

Installation Modes
Graphical-mode installation is an interactive, GUI-based
method for installing your software. It can be run on both
Windows and UNIX systems
Console-mode installation is an interactive, text-based
method for installing your software from the command line,
on either a UNIX system or a Windows system.
Silent-mode installation is a non-interactive method of
installing your software that requires the use of an XML
properties file for selecting installation options. You can run
silent-mode installation from either a script or from the
command line. Silent-mode installation is a way of setting
installation configurations only once and then using those
configurations to duplicate the installation on many machines.
Starting the Installation
Program on Windows

Graphical mode
Log in to the Windows system.
Go to the directory where you have downloaded the installation
program.
Go to the directory that contains the installation program.
Double-click the installation file.
For example, the name of the installation program for the
Oracle WebLogic Server net installer for Windows is
net_wls1031_win32.exe.
The installation program begins to install the software
.
Program on Windows Contd

Cosole Mode
Log in to the target Windows system.
Open a command prompt window.
Launch the installation by entering the name of the installation
program.
For example, to start the Oracle WebLogic Server net installer for
Windows in console mode, enter
net_wls1031_win32.exe -mode=console

.
Program on Windows Contd

Silent Mode
Log in to the Windows system.
Create a silent.xml file that defines the configuration settings normally
entered by a user during an interactive installation process, such as graphical-
mode or console-mode installation. For information about creating a
silent.xml file, see Section 5.3, "Creating a silent.xml File for Silent-Mode
Installation."
Open a command prompt window.
Start the installer.
For example, to launch the Oracle WebLogic Server installer on Windows,
enter:
wls1031_win32.exe -mode=silent -silent_xml=path_to_silent.xml
Here, path_to_silent.xml is the full path of the silent.xml file.

.
Program on UNIX Contd

Graphical Mode
Log in to the target UNIX system.


Launch the installation by entering the following command:

chmod a+x file_name.bin ./file_name.bin

file_name.bin is the name of your installation program. For example, for Oracle
WebLogic Server 10.3, the name of the net installer file for Solaris is
net_wls1031_solaris32.bin.

The installation program begins to install the software..

.

Console Mode
To start the console-mode installation process with .bin installation
files, follow these steps:
Launch the installation by entering the following command:

chmod a+x file_name.bin ./file_name.bin -mode=console

.

Silent Mode

Create a silent.xml file that defines the configuration settings normally
entered by a user during an interactive installation process, such as
graphical-mode or console-mode installation. For information about
creating a silent.xml file, see Section 5.3, "Creating a silent.xml File for
Silent-Mode Installation."
Launch the installation program by entering the following command:

chmod a+x file_name.bin ./file_name.bin -mode=silent -silent_xml=
path_to_silent.xml
file_name.bin is the name of the installation file.
path_to_silent.xml is the full path of the silent.xml file.
An Installer window is displayed, indicating that the files are being
extracted. No other prompt or text is displayed.

.
Installation Steps
GUI mode
Installation Steps Contd
Installation wizard
Selecting middleware home directory
Registering for security updates
Type of installation
Selecting products and components
Type of JDK to be installed
Product installation directories
Installation summary
Product getting installed
Final result of the installation
Creating Domain

Creating Domain Contd
Configuration wizard to create a domain
D:\oracle\middleware\common
Generating a domain
Setting up domain name and location to create
Configuring administrator username and password
Securing environment and selecting the available JDK
Type of configuration we want to implement.
Providing username and password to admin server
Configuring a managed server
Configuring a managed server
Configuring a node manager
Assigning managed servers to the node managers
Configuration summary of a domain
Creation of domain in -progress
Boot.properties
Many times we want to Alter WebLogic Admin Username and
passwords on a Routine Basis
If you want to Reset The WebLogic Username and Password then
Please follow the Steps mentioned Below
open a Command Prompt and then run setDomainEnv.sh or
setDomainEnv.cmd.
Just for Safety Take a Backup of
(D:\Oracle\Middleware\user_projects\domains\base_domain\security\
*DefaultAuthenticatorInit.ldift*) file because in the Next Command
which we are going to run is going to Create a New File
DefaultAuthenticatorInit.ldift.
In the Command Window Move inside your Domains Security
DirectoryAnd then Run the Following Command:
Example:
D:\Oracle\Middleware\user_projects\domains\base_domain\security>java
weblogic.security.utils.AdminAccount leninbabu lenin1234 .
Syntax: java weblogic.security.utils.AdminAccount <NewAdminUserName>
<NewAdminPassword>

Boot.properties contd..
NOTE:- There is a . (DOT) at the end of the Above command which
represents the Current Directory. Here you can see that after this
command Executes A new DefaultAuthenticatorInit.ldift file will be
created in the Current Directory.
In the Same command prompt Move inside the admin Server folder
inside your domain. And then Just remname the data folder to
something else .like data_OLD this is a way of taking safe backup.
Example:
D:\Oracle\Middleware\user_projects\domains\base_domain\servers\Admin
Server> rename data data_OLD
Now Similarly rename the boot.properties as well to an other File.
Example:
D:\Oracle\Middleware\user_projects\domains\base_domain\servers\A
dminServer\security> rename boot.properties boot.properties_OLD
Add the following lines in boot.properties files
username=<MyAdminUserName>
password=<MyAdminPassword>
Make sure that boot.properties file exists.If yes then Now start The
Admin Server.

Cluster
What Is a WebLogic Server Cluster?
A WebLogic Server cluster consists of multiple WebLogic Server
server instances running simultaneously and working together to
provide increased scalability and reliability.
A cluster appears to clients to be a single WebLogic Server
instance.
The server instances that constitute a cluster can run on the same
machine, or be located on different machines.
You can increase a cluster's capacity by adding additional server
instances to the cluster on an existing machine, or you can add
machines to the cluster to host the incremental server instances.
Each server instance in a cluster must run the same version of
WebLogic Server.
Cluster Contd
How Does a Cluster Relate to a Domain?
A cluster is part of a particular WebLogic Server domain.
A domain is an interrelated set of WebLogic Server resources that are
managed as a unit.
A domain includes one or more WebLogic Server instances, which
can be clustered, non-clustered, or a combination of clustered and
non-clustered instances.
A domain can include multiple clusters.
If a domain contains multiple clusters, each cluster in the domain has
the same Administration Server.
All server instances in a cluster must reside in the same domain; you
cannot "split" a cluster over multiple domains. Similarly, you cannot
share a configured resource or subsystem between domains.
Clustered WebLogic Server instances behave similarly to non-
clustered instances, except that they provide failover and load
balancing.
Cluster Contd
What Are the Benefits of Clustering?
Scalability
The capacity of an application deployed on a WebLogic Server cluster
can be increased dynamically to meet demand. You can add server
instances to a cluster without interruption of servicethe
application continues to run without impact to clients and end users.
High-Availability
In a WebLogic Server cluster, application processing can continue
when a server instance fails.
Cluster Contd
What Are the Key Capabilities of a Cluster?
Application Failover
Simply put, failover means that when an application component
(typically referred to as an "object" in the following sections) doing a
particular "job"some set of processing tasksbecomes unavailable for
any reason, a copy of the failed object finishes the job.
WebLogic Server uses standards-based communication techniques and
facilities including IP sockets and the Java Naming and Directory
Interface (JNDI)to share and maintain information about the
availability of objects in a cluster. These techniques allow WebLogic
Server to determine that an object stopped before finishing its job, and
where there is a copy of the object to complete the job that was
interrupted.
Information about what has been done on a job is called state. WebLogic
Server maintains information about state using techniques called session
replication and replica-aware stubs. When a particular object
unexpectedly stops doing its job, replication techniques enable a copy of
the object pick up where the failed object stopped, and finish the job.

Cluster Contd
What Are the Key Capabilities of a Cluster?
Load Balancing
Load balancing is the even distribution of jobs and associated
communications across the computing and networking resources in
your environment. For load balancing to occur:
There must be multiple copies of an object that can do a particular job.
Information about the location and operational status of all objects must
be available.
WebLogic Server allows objects to be clustereddeployed on multiple
server instancesso that there are alternative objects to do the same job.
WebLogic Server shares and maintains the availability and location of
deployed objects using unicast, IP sockets, and JNDI.
Cluster Contd
What Types of Objects Can Be Clustered?
A clustered application or application component is one that is
available on multiple WebLogic Server instances in a cluster. If an
object is clustered, failover and load balancing for that object is
available.
Deploy objects homogeneouslyto every server instance in your
clusterto simplify cluster administration, maintenance, and
troubleshooting.Load balancing is the even distribution of jobs and
associated communications across the computing and networking
resources in your environment.
Following types of objects can be clustered in a WebLogic Server
deployment
Servlets
JSPs
EJBs
Remote Method Invocation (RMI) objects
Java Messaging Service (JMS) destinations
Java Database Connectivity (JDBC) connections

Load balancing cluster
Round robin:-
WebLogic Server uses the round-robin algorithm as the default load
balancing strategy
for clustered object stubs when no algorithm is specified.
This algorithm is supported for RMI objects and EJBs. It is also the
method used by WebLogic proxy plug-ins.

The round-robin algorithm cycles through a list of WebLogic Server
instances in order.

The advantages of the round-robin algorithm are that it is simple,
cheap and very predictable.
The primary disadvantage is that there is some chance of
convoying.Convoying occurs when one server is significantly slower
than the others. Because replica-aware stubs or proxy plug-ins access
the servers in the same order, a slow server can cause requests to
"synchronize" on the server, then follow other servers in order for
future requests.
Load balancing cluster Contd
Weight-Based Load Balancing
This algorithm applies only to EJB and RMI object clustering.
Weight-based load balancing improves on the round-robin
algorithm by taking into account a pre-assigned weight for each
server.
You can use the Server > Configuration > Cluster page in the
Administration Console to assign each server in the cluster a
numerical weight between 1 and 100, in the Cluster Weight field.
This value determines what proportion of the load the server will
bear relative to other servers.

Random Load Balancing
This algorithm applies only to EJB and RMI object clustering.
In random load balancing, requests are routed to servers at
random. Random load balancing is recommended only for
homogeneous cluster deployments, where each server instance
runs on a similarly configured machine.
A random allocation of requests does not allow for differences in
processing power among the machines upon which server
instances run. If a machine hosting servers in a cluster has
significantly less processing power than other machines in the
cluster, random load balancing will give the less powerful
machine as many requests as it gives more powerful machines.
Disadvantages of random load balancing include the slight
processing overhead incurred by generating a random number for
each request, and the possibility that the load may not be evenly
balanced over a small number of requests.
Server Affinity
Server affinity turns off load balancing for external client
connections; instead, the client considers its existing connections to
WebLogic Server instances when choosing the server instance on
which to access an object. If an object is configured for server affinity,
the client-side stub attempts to choose a server instance to which it
is already connected, and continues to use the same server instance
for method calls.
All stubs on that client attempt to use that server instance. If the
server instance becomes unavailable, the stubs fail over, if possible,
to a server instance to which the client is already connected.
The purpose of server affinity is to minimize the number IP sockets
opened between external Java clients and server instances in a
cluster. WebLogic Server accomplishes this by causing method calls
on objects to "stick" to an existing connection, instead of being load
balanced among the available server instances.

round-robin-affinityserver affinity governs connections
between external Java clients and server instances; round-
robin load balancing is used for connections between server
instances.
weight-based-affinityserver affinity governs connections
between external Java clients and server instances; weight-
based load balancing is used for connections between server
instances.
random-affinityserver affinity governs connections between
external Java clients and server instances; random load
balancing is used for connections between server instances.
Server affinity is supported for all types of RMI objects including JMS
objects, all EJB home interfaces, and stateless EJB remote interfaces.
The server affinity algorithms consider existing connections between
an external Java client and server instances in balancing the client
load among WebLogic Server instances. Server affinity:

Turns off load balancing between external Java clients and server
instances Causes method calls from an external Java client to stick to
a server instance to which the client has an open connection,
assuming that the connection supports the necessary protocol.
In the case of failure, causes the client to failover to a server instance
to which it has an open connection, assuming that the connection
supports the necessary protocol.
Server affinity Examples
Context from a cluster
Client obtains context from the cluster. Lookups on the context and
object calls stick to a single connection. Requests for new initial
context are load balanced on a round-robin basis.
Client requests a new initial context from the cluster
(Provider_ URL=clusteraddress) and obtains the context from
MS1.
Client does a lookup on the context for Object A. The lookup
goes to MS1.
Client issues a call to Object A. The call goes to MS1, to which
the client is already
connected. Additional method calls to Object A stick to MS1.
Client requests a new initial context from the cluster
(Provider_URL=clusteraddress) and obtains the context from
MS2.
Client does a lookup on the context for Object B. The call goes
to MS2, to which the client is already connected. Additional
method calls to Object B stick to MS2.
Server Affinity and Failover
server affinity has on object failover. When a Managed Server
goes down, the client fails over to another Managed Server to
which it has a connection.
Client requests new initial context from MS1.
Client does a lookup on the context for Object A. The lookup
goes to MS1.
Client makes a call to Object A. The call goes to MS1, to which
the client is already
connected. Additional calls to Object A stick to MS1.
The client obtains a stub for Object C, which is pinned to MS3.
The client opens a
connection to MS3.
MS1 fails.
Client makes a call to Object A.The client no longer has a
connection to MS1. Because the client is connected to MS3, it
fails over to a replica of Object A on MS3.
Server affinity and server-to-server connections
server affinity does not affect the connections between server
instances.

A JSP on MS4 obtains a stub for Object B.
The JSP selects a replica on MS1. For each method call, the JSP
cycles through the Managed Servers upon which Object B is
available, on a round-robin basis.
Connection with Load Balancing Hardware
procedure for a client accessing a cluster through a load balancer.

When the client of a Web application requests a servlet using a
public IP address:
The load balancer routes the client's connection request to a
WebLogic Server cluster in accordance with its configured
policies. It directs the request to WebLogic Server A.
WebLogic Server A acts as the primary host of the client's servlet
session state. It uses the ranking system "Using Replication
Groups" to select a server to host the replica of the session state.
In the above, WebLogic Server B is selected to host the replica.
The client is instructed to record the location of WebLogic Server
instances A and B in a local cookie. If the client does not allow
cookies, the record of the primary and secondary servers can be
recorded in the URL returned to the client via URL rewriting.
Failover with Load Balancing Hardware
Should Server A fail during the course of the client's session, the
client's next connection request to Server A also fails
In response to the connection failure:
The load balancing hardware uses its configured policies to direct the
request to an available WebLogic Server in the cluster. In the above
example, assume that the load balancer routes the client's request to
WebLogic Server C after WebLogic Server A fails.

When the client connects to WebLogic Server C, the server uses the
information in the client's cookie (or the information in the HTTP
request if URL rewriting is used) to acquire the session state replica
on WebLogic Server B. The failover process remains completely
transparent to the client.

WebLogic Server C becomes the new host for the client's primary
session state, and WebLogic Server B continues to host the session
state replica. This new information about the primary and secondary
host is again updated in the client's cookie, or via URL rewriting.
Server Migration
Migration in WebLogic Server is the process of moving a clustered
WebLogic Server instance or a component running on a clustered
instance elsewhere in the event of failure.
In the case of whole server migration, the server instance is migrated to
a different physical machine upon failure. In the case of service-level
migration, the services are moved to a different server instance within
the cluster.
WebLogic Server provides feature for making JMS and the JTA
transaction system highly available: migratable servers. Migratable
servers provide for both automatic and manual migration at the server-
level, rather than the service level.
When a migratable server becomes unavailable for any reason, for
example, if it hangs,loses network connectivity, or its host machine
failsmigration is automatic. Upon failure, a migratable server is
automatically restarted on the same machine if possible.
If the migratable server cannot be restarted on the machine where it
failed, it is migrated to another machine. In addition, an administrator
can manually initiate migration of a server instance.
Server Migration Contd
Migratable server A clustered server instance that migrates in its
entirety, along with all the services it hosts. Migratable servers are
intended to host pinned services, such as JMS servers and the JTA
transaction recovery servers, but they can also host clusterable
services. All services that run on a migratable server are highly
available.
Whole server migration A WebLogic Server instance to be
migrated to a different physical machine upon failure, either
manually or automatically.
Service migration:
Manual Service MigrationThe manual migration of pinned JTA and
JMS-related services (for example, JMS server, SAF agent, path
service, and custom store) after the host server instance fails.
Automatic Service MigrationJMS-related services, singleton
services, and the JTA Transaction Recovery Service can be configured
to automatically migrate to another member server when a member
server fails or is restarted.

Cluster leaderOne server instance in a cluster, elected by a
majority of the servers, that is responsible for maintaining the
leasing information.
Cluster master One server instance in a cluster that contains
migratable servers acts as the cluster master and orchestrates the
process of automatic server migration, in the event of failure. Any
Managed Server in a cluster can serve as the cluster master,
whether it hosts pinned services or not.
Singleton masterA lightweight singleton service that monitors
other services that can be migrated automatically. The server that
currently hosts the singleton master is responsible for starting and
stopping the migration tasks associated with each migratable
service.
Candidate machinesa user-defined list of machines within a
cluster that can be a potential target for migration.
Target machinesa set of machines that are designated as
allowable or preferred hosts for migratable servers.
Lease tablea database table in which migratable servers
persist their state, and which the cluster master monitors to
verify the health and liveness of migratable servers.
Administration Serverused to configure migratable servers
and target machines, to obtain the run-time state of
migratable servers, and to orchestrate the manual migration
process.
Floating IP addressan IP address that follows a server from
one physical machine to another after migration.
Leasing
Leasing is the process WebLogic Server uses to manage services
that are required to run on only one member of a cluster at a
time. Leasing ensures exclusive ownership of a cluster-wide
entity. Within a cluster, there is a single owner of a lease.
Additionally,
leases can failover in case of server or cluster failure. This helps to
avoid having a single point of failure.
Features That Use Leasing
Automatic Whole Server MigrationUses leasing to elect a cluster
master. The cluster master is responsible for monitoring other cluster
members. It is also responsible for restarting failed members hosted on
other physical machines. Leasing ensures that the cluster master is
always running, but is only running on one server at a time within a
cluster.
Automatic Service MigrationJMS-related services, singleton
services, and the JTA Transaction Recovery Service can be
configured to automatically migrate from an unhealthy hosting
server to a healthy active server with the help of the health
monitoring subsystem. When the migratable target is migrated,
the pinned service hosted by that target is also migrated.
Migratable targets use leasing to accomplish automatic service
migration.
Singleton Services A singleton service is, by definition, a service
running within a cluster that is available on only one member of
the cluster at a time. Singleton services use leasing to accomplish
this.
Leasing Versions
WebLogic Server provides two types of leasing functionality. Which
one you use depends on your requirements and your environment.
High-availability database leasingThis version of leasing requires a
high-availability database to store leasing information.
Non-database consensus leasingThis version of leasing stores the
leasing information in-memory within a cluster member. This version
of leasing requires that all servers in the cluster are started by Node
Manager.

Within a WebLogic Server installation, you can use only one type of
leasing. Although it is possible to implement multiple features that
use leasing within your environment, each must use the same kind of
leasing.
When switching from one leasing type to another, you must restart
the entire cluster, not just the Administration Server. Changing the
leasing type cannot be done dynamically.

Leasing Versions
WebLogic Server provides two types of leasing functionality. Which
one you use depends on your requirements and your environment.
High-availability database leasingThis version of leasing requires a
high-availability database to store leasing information.
Non-database consensus leasingThis version of leasing stores the
leasing information in-memory within a cluster member. This version
of leasing requires that all servers in the cluster are started by Node
Manager.

Within a WebLogic Server installation, you can use only one type of
leasing. Although it is possible to implement multiple features that
use leasing within your environment, each must use the same kind of
leasing.
When switching from one leasing type to another, you must restart
the entire cluster, not just the Administration Server. Changing the
leasing type cannot be done dynamically.

Determining Which Type of Leasing To Use ?
High-availability database leasing
Database leasing basis is useful in environments that are already invested
in a high-availability database, like Oracle RAC, for features like JMS store
recovery. The high-availability database instance can also be configured
to support leasing with minimal additional configuration. This is
particularly useful if Node Manager is not running in the system.
Non-database consensus leasing
This type of leasing provides a leasing basis option (consensus) that does
not require the use of a high-availability database. This has a direct
benefit in automatic whole server migration. Without the high-
availability database requirement, consensus leasing requires less
configuration to enable automatic server migration.
Consensus leasing basis requires Node Manager to be configured and
running. Automatic whole server migration also requires the Node
Manager for IP migration and server restart on another machine. Hence,
consensus leasing works well since it does not impose additional
requirements, but instead takes away an expensive one.
High-availability Database Leasing
In this version of leasing, lease information is maintained within a
table in a high-availability database.
A high-availability database is required to ensure that the leasing
information is always available to the servers.
Each member of the cluster must be able to connect to the
database in order to access leasing information, update and
renew their leases.
Servers will fail if the database becomes unavailable and they are
not able to renew their leases.

The following procedures outline the steps required to configure
your database for leasing.
Configure the database for server migration. The database stores
leasing information that is used to determine whether or not a
server is running or needs to be migrated. Your database must be
reliable. The server instances will only be as reliable as the
database.
Create the leasing table in the database. This is used to store the
machine-server associations used to enable server migration. The
schema for this table is located in
WL_HOME/server/db/dbname/leasing.ddl, where dbname is the name
of the database vendor.
Set up and configure a data source. This data source should point
to the database configured in the previous step.
Non-database Consensus Leasing
In Consensus leasing, there is no highly available database required. The cluster
leader
maintains the leases in-memory. All the servers renew their leases by contacting
the cluster leader, however, the leasing table is replicated to other nodes of the
cluster to provide failover.
The cluster leader is elected by all the running servers in the cluster. A server
becomes a cluster leader only when it has received acceptance from the majority
of the servers. If the Node Manager reports a server as shutdown, the cluster
leader assumes that server to have accepted it as leader when counting the
majority.
Consensus leasing requires a majority of servers to continue functioning. Any time
there is a network partition, the servers in the majority partition will continue to
run while those in the minority partition will fail since they cannot contact the
cluster leader or elect a new cluster leader since they will not have the majority of
servers. If the partition results in an equal division of servers, then the partition
that contains the cluster leader will survive while the other one will fail.
If automatic server migration is enabled, the servers are required to contact the
cluster leader and renew their leases periodically. Servers will shut themselves
down if they are unable to renew their leases. The failed servers will then be
automatically migrated to the machines in the majority partition.
Server Migration Processes and Communications
Key processes in a cluster that contains migratable servers
Startup Process in a Cluster with Migratable Servers
Automatic Whole Server Migration Process
Manual Whole Server Migration Process

Startup Process in a Cluster with Migratable Servers
The below example illustrates the processing and communications that occur
during startup of a cluster that contains migratable servers.

The example cluster contains two Managed Servers, both of which are
migratable. The Administration Server and the two Managed Servers each
run on different machines. A fourth machine is available as a backupin the
event that one of the migratable servers fails. Node Manager is running on
the backup machine and on each machine with a running migratable server.

The administrator starts up the cluster.
The Administration Server invokes Node Manager on Machines B and C
to start Managed Servers 1 and 2, respectively.
The Node Manager on each machine starts up the Managed Server that
runs there.
Managed Servers 1 and 2 contact the Administration Server for their
configuration.
Managed Servers 1 and 2 cache the configuration with which they
started up.
Managed Servers 1 and 2 each obtain a migratable server lease in the
lease table. Because Managed Server 1 starts up first, it also obtains a
cluster master lease.
Managed Server 1 and 2 periodically renew their leases in the lease
table, proving their health and liveness.
Automatic Whole Server Migration Process

Machine C, which hosts Managed Server 2, fails.
Upon its next periodic review of the lease table, the cluster master
detects that Managed Server 2's lease has expired.
The cluster master tries to contact Node Manager on Machine C to
restart Managed Server 2, but fails, because Machine C is
unreachable.
Note: If the Managed Server 2 lease had expired because it was
hung, and Machine C was reachable, the cluster master would use
Node Manager to restart Managed Server 2 on Machine C.
The cluster master contacts Node Manager on Machine D, which is
configured as an available host for migratable servers in the cluster.
Node Manager on Machine D starts Managed Server 2.
Managed Server 2 starts up and contacts the Administration Server
to obtain its configuration.
Managed Server 2 caches the configuration with which it started up.
Managed Server 2 obtains a migratable server lease.
Manual Whole Server Migration Process

An administrator uses the Administration Console to initiate the
migration of Managed Server 2 from Machine C to Machine B.
The Administration Server contacts Node Manager on Machine C.
Node Manager on Machine C stops Managed Server 2.
Managed Server 2 removes its row from the lease table.
The Administration Server invokes Node Manager on Machine B.
Node Manager on Machine B starts Managed Server 2.
Managed Server 2 obtains its configuration from the Administration
Server.
Managed Server 2 caches the configuration with which it started up.
Managed Server 2 adds a row to the lease table.

JDBC

Java Message Service - JMS
What Is Messaging?
Messaging is a method of communication between software components or
applications. A messaging system is a peer-to-peer facility: A messaging client
can send messages to, and receive messages from, any other client. Each
client connects to a messaging agent that provides facilities for creating,
sending, receiving, and reading messages.
Messaging enables distributed communication that is loosely coupled. A
component sends a message to a destination, and the recipient can retrieve
the message from the destination. However, the sender and the receiver do
not have to be available at the same time in order to communicate. In fact,
the sender does not need to know anything about the receiver; nor does the
receiver need to know anything about the sender. The sender and the
receiver need to know only what message format and what destination to
use. In this respect, messaging differs from tightly coupled technologies, such
as Remote Method Invocation (RMI), which require an application to know a
remote application's methods.
Messaging also differs from electronic mail (e-mail), which is a method of
communication between people or between software applications and
people. Messaging is used for communication between software applications
or software components.
Java Message Service JMS
Contd
What Is the Java Message Service ?
An enterprise messaging system enables applications to
asynchronously communicate with one another through the
exchange of messages.
A message is a request, report, and/or event that contains
information needed to coordinate communication between different
applications. A message provides a level of abstraction, allowing you
to separate the details about the destination system from the
application code.
The Java Message Service (JMS) is a standard API for accessing
enterprise messaging systems that is implemented by industry
messaging providers. Specifically, JMS:
Enables Java applications that share a messaging system to exchange
messages
Simplifies application development by providing a standard interface for
creating, sending, and receiving messages
Contd
When Can You Use the JMS API?
An enterprise application provider is likely to choose a messaging
API over a tightly coupled API, such as Remote Procedure Call
(RPC), under the following circumstances.
The provider wants the components not to depend on
information about other components' interfaces, so that
components can be easily replaced.
The provider wants the application to run whether or not all
components are up and running simultaneously.
The application business model allows a component to send
information to another and to continue to operate without
receiving an immediate response.
Contd
For example, components of an enterprise application for an
automobile manufacturer can use the JMS API in situations like
these.
The inventory component can send a message to the factory
component when the inventory level for a product goes below a
certain level, so the factory can make more cars.
The factory component can send a message to the parts components
so that the factory can assemble the parts it needs.
The parts components in turn can send messages to their own
inventory and order components to update their inventories and to
order new parts from suppliers.
Both the factory and the parts components can send messages to
the accounting component to update their budget numbers.
The business can publish updated catalog items to its sales force.
Contd

Messaging in an Enterprise Application
Contd
JMS Architecture : Connecting
Contd
A JMS application is composed of the following parts. :-
A JMS provider is a messaging system that implements the JMS
interfaces and provides administrative and control features.
JMS clients are the programs or components, written in the Java
programming language, that produce and consume messages.
Messages are the objects that communicate information
between JMS clients.
Administered objects are preconfigured JMS objects created by
an administrator for the use of clients.
Native clients are programs that use a messaging product's
native client API instead of the JMS API. An application first
created before the JMS API became available and subsequently
modified is likely to include both JMS and native clients.
Contd
Below figure illustrates the way these parts interact
Administrative tools allow you to bind destinations and
connection factories into a Java Naming and Directory
InterfaceTM (JNDI) API namespace.
A JMS client can then look up the administered objects in the
namespace and then establish a logical connection to the same
objects through the JMS provider.

Contd
Messaging Domains
Before the JMS API existed, most messaging products supported
either the point-to-point or the publish/subscribe approach to
messaging.
Point-to-Point Messaging Domain
The queue or point-to-point model works by having a sender place
messages to a queue, and the receiver will be able to read the messages
from the queue.
In queue, the sender knows where the message will be going. There is a
specific sender and a specific receiver, and there is the intention of being
acknowledged as such.
In queue, you only have one receiver or consumer.
In queue you do not have to worry about timing because the sender will
have the luxury to send messages whenever he or she wants to. And the
same goes for the receiver; he or she also has the liberty of reading it
whenever he or she wants.
In queue you will also be assured that as the sender you have
successfully sent out your message because you will be notified by the
receiver,
Contd
Point-to-Point Messaging Domain
Contd
Publisher or subscriber Model
Publisher or subscriber model is also simply known as the topic
model.
Publisher or subscriber or the topic model works by disseminating
messages by posting messages about a particular topic and having
subscribers read them.
In topic you only have a publisher and a subscriber or subscribers.
In topic where in you can have your message be disseminated to a
number of subscribers. Also, in topic, the publisher has to be
continuously active for a subscriber to receive the messages.
Otherwise the message will be reallocated.
In topic there is no guarantee that the message will reach
successfully to the user.
Contd
Publisher or subscriber Model

Contd
Weblogic JMS Architecture and Environment
Contd
The major components of the WebLogic JMS architecture
include:
A JMS server is an environment-related configuration entity that
acts as management container for JMS queue and topic resources
defined within JMS modules that are targeted to specific that JMS
server. A JMS server's primary responsibility for its targeted
destinations is to maintain information on what persistent store is
used for any persistent messages that arrive on the destinations,
and to maintain the states of durable subscribers created on the
destinations. You can configure one or more JMS servers per
domain, and a JMS server can manage one or more JMS modules.
JMS modules contain configuration resources, such as standalone
queue and topic destinations, distributed destinations, and
connection factories, and are defined by XML documents that
conform to the weblogic-jms.xsd schema.
Contd
Client JMS applications that either produce messages to
destinations or consume messages from destinations.
JNDI (Java Naming and Directory Interface), which provides a
server lookup facility.
WebLogic persistent storage (a server instance's default store, a
user-defined file store, or a user-defined JDBC-accessible store)
for storing persistent message data.
Contd
Configuration
Configuration information can be further classified into environment-
related information and application-related information.
Environment-related information are the identification and definition
of JMS servers, JDBC data sources, WebLogic persistent stores, and
server network addresses. These system resources are usually unique
from domain to domain.
The configuration and management of these system resources are
the responsibility of a administrator, who usually receives this
information from an organization's system administrator or MIS
department.
To accomplish these tasks, an administrator can use the
Administration Console, various command-line tools, such as
Scripting Tool (WLST), or JMX APIs for programmatic administration.
Contd
Application-related definitions that are independent of the
domain environment are the various Java EE application
components configurations, such as EAR, WAR, JAR, RAR files, and
JMS and JDBC modules.
The application components are originally developed and
packaged by an application development team, and may contain
optional programs (compiled Java code) and respective
configuration information (also called descriptors, which are
mostly stored as XML files). In the case of JMS and JDBC modules,
however, there are no compiled Java programs involved.
These pre-packaged applications are given to Server
administrators for deployment.
Contd
Resources in a JMS System Module
Connection Factory:- Connection factories are resources that enable JMS
clients to create JMS connections. A connection factory supports
concurrent use, enabling multiple threads to access the object
simultaneously.
Queue:- Defines a point-to-point destination type, which are used for
asynchronous peer communications. A message delivered to a queue is
distributed to only one consumer.
Topic:- Defines a publish/subscribe destination type, which are used for
asynchronous peer communications. A message delivered to a topic is
distributed to all topic consumers.
Distributed Queue:- Defines a set of queues that are distributed on
multiple JMS servers, but which are accessible as a single, logical queue
to JMS clients.
Distributed queues can help with message load balancing and distribution,
and have many of the same properties as standalone queues.

Contd
Distributed Topic:- Defines a set of topics that are distributed on multiple
JMS servers, but which are accessible as a single, logical topic to JMS
clients.
Distributed topics can help with load balancing and distribution, and
have many of the same properties as standalone topics.
Foreign Server Configuration :A foreign server resource enables you to
reference third-party JMS providers within a local WebLogic Server JNDI
tree. With a foreign server resource, you can quickly map a foreign JMS
provider so that its associated connection factories and destinations
appear in the WebLogic JNDI tree as local JMS objects.
Quota Configuration :- A quota resource defines a maximum number of
messages and bytes, and is then associated with one or more
destinations and is responsible for enforcing the defined maximums.

Contd
JMS Store-and-Forward (SAF) Configuration :- JMS SAF resources build on
the WebLogic Store-and-Forward (SAF) service to provide highly-
available JMS message production. For example, a JMS message
producer connected to a local server instance can reliably forward
messages to a remote JMS destination, even though that remote
destination may be temporarily unavailable when the message was sent.
JMS Store-and-forward is transparent to JMS applications; therefore,
JMS client code still uses the existing JMS APIs to access remote
destinations.
WEBLOGIC SERVER SECURITY
Oracle
Security Realms in WebLogic
Server
The security service in WebLogic Server simplifies the
configuration and management of security while offering
robust capabilities for securing your WebLogic Server
deployment. Security realms act as a scoping mechanism.
Each security realm consists of a set of configured security
providers, users, groups, security roles, and security policies.
You can configure multiple security realms in a domain;
however, only one can be the active security realm. WebLogic
Server provides two default security realms:
myrealmHas the WebLogic Adjudication, Authentication,
Identity Assertion, Authorization, Role Mapping, and Credential
Mapping providers configured by default.
CompatibilityRealmProvides backward compatibility for 6.x
security configurations. You can access an existing 6.x security
configuration through the CompatibilityRealm.
Security Providers
Security providers are modular components that handle
specific aspects of security, such as authentication and
authorization. Although applications can leverage the services
offered by the default WebLogic security providers, the
WebLogic Security Service's flexible infrastructure also allows
security vendors to write their own custom security providers
for use with WebLogic Server.
The WebLogic Administration Console allows you to
administer and manage all your security providers through
one unified management interface.
The WebLogic Security Service supports the following types of
security providers:
Security Providers contd..
AuthenticationAuthentication is the process whereby the
identity of users or system processes are proved or verified.
Authentication also involves remembering, ransporting, and
making identity information available to various components
of a system when that information is needed. Authentication
providers supported by the WebLogic Security Service supply
the following types of authentication:
Username and password authentication
Certificate-based authentication directly with WebLogic Server
HTTP certificate-based authentication proxied through an
external Web server

Security Providers contd..
AuthorizationAuthorization is the process whereby the
interactions between users and WebLogic resources are limited
to ensure integrity, confidentiality, and availability. In other
words, once a user's identity has been established by an
authentication provider, authorization is responsible for
determining whether access to WebLogic resources should be
permitted for that user. An Authorization provider supplies these
services.

LDAP Authentication Providers - stores user and group
information in an external LDAP server. WebLogic Server provides
LDAP Authentication providers that access Oracle Internet
Directory, Oracle Virtual Directory, Open LDAP, Netscape iPlanet,
Microsoft Active Directory and Novell NDS stores

Resources that can be secured
A WebLogic resource represents an underlying WebLogic
Server entity that can be protected from unauthorized access
using security policies. Examples of WebLogic resources
include Administrative resources, Server resources, Enterprise
Applications (EARs), EJBs (JARs), and Web Applications
(WARs).
The main steps for securing a WebLogic resource are:
Determine which WebLogic resource to secure.
If you want to secure an EJB or Web application resource:
Understand the options you have for securing these resources.
Decide which technique you want to use. You can use Deployment
Descriptors only, the Administration Console only, or a combination
of the two.
Decide which security deployment model to use. This depends on
the security technique you choose.
contd..

contd..
Use the WebLogic Administration Console to secure your
WebLogic resource:
Create users and groups, representations of individuals and
collections of individuals, who may be granted a security role.
Create security roles, which are dynamically computed privileges
granted to users or groups based (optionally) on specific
conditions. You can create global roles, which apply to all
resources, or scoped roles which apply to selected resources.
BEA recommends creating security roles and using them (rather
than users or groups) to secure WebLogic resources, because
doing so increases efficiency for administrators who work with
many users.
Create security policies, which are associations between the
WebLogic server and a user, group, or security role, that specify
who has access to the WebLogic Resource and under what
conditions.
Weblogic security diagram

Security Relam
Before You Create a New Security Realm
Before creating a new security realm, you need to decide:
Which security providers you want to use. WebLogic Server includes
a wide variety of security providers and, in addition, allows you to
create or obtain custom security providers. A valid security realm
requires an Authentication provider, an Authorization provider, an
Adjudication provider, a Credential Mapping provider, a Role
Mapping provider, and a CertPathBuilder. In addition, a security
realm can optionally include Identity Assertion, Auditing, and
Certificate Registry providers.
What model to use to set security roles and security policies for Web
application and EJB resources. These security roles and policies can
be set through deployment descriptors or through the WebLogic
Administration Console.

Security Relam contd..
Creating and Configuring a New Security Realm

Define a name and set the configuration options for the security
realm.
Configure the required security providers for the security realm. A
valid security realm requires an Authentication provider, an
Authorization provider, an Adjudication provider, a Credential
Mapping provider, a Role Mapping provider, and a
CertPathBuilder.
Optionally, define Identity Assertion, Auditing, and Certificate
Registry providers.
If you configured the Default Authentication, Authorization,
Credential Mapping or Role Mapping provider or the Certificate
Registry in the new security realm, verify that the settings of the
embedded LDAP server are appropriate.
Security Relam contd..
Optionally, configure caches to improve the performance of the
WebLogic or LDAP Authentication providers in the security realm.
Protect WebLogic resources in the new security realm with
security policies.
If the security data (users and groups, roles and policies, and
credential maps) defined in the existing security realm will also
be valid in the new security realm, you can export the security
data from the existing realm and import it into the new security
realm.
Protect user accounts in the new security realm from dictionary
attacks by setting lockout attributes.
Diagnostics Framework
WLDF Architecture
The WebLogic Diagnostics Framework (WLDF) consists of a
number of components that work together to collect, archive,
and access diagnostic information about a WebLogic Server
instance and the applications it hosts. This section provides an
architectural overview of those components.
Overview of the WebLogic
WLDF consists of the following:
Data creators (data publishers and data providers that are
distributed across WLDF components)
Data collectors (the Logger and the Harvester components)
Archive component
Accessor component
Instrumentation component
Watch and Notification component
Image Capture component
Monitoring Dashboard
Diagnostics Framework Contd
Data creators generate diagnostic data that is consumed by
the Logger and the Harvester.
Those components coordinate with the Archive to persist the
data, and they coordinate with the Watch and Notification
subsystem to provide automated monitoring.
The Accessor interacts with the Logger and the Harvester to
expose current diagnostic data and with the Archive to
present historical data.
Diagnostics Framework Contd
Major WLDF Component

Relationship of Data Creation Components to
Data Collection Components

Invocations of the server logging infrastructure serve as inline data
publishers, and the generated data is collected as events. (The
logging infrastructure can be invoked through the catalog
infrastructure, the debugging model, or directly through the Logger.)
Relationship of Data Creation Components to
Data Collection Components Contd
The Instrumentation system creates monitors and inserts
them at well-defined points in the flow of execution. These
monitors publish data directly to the Archive.
Components registered with the MBean Server may also make
themselves known as data providers by registering with the
Harvester. Collected data is then exposed to both the Watch
and Notification system for automated monitoring and to the
Archive for persistence.

Archive
The past state is often critical in diagnosing faults in a system.
This requires that the state be captured and archived for
future access, creating a historical archive. In WLDF, the
Archive meets this need with several persistence components.
Both events and harvested metrics can be persisted and made
available for historical review.
Relationship of the Archive to the Logger and the Harvester

Watch and Notification
The Watch and Notification system can be used to create
automated monitors that observe specific diagnostic states
and send notifications based on configured rules.
A watch rule can monitor log data, event data from the
Instrumentation component, or metric data from a data
provider that is harvested by the Harvester.
The Watch Manager is capable of managing watches that are
composed of a number of watch rules.
Data Accessor
The Accessor provides access to all the data collected by
WLDF, including log, event, and metric data. The Accessor
interacts with the Archive to get historical data including
logged event data and persisted metrics.

Monitoring Dashboard and Request
Performance Pages
Monitoring Dashboard
The Monitoring Dashboard displays the current and historical
operating state of WebLogic Server and hosted applications by
providing visualizations of metric
runtime MBean attributes, which surface some of the more
critical run-time performance metrics and the change in those
metrics over time.
Diagnostics Request Performance Page
The Diagnostics Request Performance page of the WebLogic
Server Administration Console shows real-time and historical
views of method performance information that is captured
through the WLDF instrumentation capabilities.
To view request performance information, you must first
configure WLDF instrumentation to make that data available.

Diagnostic Image Capture
Diagnostic Image Capture support gathers the most common
sources of the key server state used in diagnosing problems
Image Capture support includes:
On-demand capture, which is the creation of a diagnostic image
capture by means of an operation or command issued from the
WebLogic Server Administration Console, WLST script, or JMX
application.
Image notification, which is automatically creating a diagnostic
image capture in response to the triggering of an associated
Harvester watch, Log watch, or Instrumentation watch rule.
For example, a Harvester watch that monitors runtime MBean
attributes in a running server can trigger an image notification if the
metrics harvested from specific runtime MBean instances indicate a
performance issue. Data in the diagnostic image capture can be
analyzed to determine the likely causes of the issue.
Diagnostic Image Capture Contd..
Diagnostic Image Capture
Overall View of the WebLogic
Below figure shows how all the parts of WLDF fit together

Web Logic

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Web Logic

Hochgeladen von

Copyright:

Verfügbare Formate

Weblogic

Das könnte Ihnen auch gefallen