websphere application server - overvie application server ... technical sales specialist ibm italia...

IBM Italia SpA

© 2007 IBM Corporation| Milan, 07 January 2008 |

WebSphere Application Server - Overview

Marco DragoniIBM Software Group – Technical Sales Specialist

IBM Italia S.p.A.

IBM Value Assessment

© Copyright IBM Corporation 2007

2

Agenda

� Course and speaker introduction

� What is an Application Server

� Model-View-Controller Pattern

� WebSphere Basic Architecture and mapping to MVC

– EAR file composition

– J2EE standard

– WebSphere Application Server Family

� Understand difference between Basic and Network Deployment

– Accessing Application Server Resource

– A typical application flow

� HTTP Server and Plug-in

� Class Loader role

� JNDI role

� JDBC resource

� Web Services for J2EE



3

Course and Speaker Introduction

� 7 January 2008 (14.30-16.30) – WebSphere Application Server Overview (Marco

Dragoni)

� 11 January 2008 (11.30-13.30) – Order Process demonstration (Marco Dragoni).

Service Oriented Architecture Introduction (Mariano Ammirabile)

� 14 January 2008 (14.30-16.30) – WebSphere Integration Developer Introduction

(Marco Dragoni)

� 16 January 2008 (14.30-17.30) LAB 01 – Building a simple service-oriented application (BSM and BPEL)

� 18 January 2008 (11.30-13.30) – WebSphere Process Server, WebSphere

Enterprise Service Bus and WebSphere Service Registry and Repository Overview (Marco Dragoni)

� 23 January 2008 (10.30-13.30) LAB 02 – BO mapping, Human Task and

Selector component



4

What is an Application Server

� An Application Server is a runtime environment for hosting applications that are written following the J2EE specification

� An Applications Server, compliant with J2EE specification, offers services such as Security (JASS), Transaction (JTA), Messaging (JMS), Naming Services (JNDI), Database Connectivity (JDBC), etc.

� Any Web applications that are written to the J2EE specification can be installed and deployed on the server

� J2EE is:

– An open and standard based platform for developing, deploying and managing n-tier, Web-enabled, server-centric, and component-based enterprise applications

� J2EE add value to

– Developer

– Vendors

– Business Customer



5

J2EE – MVC Pattern (Model View Controller)

� Model to represent the underlying

data and business logic behaviuor in one place (Entity and Session

EJB). Make data and behaviour

independent from presentation. Represented by EJB.

� View display information

according to client types, display result of business logic.

Represented by JSP.� Controller serves as the logical

connection between the users

interaction and the business

services on the back.

Represented by Servlet.



6

J2EE Architecture

Web Tier EJB Tier

� The Presentation Tier processes input from the Client Side Tier, calls components

in the Business Logic Tier, and then sends a response back to the Client Side Tier

(Servlet, JSP)� The Business Logic Tier provides a framework for executing business logic and

for accessing business data in a distributed transactional environment (EJB)



7

Web Applications and anatomies

� It is often advantageous to treat each layer as an independent portion of your application

� Do not confuse logical separation of responsibilities with actual separation of components

� Some of the layers can be combined into single components to reduce

application complexity

� J2EE application anatomies samples:

– HTML client, JSP/Servlets, EJB, JDBC/Connector (4 tiers)

– HTML client, JSP/Servlets, JDBC (3 tiers)

– EJB standalone applications, EJB, JDBC/Connector (3 tiers)



8

J2EE 1.4 Application Components

Web Module

HTML

Java beans

Servlet/JSP

DeploymentDescriptor

EJB Module


Session

Entity

MDB

ResourceAdapter (RAR)


RA JavaClasses

ApplicationClient Module


RA JavaClasses

Main Class


Runs in Application ServerRuns in ApplicationClient Container



9

J2EE 1.4 Standard supported



10

WebSphere AS Packaging

WebSphere

Process

Server�Process Choreography

�Business Rules EngineWebSphere

ESB�Mediation Functions

WebSphere XD�Dynamic Operation

