Sample copy. Introduction To WebLogic Server Property of Web 10.3 Age Solutions Inc.

Introduction To WebLogic Server

10.3

Sample copy

Objectives

„

At the end of this chapter, participants should

be able to:

„

Understand basic WebLogic Server architecture

„

Understand the difference between administrative

servers and managed servers

„

Create a domain using the configuration wizard

Use the Administration Console

„

Start and stop WebLogic Server instances

Sample copy

WebLogic Server Instances

„

Each WebLogic Server runs as an individual process

„

Also known as an "instance"

„

Each running instance of WebLogic Server is a full

fledged JEE application server

„

A running server instance of WebLogic will have a running

web container, EJB container, JMS server, etc.

„

Can service requests

„

An Application Server's main task is to host and

server JEE applications!

„

To "start WebLogic" implies starting one or more

WebLogic Server instances

Sample copy

The Java Virtual Machine

„ This JVM is the "java sandbox" that contains running java code

„ The JVM is the byte code interpreter that reads and executes all java classes

„ For every Java program that is executed, the OS will start a JVM process to execute that code

„ Running a java program and then looking at your OS process list will show a

process called java.exe (on Windows) or just java (on Unix)

„ An instance of WebLogic Server is a java program itself

„ Starting one instance of WebLogic Server will start an instance of the JVM „ Multiple instances running would imply there are multiple JVMs running as well

„ The JVM is a part of the Sun specification of how the Java

programming language works

„ The JVM is usually included as a part of a JDK (Java Development Kit) download

„ Also can be installed in the form of a JRE (Java Runtime Environment)

Sample copy

JVM Providers

„

Sun Microsystems is the "creator" of Java

„ controls the language "spec" (i.e. how the language works) „ Maintains versions of the JDK (and hence, JVM)

„

Sun will always have an implementation of the latest JVM

version available for download and use

„

Most Java run time environments will use the JVM provided by

Sun, but other vendors also produce a JVM

„

WebLogic Server 10 comes packaged with 2 JVMs, allowing the

administrator to decide which version to use

„ Sun JDK v1.6.0_05 (The 'official' Sun implementation)

„ The established standard

„ JRockit9 v1.6.0_05 (Created by 3rd party)

„ The JRockit JVM has been fine-tuned and optimized for server-side java

applications

„ Regardless of the choice of JVM, all applications should work in either environment ... but one may run faster than the other.

Sample copy

Threads vs. Processes

„

WebLogic Server itself is running several

services (e.g. web container, EJB container)

„

Each one of these services runs as a separate

thread

inside the parent JVM

process

„

WebLogic Server is multi-threaded to allow for

high-performance and concurrency

„

While it may look like hundreds of requests are

being serviced by one WebLogic instance at any

given moment, only one

process

should be

running

„

Only one java.exe

Sample copy

WebLogic Server Domains

„

A WebLogic Server instance must belong to a

domain

„

A domain is a logical collection of one or more server

instances, sharing a common configuration

„

When a WebLogic Server instance is created, it is either

added to an existing domain, or a new domain is created for

it, using the provided

configuration wizard

tool

„

Every domain has a unique name

„

Each domain has its own

domain directory

on the file

system. This directory will contain all the configuration

information for the server(s) in that domain

Sample copy

Servers And Domains

„ A domain contains one or more WebLogic Server instances „ Every domain has exactly one administration server

„ Optionally, has 1 or more managed servers

„ Both Administration Server and Managed Servers are fully J2EE capable

application servers, but an Administration Server is also capable of performing administrative duties for a domain

„ At its simplest, a WebLogic Server domain will have just one admin

server which is responsible for both administering the domain as well as serving all applications

„ A more typical domain architecture would have a single admin server

and multiple managed servers

„ In this case, the admin server would be responsible just for admin duties

„ The managed servers would perform all the application serving „ Can be connected in a cluster

„ Clustering will be discussed in great detail in a later chapter

„ In a domain, servers do not all have to be run on the same physical

machine.

Sample copy

Domain Configuration

„

A domain's complete configuration will be stored in

the domain directory

„

e.g. server definitions, web container settings, security

settings, etc

„

This is also known as the

configuration repository

„

Making any administrative changes to the domain

configuration setup implies altering files inside the

configuration repository

„ e.g. config.xml

„ Config.xml contains the majority of domain configuration data „ Note that the makeup has changed since WLS 8.x. Will be

discussed later in the chapter.

Sample copy

WebLogic Administration

Domain

Server 1 Server 2 Server 3

Set/Get Get Configuration On start up Monitor

Domain

Sample copy

Directory Structures

„

