WebSphere 6.1 admin Course 2

WebSphere Administration
Course

Copyright © Oded Nissan 2009

Agenda
• Administration of WebSphere Resources
– JDBC Administration
– JMS Administration

•
•
•
•

WebSphere Naming
JEE Class Loading
Working with Profiles
Summary

Administration of WebSphere
Resources


JDBC Data Source Administration


Java Database Connectivity (JDBC)
• Java programs communicate with databases
and manipulate their data using the
JDBC™API.
• A JDBC driver enables Java applications to
connect to a database in a particular DBMS
and allows programmers to manipulate that
database using the JDBC API.


Java Database Connectivity (JDBC)
• Database vendors implement the JDBC API.
The implementation is called a JDBC Driver.
• The driver is provided as a jar file that should
be included in the classpath of the using
program.
• JDBC is a standard JavaSE technology.


JDBC Architecture


The Data Source API
• The Data Source API was introduced in the
JDBC 2.0 Optional Package as an easier, more
generic means of obtaining a Connection.
• Application servers work with JDBC using the
Data Source API.
• WebSphere uses the Data Source API to
manage connection pooling, container
managed transactions etc.


Data source and JDBC Provider
• The JDBC provider defines the driver in use.
We can configure more than one JDBC
provider in WebSphere.
• The DataSource uses a specific provider and
defines the database host, port, database
name, schema etc.
• We can think of the provider as the class and
the DataSource as the instance (sort of..).


Data Source
• The JCA connection manager provides
connection pooling, transaction support and
security support.
• The JDBC driver is used by the connection
manager to obtain connections.


Data Source


The Data source programming model
• The application looks up the datasource in the JNDI
tree and obtains it.
• The application calls getConnection() on the Data
source object obtained to get a JDBC Connection.
The connection is retrieved from the connection
pool.
• The application uses the connection to access the
database.
• The application calls the close() method on the
connection when it is done, the connection is
returned to the pool.

Creating a Data Source


• Create a JDBC Provider, specify the JDBC
driver to be used by the specific data base.
• Create a data source specify the connection
settings for the database.


Creating a JDBC Provider
• Using the Admin console select Resources>JDBC->JDBCProviders
• Select the scope for which the resource will be
visible, default is node.
• Press the new button to create a new JDBC
Provider.


Creating a JDBC Provider (step 1)


• Database type – select the type of the
database, WebSphere is preconfigured for
popular databases such as DB2, Oracle etc.
• Provider type – select the JDBC driver to use.
• Implementation type – XA or regular
connection. Use XA to support two-phasecommit.


• Classpath – the relevant classpath for the
specific JDBC driver.
• Library path – specify the value for the
environment variable specifying the directory
with the JDBC driver. Can also be set using
Environment->WebSphere variables.
• Native library path – optional path to native
libraries used by the JDBC driver.


• Review the settings and press finish to create
the JDBC Provider
• Press the save link to save the provider to the
master configuration.
• It is recommended to restart the server after
adding a new JDBC provider.


• Using the Admin console select Resources>JDBC->Data sources
• Select the scope for which the resource will be
visible, default is node.
• Press the new button to create a new data
source.


Creating a Data Source (step 1)


• Data source name – enter a name for the data
source.
• JNDI name – the name the data source will be bound
to in the JNDI naming tree.
• Authentication alias – choose an existing
authentication alias or create a new one by pressing
the link. The authentication alias stores the
authentication data for the database (user,
password).
• Press next

• Choose the JDBC Provider
• Press next


• Database name – the name of the database.
• Driver type – the JDBC driver type to use.
• Server name – the name of the server where
the database instance is running.
• Port number – the port the database instance
is listening to.


• Review the settings and press finish to create
the data source
• Press the save link to save the data source to
the master configuration.
• You can now test the connection by pressing
the Test connection button.


Testing the connection


Update Data source properties
•
•
•
•

Click the data source in the resource list.
Click custom properties
Click new to add a new property.
Click a property to change its value.