�High Performance Computing

�Management Facility

�Clustering

Failover

Workload Mgmt

�Distributed Administration

�Web Services

UDDI Registry

Web Services Gat.

�Edge Components

�IBM Ldap for prod env.

�TAM for prod env.

�DB2 Session Persistance

WebSphere ND

Application Server

Express/Base�Extended Transaction

Support

�Application Profiling

�Asynchronous Execution

�Dynamic Query

�Scheduling

�Startup Beans

�Service Integration Bus

WebSphere CE

Based on Apache

Geronimo



11

WebSphere AS Basic Architecture

MessagingEngine

Em

bedded H

TT

PS

erv

er

Web Container

Servlets JSPs

EJB Container

EJBs

ApplicationDatabasesApplicationData

XML Configuration

Files

HTTP Server Plug-in

HTTP Server

Application ServerApplication Server

Plug-in Configuration File

Dynamic Cache Name Server Security

… … ….

Web ServicesEngine

Data Replication JMX Transaction.

HTTP/S

Web Browser

HTTP/S



12

WebSphere AS Basic Administration

Application Server

WEB Container

Embedded HTTP Server9060

Administrative Services

Administrative Console

Application

Soap/HTTPor

RMI-IIOP

WebSphereWebSphereAdministrative ClientsAdministrative Clients

Custom Java Administrative

Clients

Scripting Client (wsadmin)

Web Browser

Update

Configuration Repository

Internet or Intranet

ConfigFiles

J2EEApps

(EARs)

Stand-alone Node

� Administrative Console run inside the same JVM running customer

application



13

WebSphere AS Express, Base – Sample Topologies

Http Server + WebSphere Plug-in WebSphere AS Database/EIS

HTTP Server

WAS

Database/EIS

� All in one machine

� Easy to maintain

� Low cost

� Low performance

� All in different machine

� A DMZ can be established

� No competition between DB and other resources (different tuning)

DMZ Network Intranet Network

Example 1

Example 2



14

WebSphere AS Network Deployment Architecture

� A deployment manager process

manages the node agents

– Holds the configuration repository for

the entire management domain,

called a cell

– Administrative Console runs inside

the DMgr

� A node is a logical grouping of servers

– Each node is managed by a single

node agent process

– A managed node is a node that

contains a node agent

– An unmanaged node is a node in the

cell without a node agent� Enables the rest of the environment to be

aware of the node

V6 Node

V6 Application

Server

V6 Application

Server…

V6 Node

V6 Application

Server

V6 Application

Server…

…

Cell



15

Network Deployment : File synchronization

� Deployment manager contains the master configuration

� Node agents synchronize their files with the master copy

� Automatically� At start up� Periodically

� Manually� Administrative console� Command line

� During synchronization� 1. Node agent asks for changes to master configuration� 2. New or updated files are copied to the node



16

V6 Node

V6 Application

Server

V6 Application

Server…V6 Node

V6 Application

Server

V6 Application

Server……

ConfigFiles

J2EEApps

(EARs)

ConfigFiles

J2EEApps

(EARs)

ConfigFiles

J2EEApps

(EARs)

Network Deployment : System Administration

Administrative ClientsAdministrative Clients

� ND allows you to manage the entire cell (all processes) from a central Deployment Manager

– Administrative clients connect to Deployment Manager

� Changes made by the administrative clients are saved in the master configuration

� The configuration is then synchronized with the Nodes

Master Configuration forthe Entire Cell

V6 Deployment Manager

WEB Container

Embedded HTTP Server

Administrative Services

Administrative Console

Application

9060Internet

or Intranet

Soap/HTTPor

RMI-IIOP

Custom Java Administrative

Clients

Scripting Client (wsadmin)

Web Browser

ConfigFiles

J2EEApps

(EARs)



17

WebSphere AS Example configuration (ND package)

Web Server + Plugin

DMGR

Node Agent

JVM AS

WebSphere

Cluster1

WebSphere Traffic

Client Traffic

LEGENDA