Three major directory structures in a BEA-installed

environment:

<bea_home>, <wl_home> and <domain_dir>

„

Typically <bea_home> is /bea, it is the "top level"

folder for all BEA products

„ Important sub-dirs:

„ wlserver_10.3

„ Contains all the binaries and libraries needed for WebLogic Server that are

used by all server instances and domains

„ Often referred to as

<wl_home>

„ JVM folders (for both JRockit and Sun)

„ This variable is referred to in many WebLogic scripts.

„

One <bea_home> can contain multiple versions of WebLogic

Server

„ v10 can co-exist with v9 and v8, as each will have a separate <wl_home> folder

Sample copy

Directory Structures

„

<domain_dir>

„ One per created domain. Contains configuration repository per domain. Typically under

<bea_home>/user_projects/domains „ Important sub-dirs:

„ servers

„ Contains specific server data for each server in the domain (e.g. log files,

deployment directories, etc)

„ config

„ Contains domain wide configuration data

„ autodeploy

„ In development used for auto-deployment of applications. (will be

discussed later)

„ bin

„ Contains launch scripts

Sample copy

Getting Started Roadmap

„ Basic steps to getting a WebLogic Server up and running:

ƒ 1. Install the software

ƒ Installs all the binaries and libraries that are needed by WebLogic Server

ƒ Use the BEA installer

ƒ Done once per machine

ƒ Set <bea_home>

ƒ 2. Create a domain, and define an administration server for this domain

ƒ Use the configuration wizard

ƒ If creating a second domain, no need to re-install the software; just use the configuration wizard to create another domain

ƒ Specify an administrator username/password

ƒ 3. Start the administration server in the newly created domain

ƒ Use the startWebLogic.cmd script

ƒ 4. Administer the new domain by using the administration server' Admin Console

ƒ Open a browser to http://<adminserverhostname>:port/console

ƒ From the admin console:

ƒ 5. Create managed servers if necessary

ƒ 6. Configure resources

ƒ 7. Deploy applications.

Sample copy

Install WebLogic Server

„

This step copies the WebLogic Server binaries and

libraries onto the machine

„

Use the BEA installer, either off CD or via downloaded

package

„

Choose optional components to install

„

Complete install implies installation of both the server

software as well as the Workshop for WebLogic

Platform development environment

„

Accept the license agreement

„

Specify BEA home and product directory

„

Recommended: leave defaults

Sample copy

The Configuration Wizard

ƒ The configuration wizard is a tool that is used to create new WebLogic

Server domains

ƒ Java-based GUI tool

ƒ Launch: <wl_home>\common\bin\config.cmd for Windows

(config.sh for Unix)

ƒ A domain must be created before any servers can be created! ƒ The configuration wizard can:

ƒ Create new domains

ƒ Define simple domains (e.g. just a single admin server) or complex domains

(multiple servers, clusters, etc)

ƒ Define resources in this new domain

ƒ (Can also be done from the admin console post domain creation)

ƒ Extend existing domains

ƒ Define resources in an existing domain

ƒ (Can also be done from the admin console)

ƒ Upon completion, a domain directory should be created, typically found

in <bea_home>/user_projects/domains/<domain_name>

Sample copy

The Configuration Wizard:

Creating A New Domain

„ Important steps:

„ Select Create a new WebLogic Domain

„ Specify domain type (e.g. new, or based on a template) „ Specify an administrator username and password

„ Do not lose this information!

„ Specify which JVM to use, and start mode

„ Start mode can be either production or development. This

will be discussed later.

„ Avoid customizing domain now; do it later from the admin console

„ Specify a domain name, as well as domain location

„ Best to leave default for location

„ The domain will be created at this point.

Sample copy

Starting The Administrative

Server

„ Starting a domain implies starting the administrative server for that

domain

„ The creation wizard, by default, defines an administrative server (called

AdminServer), listening at port 7001

„ This name and port number can be overridden at domain creation time „ To start the admin server, run the startWebLogic.cmd (or

startWebLogic.sh for Unix) script in the newly created domain directory

„ Recall: domain directory is created at:

<bea_home>/user_projects/domains/<domain_name>

„ Executing this script will start the administration server for the domain „ Recall: this launches a JVM which is the java process for this server instance „ This start script, as well as others can also be found in the bin/ subfolder

of <domain_dir>

„ Once the server is started, the Administration Console can be opened!

Sample copy

The Administration Console

„

The Admin Console will be the

primary means of configuring

and administering WebLogic

„ Browser based, accessible from any client

„ Allows remote administration „ Functionally equivalent to the

admin console in previous versions of WebLogic Server „ Identical to the Admin Console