Update Data source properties


JMS Administration


Introduction to JMS
• JMS is a vendor-neutral API that can be used to
access enterprise messaging systems
• Applications that use JMS are called JMS clients , and
the messaging system that handles routing and
delivery of messages is called the JMS provider.
• A JMS client that sends a message is called a
producer , and a JMS client that receives a message
is called a consumer . A single JMS client can be both
a producer and a consumer.


JMS Architecture
A JMS application is composed of the following parts:
• A JMS provider: A messaging system that
implements the JMS specification.
• JMS clients: Java applications that send and receive
messages.
• Messages: Objects that are used to communicate
information between JMS clients.
• Administered objects: Preconfigured JMS objects
that are created by an administrator for the use of
JMS clients.

JMS Delivery Modes
JMS supports two different message delivery
models:
• Point-to-Point (Queue destination): In this
model, a message is delivered from a
producer to one consumer.
• Publish/Subscribe (Topic destination): In this
model, a message is delivered from a
producer to any number of consumers.

Point to Point
• The messages are delivered to the destination, which
is a queue, and then delivered to one of the
consumers registered for the queue. While any
number of producers can send messages to the
queue, each message is guaranteed to be delivered,
and consumed by one consumer. If no consumers
are registered to consume the messages, the queue
holds them until a consumer registers to consume
them.


Publish/Subscribe
• Messages are delivered to the topic destination, and
then to all active consumers who have subscribed to
the topic. In addition, any number of producers can
send messages to a topic destination, and each
message can be delivered to any number of
subscribers. If there are no consumers registered,
the topic destination doesn't hold messages unless it
has durable subscription for inactive consumers. A
durable subscription represents a consumer
registered with the topic destination that can be
inactive at the time the messages are sent to the
topic.

The JMS programming Model
• A JMS application consists of a set of
application-defined messages and a set of
clients that exchange them.
• JMS clients interact by sending and receiving
messages using the JMS API.
• A message is composed of three parts:
header, properties, and a body.


The JMS programming Model


JMS Message Types
•

The JMS specification defined six type or classes of messages that a JMS
provider must support:
– Message: This represents a message without a message body.
– StreamMessage: A message whose body contains a stream of Java
primitive types. It is written and read sequentially.
– MapMessage: A message whose body contains a set of name/value
pairs. The order of entries is not defined.
– TextMessage: A message whose body contains a Java string...such as
an XML message.
– ObjectMessage: A message whose body contains a serialized Java
object.
– BytesMessage: A message whose body contains a stream of
uninterpreted bytes.

Producing and Consuming Messages


Sample Code
Creating a connection:
QueueConnection conn;
QueueSession session;
Queue que;
InitialContext iniCtx = new InitialContext();
Object tmp = iniCtx.lookup("ConnectionFactory");
QueueConnectionFactory qcf = (QueueConnectionFactory) tmp;
conn = qcf.createQueueConnection();
que = (Queue) iniCtx.lookup("queue/testQueue");
session = conn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
conn.start();


Sample Code
Sending a message:

// Send a text msg
QueueSender send = session.createSender(que);
TextMessage tm = session.createTextMessage(text);
send.send(tm);

Receiving a message:

// Set the async listener
QueueReceiver recv = session.createReceiver(que);
recv.setMessageListener(new ExListener());
public static class ExListener implements MessageListener {
public void onMessage(Message msg) {
TextMessage tm = (TextMessage) msg;
try {
log.info("onMessage, recv text=" + tm.getText());
}
catch(Throwable t) {
….


Message Driven Beans


• Message-driven beans (MDBs) are stateless, server-side,
transaction-aware components for processing asynchronous
messages delivered via JMS. While a message-driven bean is
responsible for processing messages, its container manages
the component's environment, including transactions,
security, resources, concurrency, and message
acknowledgment..
• An MDB can process hundreds of JMS messages concurrently
because numerous instances of the MDB can execute
concurrently in the container.


MDB Example


The MDB Life Cycle
An MDB can be in two states:
• Does not exist
• Method Ready Pool – the pool is maintained
by the container, when the container decides
to reduce the number of MDB instances it
may destroy some instances.


The MDB Life Cycle


• MDB clients are regular JMS clients, in
contrast to other EJB types.
• Use MDBs to perform asynchronous
operations.
• MDBs can be a good fit for handling a high
load of events or observations.


JMS Resources


JMS Providers
• Default Messaging Provider - based on service
integration technologies and is fully integrated with
the WebSphere Application Server runtime
environment.
• WebSphere MQ Provider - integrate WebSphere
Application Server messaging applications into an
exising WebSphere MQ server.
• Generic Provider- integrate WebSphere messaging
with a 3rd party JMS provider.

Default Messaging Provider
• Based on a preconfigured JCA adapter that
integrates with a Service Integration Bus (SIB).
• The Admin Console allows us to configure the
adapter as if it was a JMS provider.
• The preferred choice for most JEE
applications, unless we are integrating with
other systems.


WebSphere MQ Provider
• Provides integration with MQ products for
both the point to point and publish-subscribe
messaging models.
• Creation of MQ objects such as queue
managers, channels and queues must be done
in the MQ product.
• These objects can then be used when
integrating with WebSphere.

Generic Provider
• You can configure any third-party messaging
provider that supports the JMS Version 1.1
specification.
• JMS Administered objects must be created
using the 3rd party provider.
• JMS Administered objects are bound to the
WAS JNDI tree, however, these are aliases to
the real JMS objects that are bound to an
external JNDI tree.

Generic Provider


Service Integration Bus
• A service integration bus is a group of one or
more application servers or server clusters in
a WebSphere® Application Server cell that
cooperate to provide asynchronous messaging
services.
• The application servers or server clusters in a
bus are known as bus members.


Service Integration Bus
• A service integration bus, or bus, is simply an
architectural concept. It gives an
administrator the ability to group a collection
of resources together that provide the
messaging capabilities of the bus.
• The application servers or server clusters in a
bus are known as bus members.


Service integration Bus in a Cell


Messaging Engine
• A messaging engine is the component within an
application server that provides the core messaging
functionality of a bus. At run time, it is the messaging
engines within a bus that communicate and
cooperate with each other to provide the messaging
capabilities of the bus.
• A messaging engine is responsible for managing the
resources of the bus and it also provides a
connection point to which local and remote client
applications can connect.

SIB and Messaging Engine


Message Store
• Every messaging engine defined within a bus has a
message store associated with it. A messaging engine
uses this message store to persist durable data, such
as persistent messages and transaction states.
• Durable data written to the message store survives
the orderly shutdown, or failure, of a messaging
engine, regardless of the reason for the failure.


Destinations
• A destination within a bus is a logical address to
which applications can attach as message producers,
message consumers, or both, in order to exchange
messages.
• The main types of destination that can be
configured on a bus are:
– Queue destinations for point-to-point messaging.
– Topic destinations for publish-subscribe messaging.


Using the Default Provider
• To create JMS resources using the default
provider:
– Create a Service Integration Bus (SIB)
– Add a member to the SIB.
– Create a destination on the SIB
– Create a JMS connection factory.
– Create the JMS destinations: queues or topics.


Creating a SIB
• From the navigation menu choose Service
Integration->Buses.
• Press the new button.
• Name the bus and press next.
• Confirm your bus creation.


Creating a SIB


Adding a bus member
•
•
•
•
•
•
•

Click bus members
Press Add
Choose a bus member to add, a server or a cluster.
Press next.
Choose the store for the bus, file store or data store.
Press next and edit store properties.
Press finish.


Adding a bus member


Create a destination
• From the navigation menu choose Service
integration->Buses choose the desired bus.
• Press destinations
• Press new
• Choose the destination type
• Enter a name for the destination.
• Press next.

• Choose a bus member to assign the
queue/topic to.
• Click finish.


Creating a JMS Connection Factory.
• From the navigation menu choose Resource>JMS->JMS providers.
• Choose the Default JMS Provider in the
required scope and press the connection
factories link.
• Press new to create a new connection factory.


• Name - The name by which this resource is known
for administrative purposes.
• JNDI Name-The JNDI name for the resource.
• Bus name - The name of the service integration bus
to connect to.
• Target - The name of a target that identifies a group
of messaging engines. Specify the type of target
using the Target type property.
• Target type - The type of target named in the Target
property.

• Target Significance - the significance of the target
group. Preferred or required.
• Target inbound transport chain - Type the name of
the transport chain that the application should use
when connecting to a messaging engine in separate
process to the application. The name you specify
must be one of the transport chains available in the
server that hosts the messaging engine, as listed on
the Servers > Application servers > server >
Messaging engine inbound transports panel.

• Provider endpoints - The list of comma
separated endpoints used to connect to a
bootstrap server. You only need to modify this
property if you have client applications
running outside of an application server.
• Connection Proximity - The proximity of
messaging engines that can accept connection
requests, in relation to the bootstrap
messaging engine.

• Durable subscription- properties for
configuring a durable supscription.
• Quality of Service - The reliability applied to
JMS messages sent using this connection
factory.
• Advanced Messaging-read ahead, temporary
queue name prefix and more.


Creating a Queue
• From the navigation menu choose
JMS>Queues.
• Select the scope and press new.
• Choose the default messaging engine.
• Press Next


Creating a Queue


Creating a Queue
• Name - The name by which this resource is known
for administrative purposes.
• Bus name - The name of the service integration bus
to connect to.
• Queue name - The name of the associated queue on
the service integration bus.
• Delivery Mode - the persistence mode of messages
on this destination.

Creating a Queue
• Time to live –The default length of time in
milliseconds from its dispatch time that a message
sent to this destination should be kept by the
system.
• Priority – The relative priority for messages sent to
this destination, in the range 0 to 9.
• Read ahead - an optimization that preemptively
assigns messages to consumers. This improves the
time taken to satisfy consumer requests.

JMS Activation Spec
• a JMS activation specification is used to
configure an instance of an Activation Spec
JavaBean for the default messaging JMS
provider.
• A JMS activation specification is then
associated with a message-driven bean during
application installation.


Creating a JMS Activation Spec
• From the navigation menu choose Resources>JMS->Activation spec.
• Choose the scope and press new.
• Choose the message provider press OK.


• Name - The name by which this resource is
known for administrative purposes.
• Destination type – queue or topic
• Destination JNDI – the JNDI name of the
destination.


• Message selector - a message selector property is a
string that is used to select a subset of the available
messages.
For example:
JMSType='car' AND color='blue' AND weight>2500
• Bus name – the name of the bus
• Acknowledge mode - The acknowledge mode
indicates how a message received by a messagedriven bean should be acknowledged.


• Target properties –same as for a JMS connection
factory.
• Authentication alias - The name of a J2C
authentication alias used for component-managed
authentication of connections to the service
integration bus.
• Maximum batch size - The maximum number of
messages received from the messaging engine in a
single batch.
• Maximum concurrent endpoints - The maximum
number of endpoints to which messages are
delivered concurrently.

WebSphere Naming


WebSphere Naming
• WAS has a naming service that is used to store
references to JEE resources.
• The naming service is a JNDI implementation.
• Objects are bound into a mostly hierarchical
structure, referred to as a name space. All
non-leaf objects are called contexts.


WebSphere Naming Features
• Distributed name space - For additional
scalability, the name space for a cell is
distributed among the various servers. The
deployment manager, node agent, and
application server processes all host a name
server.
• Transient and persistent partitions - The name
space is partitioned into transient areas and
persistent areas.

WebSphere Naming Features
• Federated name space structure - A name
space is a collection of all names bound to a
particular name server. A name space can
contain naming context bindings to contexts
located in other servers.
• Configured bindings - Administrators can
configure bindings into the name space.
• Support for CORBA URLS - WAS contains
support for CORBA object URLs

WebSphere Naming
• Use the DumpNameSpace.cmd utility in the
bin directory to dump the server’s
namespace.
• The DumpNameSpace command can be given
the host and port to connect to in the
command line arguments.
• The BOOTSTRAP_ADDRESS in the ports panel
specifies the naming server’s port.

Naming Bindings
• Bindings can be created in three ways:
– By application deployment the binding is specified
in the deployment descriptor.
– Explicitly using the admin console.
– Programmatically using the JNDI API.


Naming Bindings in the
AdminConsole
• From the navigation menu select
Environment->Naming->Name Space bindings
• Select the scope and click new.
• Select the binding type and enter the binding
value.


Naming Bindings in the
AdminConsole


Naming Bindings Using JNDI
• Obtain an InitialContext object.
• Perform lookups and binding of objects using
the InitialContext object.
• The InitialContext object must be given either
an iiop or CORBA style URL to the naming
server. If we are calling the local naming
server, no URL is needed.


• Getting an InitialContext


• Looking up and EJB home using a compound
name.


The Federated NameSpace


JEE ClassLoading


Java Class Loaders
• Class loaders enable the Java virtual machine
(JVM) to load classes. Given the name of a
class, the class loader locates the definition of
this class.
• Each Java class must be loaded by a class
loader.
• The JVM uses more than one class loader.
Class loaders are organized in a hierarchy

Java Class Loaders
• By default the JVM uses three class loaders:
– bootstrap class loader loads the core Java libraries
– extensions class loader loads extention java
libraries
– application class loader loads classes from the
CLASSPATH.


Java Class Loaders
• A class loader delegates class loading to its
parent before trying to load the class itself.
The parent class loader can be either another
custom class loader or the bootstrap class
loader.
• A class loader can only delegate requests to its
parent class loader, never to its child class
loaders (it can go up the hierarchy but never
down).

The JVM ClassLoader Hierarchy


The WebSphere Class Loader
Hierarchy


WebSphere Class Loaders
• The WAS extension class loader - The class path used
by the extensions class loader is retrieved from the
ws.ext.dirs system property.
• Web Module class loader – loads classes from the
WEB-INF/classes WEB-INF/lib directories in the web
application.
• Application class loader – handles EJB modules utility
jars etc that reside in the EAR file.


WAS Class Loader Policies
• Single - a single application loader is used to
load all EJBs, utility JARs, and shared libraries.
Same with single web class loader.
• Multiple – each application (or web
application) will receive its own class loader.


Multiple Class Loaders
• Total isolation between applications and web
modules.


Single Web class loader
• WAR2-2 is loader by the application class
loader.


Single Application class loader
• Single application class loader and single web
class loader for WAR2.


Class loading order
• Parent first – first try to load classes using the
parent class loader. This is the default. (JVM
behavior).
• Application first (parent last) – try to load
classes using the application’s class loader
(web or application) before delegating to the
parent. This allows the application to override
classes in the parent.

Shared Libraries
• These are libraries that we want to share
among all applications. For example:
framework libraries.
• Shared libraries are defined using the
administration tools. They consist of a
symbolic name, a Java class path, and a native
path for loading JNI libraries.
• Share libraries need to be associated with an
application in order to be loaded.

Class loader viewer
• the Class Loader Viewer displays the hierarchy of
class loaders and their classpaths.
• To enable the Class Loader Viewer Service, select
Servers → Application Servers → <server name> and
then click the Class Loader Viewer Service under the
Additional Properties link. Then select Enable service
at server startup.
• You will need to restart the application server for the
setting to take effect.

WebSphere Profiles


WebSphere Profiles
• A set of WebSphere configuration files that
represent a WAS instance.
• In the WAS Base product, you can only have
stand-alone application servers, Each
application server is defined within a single
cell and node. The administration console is
hosted within the application server and can
only connect to that application server.

WebSphere Profiles
• Standalone server profile.


WebSphere Profiles
• With the Network Deployment package, you have
the option of defining multiple application servers
with central management capabilities. The
administration domain is the cell, consisting of one
or more nodes.
• Each node contains one or more application servers
and a node agent that provides an administration
point management by the deployment manager.


WebSphere Profiles
• Profiles with Network Deployment


Profile Types
• Application Server profile - defines a single stand-alone
application server.
• Deployment manager profile -defines a deployment manager
in a distributed server environment.
• Custom profile - A custom profile is an empty node, intended
for federation to a deployment
• manager. This type of profile is used when you are building a
distributed server
• environment.
• Cell profile - A cell profile is actually a combination of two
profiles: a deployment manager profile and an application
server profile. Useful for test environments.

Profile Directory Structure


Creating a profile
• From the <WAS
HOME>bin/ProfileManagment directory run
PMT.bat
• Choose the type of the profile to create.
• In case of an application server profile choose
whether to install the admin console and
default application.
• Press next

Creating a profile
• Give the profile a name and choose the profile
directory (to override the default).


Creating a profile
• You can enter the node name and host name
defaults are automatically filled.


Creating a profile
• You can change the ports to avoid collision
with an existing server.


Creating a profile
• On windows systems you can run the profile
as a windows service.


Creating a profile
• Press next, review settings and press finish to
create the profile.
• The First Steps console is started.
• Now we can move to the profile directory and
start the server using the startServer
command from the bin directory.


Backing up a profile
• Use the backupConfig command to back up a
profile. The command will zip the
configuration file and store it in the current
directory or a specified file name. The zip file
can be restored using the restoreConfig
command.
• Run backupConfig from the
<WAS_HOME>/bin directory

Restoring a profile
• Use the restoreConfig command to restore a
profile configuration using an archive
previously generated using backupConfig. If
the configuration to be restored exists, the
config directory is renamed to config.old
before the restore begins.
• The command then restores the entire
contents of the <profile_home>/config
directory

Exporting and Importing Profiles
• WAS provides a mechanism that allows you to export
certain profiles, or server objects from a profile to an
archive. The archive can be distributed and imported
to other installations.
• An exported archive is a zip file of the config
directory with host-specific information removed.
• The exported archive can be the complete
configuration or a subset.
• Importing the archive creates the configurations
defined in the archive.

Exporting and importing profiles
• To export a profile run wsadmin, type the
following command:
– $AdminTask exportWasprofile {-archive
<archivename>.car}

• To import a profile run wsadmin, type the
following command:
– $AdminTask importWasprofile {-archive
<archivename>.car}

Managing Profiles
• The wasprofile command line tool can also be
used to create profiles from the command
line.
• The wasprofile tool can also delete and list
available profiles.
• Listing available profiles:
– wasprofile.sh -listProfiles


Managing Profiles
• Creating a profile:
– /wasprofile.sh -create -profileName bladetcb6profile
-profilePath
/usr/IBM/WebSphere/AppServer/profiles/bladetcb6profil
e -templatePath
/usr/WebSphere/AppServer/profileTemplates/default
-nodeName bladetcb6node -cellName bladetcb6Cell
-hostName bladetcb6.rtp.raleigh.ibm.com
• Deleting a profile:
– wasprofile.sh -delete -profileName profile_name


Resources

• Info center for WAS 6.1 http://publib.boulder.ibm.com/infocenter/wasi
• IBM Redbook – sg247304 WAS 6.1 System
Management and configuration.
• Admin Console context sensitive online help.


Summary
• Administration of WebSphere Resources
– JDBC Administration
– JMS Administration

• WebSphere Naming
• JEE Class Loading
• Working with Profiles


WebSphere 6.1 admin Course 2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to WebSphere 6.1 admin Course 2

Similar to WebSphere 6.1 admin Course 2 (20)

More from odedns

More from odedns (6)

Recently uploaded

Recently uploaded (20)

WebSphere 6.1 admin Course 2