Caching Proxy

Load Balancer

INTERNET DMZ

INTRANET

Internet Client



18

Accessing Server Resources

Web browserHTTP(S)

ApplicationDatabasesApplicationData

Messaging Engine

Em

bedded H

TT

PS

erv

er

WebContainer

EJBContainer

Application ServerApplication Server

Web Services Engine

Servlets/JSPs EJBs

Java client

Web Servicesclient

RMI/IIOP SOAP/JMS

SOAP/HTTP(S)

JMS Client



19

The flow of an application



20

Plug-in configuration file

� The plug-in configuration file (plugin-cfg.xml) contains routing information for

all applications mapped to the Web server. This file is read by a binary plug-in

module loaded in the Web server.



21

Plug-in XML tag description

� VirtualHostGroup, VirtualHost: – A group of virtual host names and ports that will be specified in the HTTP Host header when the user

tries to retrieve a page. Enables you to group virtual host definitions together that are configured to handle similar types of requests. The requested host and port number are matched to a VirtualHosttag in a VirtualHostGroup.

� UriGroup, Uri :– A group of URIs that will be specified on the HTTP request line. The incoming client URI is compared

with all the Uri tags in the UriGroup to see if there is a match to determine if the application server will handle the request for the Route in conjunction with a virtual host match.

� Route:– The Route definition is the central element of the plug-in configuration. It specifies how the plug-in

will handle requests based on certain characteristics of the request. The Route definition contains the other main elements: a required ServerCluster, and either a VirtualHostGroup, UriGroup, or both. Using the information that is defined in the VirtualHostGroup and the UriGroup for the Route, the plug-in determines if the incoming request to the Web server should be sent on to the ServerClusterdefined in this Route. The plug-in sets scores for Routes if there is a VirtualHost and Uri match for an incoming request. Once the plug-in processes all Routes, the Route chosen is the one with the highest score.

� ServerCluster, Server:– The located ServerCluster from the Route tag contains a list of Server tags that in turn contain the

requested object. The ServerCluster located by finding the correct Route can optionally specify theWLM algorithm. This will then be used to select one Server from within the ServerGroup.

� Transport:– Once a Server has been located, its Transport tags describe how to connect to it.



22

Plug-in workload management policies

� Weighted round robin

– When using this algorithm, the plug-in selects a cluster member at random from which

to start. The first successful browser request is routed to this cluster member and then

its weight is decremented by 1. New browser requests are then sent round robin to

the other application servers and subsequently the weight for each application server

is decremented by 1. The spreading of the load is equal between application servers

until one application server reaches a weight of 0. From then on, only application

servers with a weight higher than 0 will have requests routed to them. The only

exception to this pattern is when a cluster member is added or restarted or when

session affinity comes into play.

� Random

– Requests are passed to cluster members randomly. Weights are not taken into

account as with round robin. The only time the application servers are not chosen

randomly is when there are requests with sessions associated with them. When the

random setting is used, cluster member selection does not take into account where

the last request was handled. This means that a new request could be handled by the

same cluster member as the last request.

23

Plug-in configuration file – Session Affinity

� In a clustered environment, any HTTP requests associated with an HTTP

session must be routed to the same Web application in the same JVM.

� This ensures that all of the HTTP requests are processed with a consistent view of the user’s HTTP session.

� The exception to this rule is when the cluster member fails or has to be

shut down.

content valueCache ID 0000Session ID SHOQmBQ8EokAQtzl_HYdxItseparator :Clone ID vuel491u

<?xml version="1.0" encoding="ISO-8859-1"?><Config>......<ServerCluster Name="MyCluster"><Server CloneID="vuel491u" LoadBalanceWeight="2"

Name="NodeA_server1"><Transport Hostname="wan" Port="9080" Protocol="http"/><Transport Hostname="wan" Port="9443" Protocol="https">......</Config>



24

Plug-in configuration file – Session Failover

� Server clusters provide a solution for failure of an application server. � Sessions created by cluster members in the server cluster share a common