from WebLogic v9.x

„ "Portal based" instead of 8.x

applet based

„ http://adminserver:port/console „ Login with username/password

specified during domain creation

Sample copy

Administrative Tasks

„ Using the Admin Console, some

of the more important tasks that can be performed are:

„ Defining new managed server instances

„ Define clusters, virtual hosts

„ Starting servers in the domain (in conjunction with the Node Manager)

„ Define "machines"

„ Setting up application resources (e.g. JDBC data sources, JMS connection factories, JTA, JNDI etc)

„ Configure security „ Deploy applications

All of these operations will be covered throughout this course!

Sample copy

Change Center

„

WLS v9 and WLS v10 (previous to 10.3)

featured a mandatory

Change Center

system

„

In order to make any changes, the administrator

had to obtain a "lock" from the console, and then

had to explicitly "activate" changes afterwards

„

While theoretically a good idea, it ended up acting as a

nuisance to most administrators

„

In WLS 10.3, this "lock and activate" is only

enabled by default in

production mode

.

„

In development mode, it is disabled by default

Can be toggled as desired

Sample copy

Other Administrative Tools

„

In addition to the admin console, WebLogic Server can also be

administered by:

„ Various BEA-provided command line tools (e.g.

weblogic.Deployer, startManagedWebLogic.cmd)

„ Very limited in scope; can only perform a few basic admin functions „ Will usually require command-line environment CLASSPATH settings to

point at WebLogic JARs

„ WLST

„ A full featured command-line based scripting environment „ Very powerful; can do anything the admin console can „ Uses the Jython language

„ ...will be discussed in a later chapter!

„

Inexperienced administrators should use the admin console as

much as possible; experienced administrators should look

towards migrating tasks to WLST scripts

Sample copy

Setting the Domain

Environment

„

If using command line tools, it is command

line environment must be

set

with

appropriate variables for many operations

„

e.g. any use of java weblogic.* commands will

require an appropriate CLASSPATH

„

Setting these variables can be done by

running script setDomainEnv in the

<domain_dir>/bin directory

„

Run this before doing any command line work.

Sample copy

Automatically Starting Admin

Servers

„

The admin server for a domain can be

configured with the OS to start automatically

upon system reboot

„

Windows: use the BEA provided

installSvc.cmd

to register the admin server

process as an OS service

„

Can be found at <wl_home>/server/bin

„

This service registration can be performed at domain

creation time using the configuration wizard

„

Unix: Use the OS-provided rc script and the

init

process

Sample copy

Managed Servers

„

The configuration wizard will create an admin server, but not

necessarily managed servers

„

Recall: managed servers are optional but recommended in a

domain

„ Typically, leave the admin server functioning exclusively as an administration tool, and use managed servers to host applications „ A cluster typically uses managed servers as its members

„

Once a domain has been created, managed servers can be

created through the admin console

„

As the name implies, managed servers are managed by the

admin server in the domain which they belong

„

To configure a Managed Server's settings, use the admin

console

Sample copy

Creating A Managed Server

„ Start the admin server and login

to the admin console

„ In the Domain Structure pain,

click on <domainname> | Environment | Servers

„ In the Summary Of Servers

pane, click New

„ Specify the new managed

server's settings „ Minimally, specify a „ Server name „ Port „ Click Finish

Sample copy

Server Details

„

A server's name should be unique within the domain

„ This is not a hostname; it is a handle to the managed server in the context of the domain

„

A server's port number should also be one that is not currently

in use

„ If the specified port number is in use, the server will not be able to start up.

„ Port conflict error!

„

It is possible for a server box to be

multihomed

, meaning it has

several network cards installed on it.

„ Implies one machine has multiple IP addresses

„ In this case, we can assign a specific listen address for each

managed server we create. This is the address that the server will listen on for incoming requests.

„ Not very common; usually, the field is left blank

Sample copy

Starting A Managed Server

„ Managed servers can be started from:

„ The command line, using the startManagedWebLogic.cmd script file which can be

found in <domain_dir>/bin

„ Usage:

„ startManagedWebLogic <managedservername> <adminserverURL> „ e.g.

„ startManagedWebLogic TestServer http://localhost:7001

„ Specify a user name/password that has boot privileges (typically admin username/password)

„ The managed server will launch and will attempt to connect to the specified

admin server to obtain configuration info

„ If the admin server is not running, the managed server will start in "independence

mode"

„ Server will run, but will not accept any configuration changes.

„ Alternatively, if (and only if) the Node Manager is being used, a managed

server can be started from inside the admin console

„ The Node Manager will be discussed in a later chapter

Sample copy

Password boot.properties

