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-phase-commit.



• 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 CodeCreating 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 CodeSending 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


• JNDI Name-The JNDI name for the resource. • 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.




• JNDI Name-The JNDI name for the resource. • 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 message-driven bean should be acknowledged.


Creating a JMS Activation Spec• 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


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/bladetcb6profile \ -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/wasinfo/v6r1/index.jsp

• IBM Redbook – sg247304 WAS 6.1 System Management and configuration.

• Admin Console context sensitive online help.

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp


Summary

• Administration of WebSphere Resources– JDBC Administration– JMS Administration

• WebSphere Naming• JEE Class Loading• Working with Profiles

websphere 6.1 admin course 2

Technology

jdbc connection

jdbc provider step

jdbc api

new jdbc provider

data source step

new data source

data source api

jdbc driver type