persistent session store (Memory or Database).

� Any cluster member in the server cluster has the ability to see any user’s session

saved to persistent storage � If one of the cluster members fail, the user can continue to use session information

from another cluster member in the server cluster. This is known as failover.

Failover works regardless of whether the nodes reside on the same machine or

several machines.



25

Java Class Loader

� 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.

� When you start a JVM, you use three class

loaders: the Bootstrap class loader, the

Extensions class loader, and the System class

loader.

� The Extensions class loader is the parent for the System class loader. The Bootstrap class loader is

the parent for the Extensions class loader. The

class loaders hierarchy is shown

� Delegation is a key concept to understand when dealing with class loaders



26

ClassLoader behavior example

� A class called WhichClassLoader1 loads a class called

WhichClassLoader2, in turn invoking a class called WhichClassLoader3

� If all WhichClassLoaderX classes are put on the system

class path, the three classes are loaded by the System class loader, and this sample runs just fine.

� Now suppose you package the WhichClassLoader2.class

file in a JAR file that you store under

<JAVA_HOME>/lib/ext directory.

� As you can image, the program fails with a

NoClassDefFoundError exception, which might sound

strange because WhichClassLoader3 is on the system class path. The problem is that it is on the wrong class

path.



27

ClassLoader behavior example cont.

� The WhichClassLoader2 class was loaded by the Extensions class loader. In

fact, the System class loader delegated the load of the WhichClassLoader2 class

to the Extensions class loader, which delegated the load to the Bootstrap class

loader. Because the Bootstrap class loader could not find the class, the class loading control was returned to the Extensions class loader. The Extensions

class loader found the class and loaded it.

� Now, the Extensions class loader needs to load the WhichClassLoader3 class. It

delegates to the Bootstrap class path, which cannot find the class, then tries to

load it itself and does not find it either.

� A NoClassDefFoundError exception is thrown. Once a class is loaded by a class

loader, any new classes that it tries to load reuse the same class loader, or go up

the hierarchy to find a class.

� A class loader can only find classes by going up the hierarchy, never down.



28

WebSphere Class Loader policies

� The top box in red represents the Java (Bootstrap, Extension and System) class

loaders. WebSphere loads just enough here to get itself bootstrapped and initialize the WebSphere extension class loader.

� The WebSphere extensions class loader is where WebSphere itself is loaded

� EJB modules, utility JARs, resource

adapters files, and shared libraries

associated with an application are always grouped together into the

same class loader. This class loader

is called the Application class loader.

� Depending on the application class

loader policy, this application class

loader can be shared by multiple

applications (EARs), or be unique for

each application, which is the default.



29

WebSphere ClassLoader policies cont.

� There are settings in WAS that allow you to influence WebSphere class loader behavior.

– When the application class loader policy is set to Single, a single application class

loader is used to load all EJBs, utility JARs, and shared libraries within the application

server (JVM). If the WAR class loader policy then has been set to Application, the Web

module contents for this particular application are also loaded by this single class loader.

– When the application class loading policy is set to Multiple, the default, each application

will receive its own class loader for loading EJBs, utility JARs, and shared libraries.

Depending on whether the WAR class loader loading policy is set to Module or

Application, the Web module might or might not receive its own class loader.

Module

MultipleSingle

Module

Application



30

WebSphere ClassLoader delegation

� WebSphere’s application class loader and WAR class loader both have a setting

called the class loader mode.

� There are two possible values for the class loader mode: PARENT_FIRST and

PARENT_LAST

� PARENT_FIRST. This mode causes the class loader to first delegate the loading

of classes to its parent class loader before attempting to load the class from its

local class path. This is the default policy for standard Java class loaders.

� PARENT_LAST, the class loader attempts to load classes from its local class

path before delegating the class loading to its parent. This policy allows an

application class loader to override and provide its own version of a class that

exists in the parent class loader.



31

JNDI

� WebSphere Application Server provides a JNDI implementation that you can use to access CosNaming name servers through the JNDI interface