„

It is time consuming to have to enter usernames and

passwords every time a managed server is to be

started

„

Create a plain text file called boot.properties in

<domain_dir>.

Inside this file, create two lines:

username=<boot_username>

password=<boot_password>

On next boot, WebLogic Server will read this file and use the

specified username and password. It will then encrypt it so

it cannot be viewed.

Sample copy

Examining Server Status

„ The status of all servers in a domain (running/starting/stopped, etc) can be examined

from the admin console

„ Environment | Servers

„ Should always check this after starting managed servers

„ A domain may run all servers on one physical machine, or it may contain servers

across several machines (more common for clustering).

„ In terms of administrative control, the physical machine on which a managed server is

irrelevant; the AdminServer for the domain will control all managed servers that belong to it

Sample copy

Shutting Down Servers

„ Servers can be properly shutdown in two ways:

„ Through the command line

„ stopWebLogic.cmd (or stopWebLogic.sh for Unix) in <domain_dir>/bin to shutdown the

AdminServer

„ stopManagedWebLogic.cmd (or stopManagedWebLogic.sh for Unix) in the same directory to

shutdown managed servers

„ Through the admin console

„ The Node Manager is not necessary for this

„ For a server, click its Control tab. Check the Server to shutdown and click the Shutdown button

„ Through WLST

„ WLST will be discussed in the next chapter

Sample copy

Shutting Down Servers

„ When shutting down servers, a Force or Wait can be specified

„ Force implies "shut down immediately, even if users are connected to the server"

„ Connected users will be ungracefully "booted" „ Avoid doing this for live production machines

„ Wait will tell WebLogic Server to wait until all connected users finish their work

„ A timeout can be specified; if work does not complete before the timeout expires,

a force shutdown will occur

„ Both of these are considered "Graceful" shutdowns and allow WebLogic to "clean up" after itself if necessary.

„ Ways to improperly shut down WebLogic: „ Killing the process through the OS

„ Ctrl-C on the process window where a server is running, or simply closing it „ Reboot the machine

„ Avoid doing these where possible! Explicitly killing a WebLogic Server

process in these ways is ungraceful and may leave the domain in a corrupted state.

Sample copy

Admin Server Shutdown

„

An admin server in a domain can be shutdown without affecting

any running Managed servers

„ Recall, admin server is just for administrative use. If all the

managed servers have been properly configured, and no changes are pending, the admin server can be shutdown safely

„ Admin console will not be available

„ Managed servers will go into independence mode „ Domain log will not be updated

„ The domain log will be discussed later

„ No changes can be made to the domain until the admin server is restarted

„ When the admin server is restarted, it will notify the managed servers

that it is back in business.

„

The admin server is not a single point of failure!

„ Managed servers will continue to run and host applications in the absence of the admin server

Sample copy

Admin Server Backup

„

If the admin server cannot be restarted on

the same machine, a backup can be made on

a separate machine

„

On the backup machine:

„

Install the software

„

Copy the domain directory from the old machine to the

backup machine

„

Launch the server on the backup machine

„

Managed servers running in independence mode should

detect the new 'backup' admin server.

Sample copy

Start Scripts

„

Both startWebLogic(.sh, .cmd) and

startManagedWebLogic(.sh, .cmd) can be

edited by the administrator if necessary

„

e.g. setting classpaths and other environment

variables

„

Additionally, these domain specific scripts

may call other WebLogic Server standard

scripts (e.g. setDomainEnv.cmd)

„

Edit these scripts with care. Making a typo in

one of the core WebLogic Server scripts can

result in all scripts to fail.

Sample copy

config.xml

„ In previous version of WebLogic Server, config.xml was the "master"

configuration

„ The entire domain configuration was kept in this one file „ As of WebLogic Server 9.x, the file has been changed

„ Older config.xml files cannot be used, so do not copy over one from a previous version

„ Now stored in a directory called <domain_dir>/config „ Is no longer "monolithic"

„ References other xml files in other subfolders in the <domain_dir>

„ No more automatic ".booted" backups

„ WebLogic no longer makes a backup copy of config.xml upon successful bootup „ Administrator will have to manually backup config directory

„ Although it is possible to change WebLogic Server's configuration by

manually editing these config files, it is highly reccomended not to do so

„ A typo or mistake can render a domain useless „ Only make changes through the proper admin tools

Sample copy

Summary

„

Domains are logical collections of an

Administration Server and zero or more

Managed Servers and are created through

the Domain Configuration Wizard

„

WebLogic Server can be started using BEA

provided scripts

„

WebLogic Server is administered primarily via

a browser-based administration console

Sample copy