� CosNaming provides the server-side implementation and is where the name space is stored.

� JNDI essentially provides a client-side wrapper of the name space stored in CosNaming, and interacts with the CosNaming server on behalf of the client.

� WebSphere application clients use the naming service to obtain references to objects related to those applications, such as EJB homes.

� These objects are bound into a mostly hierarchical structure, referred to as a name space.

� In this structure, all non-leaf objects are called contexts.



32

JNDI

� Naming operations, such as lookups and binds, are performed on contexts.

� All naming operations begin with obtaining an initial context. You can view the initial context as a starting point in the name space. For example:

– The name myApp/myEJB consists of one non-leaf binding with the name myApp,

which is a context.

– The name also includes one leaf binding with the name myEJB, relative to myApp.

The object bound with the name myEJB in this example happens to be an EJB home

reference.

– The whole name myApp/myEJB is relative to the initial context, which can be viewed

as a starting place when performing naming operations.



33

JNDI

� The name space can be accessed and manipulated through a name server.

� Users of a name server are referred to as naming clients

� Naming clients typically use Java Naming and Directory Interface (JNDI) to

perform naming operations. Naming clients can also use the Common Object Request Broker Architecture (CORBA) CosNaming interface.

� Notice that all WebSphere

Application Server processes host their own naming service and local

name space (remove bottleneck)



34

JNDI

� There are three options available for binding EJB (<ejb-ref>) and resource

(<resource-ref>) object names to the WebSphere Application Server name

space:

– Simple name -- ejb/webbank/Account

– Compound/fully qualified name -- cell/nodes/node1/servers/server1/ejb/webbank/Account

– Corbaname -- corbaname::myhost1:9812/NameServiceServerRoot#ejb/webbank/Account

� The binding you can use to look up an object depends on whether or not the

application is running within the same application server.



35

JNDI - Federated namespace

� The system partition is a reflection of the cell topology and is read-only. This part of the name

space cannot be changed programmatically, because it is based on the configuration rather

than runtime settings.

� The persistent partitions are primarily for the

storage of resource configuration, such as data

sources, JMS destinations etc.

� Cell persistent root. This partition is used

to register persistent objects that are

available to all the nodes and managed

processes of a cell.

� Node persistent root. This partition is

used to register persistent objects available

to the nodes and it their managed

processes.

� The server root transient partition is updateable through APIs, and is meant for

information such as EJB bindings and JNDI names. This name space is

transient and bindings are created each time a server process starts. It reads

configuration data from the file system, for example EJB deployment

descriptors, to register the necessary objects in this space.



36

JDBC Resource

� A data source represents a real-world data source, such as a relational database.

� When a data source object has been registered with a JNDI namingservice, an application can retrieve it from the naming service and use it to make a connection to the data source it represents

� Information about the data source and how to locate it, such as its name, the server on which it resides, its port number, and so on, is stored in the form of properties on the DataSource object. This makes an application more portable because it does not need to hard code a driver name, which often includes the name of a particular vendor

� The connection is usually a pooled connection. That is, once theapplication closes the connection, the connection is returned to a connection pool, rather than being destroyed.

� Data source classes and JDBC drivers are implemented by the datasource vendor.



37

JDBC Resource

� The programming model for accessing a data source is as follows:

– 1. An application retrieves a DataSource object from the JNDI naming space.

– 2. After the DataSource object is obtained, the application code calls getConnection()

on the data source to get a Connection object. The connection is obtained from a pool

of connections.

– 3. Once the connection is acquired, the application sends SQL queries or updates to

the database.

– 4. Once the application component is finished with the connection, it calls the close()

method on the connection. Closing a connection handle should not close the physical

connection to the EIS.



38

JDBC Resource

� In WebSphere Application Server, connection pooling is provided by two parts, a

JCA Connection Manager and a relational resource adapter

� The JCA Connection Manager provides connection pooling, local transaction,

and security support

� The relational resource adapter provides JDBC wrappers and the JCA CCI

implementation that allows BMP, JDBC applications, and CMP beans to access the database



39

JDBC Resource – Connection Pooling

� WebSphere® Application Server provides connection pooling for Java Database

Connectivity (JDBC), Java™ Message Service (JMS), and Enterprise Information

System (EIS) connections.

� The purpose of pooling connections is to improve performance by reducing the

overhead involved in creating a new connection every time the application

requests one.

� For JDBC connections, there is one connection pool for each data source that is created in WebSphere Application Server



40

Web Services for J2EE (JAX-RPC and WSEE)

� JAX-RPC provides the programming model for SOAP-based applications by

abstracting the runtime details and providing mapping services between Java

and WSDL.

� Web Services for J2EE Specification (WSEE) adds additional artifacts to those

defined by JAX-RPC and brings JAX-RPC to the J2EE container.

� WSEE defines the required architecture for Web services for the Java 2 Platform

Enterprise Edition (J2EE) environment.

� WSEE standardizes the packaging, deployment, and programming model for

Web services in a J2EE environment.

� Although WSEE does not restrict any implementation, it only defines two:

– Stateless session EJB in an EJB container

– Java class running in a Web container



41

JAX-RPC Client

� A JAX-RPC client is capable of invoking a Web service irrespective of whether

the service has been defined on the J2EE platform or on a non-Java platform.

� JAX-RPC clients can run inside a J2EE container or as a stand-alone Java

client.

� There are three types of Web services clients:

– Static stub

– Dynamic proxy

– Dynamic invocation interface (DII)



42

JAX-RPC Client – Static Stub

� After the proxy classes have been generated, they are copied to the client

machine. The client can then invoke the Web service based only on these proxy

classes.

� These proxy classes are generated from the WSDL of the Web service.

– In WebSphere Application Server, the proxy classes can be generated by the tool

<WAS_HOME>/bin/WSDL2JAVA.



43

JAX-RPC Client – Static Stub, calling sequence

1. The client instantiates the service locator.

2. The client calls the service locator to retrieve the SEI (an instance of the

client stub that implements the SEI is returned).

3. The client invokes a Web service through the SEI.



44

WSEE Client – Static Stub, calling sequence

1. The client makes an JNDI lookup to get an instance of the service object,which implements a service interface.

2. The client uses a factory method of the service object to retrieve the client

stub. The client stub implements the SEI.

3. The client invokes the Web service through the SEI.

The configurations for the Web service client and server side are represented by

the client and server deployment descriptor shown at the bottom



45

JAX-RPC Client – Dynamic Proxy and DII

� Dynamic Proxy

� In dynamic proxy clients, the default destination of the Web service can be changed in the client by specifying a different destination in the client application.

� At runtime the service locator is instantiated. The SEI is retrieved using a

destination (QName).

� Dynamic invocation interface (DII) - (limited support in WAS)

� DII is used when the WSDL of the Web service can change considerably over

time. DII-based clients do not use proxy classes, but instead they read the entire

WSDL file during runtime:

– Instantiate a DII service class.

– Instantiate a Call object (Call is a class provided by JAX-RPC).

– Populate the Call object.

– Invoke the Web service operation on the Call object.



46

WSEE Server Container responsability

� A server container provides a JAX-RPC runtime environment for invoking Web

services ports. The container is responsible for:

– Listening to Web services SOAP HTTP requests

– Parsing the inbound message

– Mapping the messages to the implementation class and method

– Creating Java objects from the SOAP envelope

– Invoking the service implementation bean handlers and instance methods

– Capturing the response

– Mapping the Java response objects into a SOAP message

– Creating the message envelope

– Sending the message to the client



47

SOAP over HTTP request

� The client request to the Java proxy is handled by the SOAP client and is routed

to the server over HTTP.

� In the server, the WebSphere SOAP engine calls a JavaBean Web service as a

servlet, or uses a servlet in a Web router module to invoke an EJB Web service.



48

References

� http://www.redbooks.ibm.com

websphere application server - overvie application server ... technical sales specialist ibm italia...

Documents