26 - Theory and Fundamentals - Slide

© 2003 BEA Systems, Inc. 955

Theory and Fundamentals

At the end of this module you will be able to:

� EJB fundamentals

� Transaction fundamentals

� JDBC fundamentals

� JMS and MOM fundamentals

Module 26

Theory and Fundamentals-1


Road Map

1. EJB Fundamentals

– Major EJB Types and Their Purpose

– EJB Pool and Cache Management

2. Transaction fundamentals

3. JDBC fundamentals

4. JMS and MOM fundamentals



Enterprise JavaBeans™

� Enterprise JavaBeans™ (EJB) standardizes the development and deployment of server components built in Java.

� The EJB specification defines relationships between:– the EJB and its container

– the container and the application server

– the container and the client



Types of EJBs

� The EJB specification discusses four types of objects:– stateless session beans

– stateful session beans

– entity beans

– message driven beans



What Is a Stateless Session EJB?

� Stateless session EJBs:– provide independent services

– do not maintain state on behalf of client

– are synchronous

– do not survive EJB server crashes

– are maintained in memory

– calls can be handled by any instance with the same results

Stateless Session EJB



What Is a Stateful Session EJB?

� Stateful session EJBs:– provide conversational interaction

– store state on behalf of the client

– are synchronous

– do not survive EJB server crashes

– are maintained in memory

– each instance is associated to a single client

Stateful Session EJB



Session EJB Examples

� Stateless session EJBs:– an EJB that checks to see if

a stock symbol is valid

– an EJB that determines the local billing price for a phone call

– an EJB that calculates an insurance quote based on a provided customer profile

– an EJB that assembles a standard report from several departments

� Stateful session EJBs:– an EJB that books a flight

and car rental at a travel agents Web site

– an EJB that orders spare parts for a car as part of an application

– an EJB that manages the shopping cart in a Web site



What Is an Entity EJB?

� Entity EJBs have the following behavior:– they are representations of persistent data

– they can survive a crash

– multiple clients can be using EJBs that represent the same data

– the EJB manages an in-memory “copy” of the data in the persistent store

Entity EJB



Entity EJB Examples

� Some entity EJB examples include:– an EJB that represents a football player’s career

statistics

– an EJB that represents a stock’s historical prices

– an EJB that represents a genome sequence

– an EJB that represents the outline for a course

– an EJB that contains your personal profile for accessing your favorite Web site



Message-Driven Beans

� Message-driven beans (MDB):– are asynchronous stateless components

– behave similarly to stateless session beans

– are JMS message consumers

� Clients do not interact directly with MDBs

Container

ClientSends

JMS DestinationMessage



Message-Driven EJB Examples

� Message-driven EJBs:– an EJB that stores logging messages

– an EJB that processes a Web site’s feedback messages sent from a Servlet

– an EJB that processes news article postings



JAR File Structure

� EJB components come packaged in a JAR file.

� The format of the JAR file is shown here:

� EJBs are configured by modifying the XML files.



EJB Pooling & Caching in WLS

� EJB objects can be pooled:– creating many instances at deployment time– servicing many concurrent clients faster

� EJB objects can also be cached:– the number of objects is limited to a certain ceiling,

so memory cannot be filled up– only the recently used objects stay in memory– other objects are either

• saved to persistent storage, or

• destroyed (if they are timed out)

� Pooling and Caching are set up by editing the file META-INF\weblogic-ejb-jar.xml.



EJB Administrator Tasks with WLS

� You can set up Stateless session EJBs for:– pool size

� You can configure Stateful session EJBs’:– cache size

– idle timeout - if memory is short, not used objects can be disposed of after a certain period of time

– cache type - if memory is short, objects can be stored to persistent storage (if they are not timed out); this is called passivation

� Entity EJBs are both pooled and cached, so you can set their:– pool size

– cache size and idle timeout



Stateless Session EJB Pool Settings

� You can manage the stateless session EJB pool by:– capping the number of instances

– setting an initial pool size

META-INF\weblogic-ejb-jar.xml Snippet: <!–- Other Tags As Appropriate Here… -->

<weblogic-enterprise-bean><ejb-name>HelloEJB</ejb-name><stateless-session-descriptor>

<pool><max-beans-in-free-pool>15</max-beans-in-free-pool><initial-beans-in-free-pool>5</initial-beans-in-free-pool>

</pool> </stateless-session-descriptor><jndi-name>HelloWorld</jndi-name>

</weblogic-enterprise-bean>1001011110



Stateful Session EJB Cache Settings

� You can manage the stateless session EJB cache by:– capping the number of instances

– setting a timeout period

– setting the passivation strategy for the cached EJBs

META-INF\weblogic-ejb-jar.xml Snippet:<!–- Other Tags As Appropriate Here… -->

<weblogic-enterprise-bean><ejb-name>HelloEJB</ejb-name><stateful-session-descriptor>

<stateful-session-cache><max-beans-in-cache>1000</max-beans-in-cache><idle-timeout-seconds>60</idle-timeout-seconds><cache-type>NRU</cache-type>

</stateful-session-cache> </stateful-session-descriptor><jndi-name>HelloEJB</jndi-name>

</weblogic-enterprise-bean> 1001011110



Entity EJB Pool & Cache Settings

� You can manage the entity EJB:– pool by capping the number of instances and setting an

initial pool size

– cache by capping the number of instances and setting a timeout period

META-INF\weblogic-ejb-jar.xml Snippet:<weblogic-enterprise-bean>

<ejb-name>DogEBean</ejb-name><entity-descriptor><pool><max-beans-in-free-pool>15</max-beans-in-free-pool><initial-beans-in-free-pool>5</initial-beans-in-free-pool>

</pool><entity-cache> <max-beans-in-cache>100</max-beans-in-cache><idle-timeout-seconds>30</idle-timeout-seconds>

</entity-cache> </entity-descriptor> example 10

01011110



Pool Size Determination

� How many EJBs should be in the pool?

� Factors to consider:– number of threads set in WLS

– number of concurrent clients

– number of dependent backend resources (for example, database connections)

� Pool size will equally affect all servers of a cluster.



Cache Size Determination

� Some criteria that affect the size of your cache include:– the total amount of Java heap space available in

the VM

– the number of different stateful session and entity beans deployed

– the amount of memory a single EJB consumes while active

– the number of concurrent clients

– clustering requires more memory because of replication of EJBs



Section Review

� Major EJB types and their purpose

� EJB pool and cache management

In this section we discussed:



Road Map

1. EJB Fundamentals


– Transactions

– The ACID Properties of Transactions

– Commit and Rollback

– The Two-phase Commit Protocol





What Is a Transaction?

� A transaction is a mechanism to handle groups of operations as though they were one.

� Either all operations in a transaction occur or none at all.

� Operations involved in a transaction may rely on many different servers and databases.



ACID Properties of a Transaction

� A transaction is formally defined by the set of properties known by the acronym ACID.

� The acronym ACID stands for:– Atomic

– Consistent

– Isolated

– Durable



Transfering Without Transactions

� Successful transfer:

� Unsuccessful transfer (accounts are left in an inconsistent state):

$1000+$100$1100

$500-$100$400

2) Deposit: $100

1) Withdraw: $100Transfer: $100From: Acct 1To: Acct 2

ATM Bank

Account 1

Account 2

$1000

$500-$100$4001) Withdraw: $100

Transfer: $100From: Acct 1To: Acct 2

ATM Bank

Account 1

Account 2Failed

Deposit



Successful Transfer with Transactions

Transaction Started by Bank

� Changes within a transaction are buffered.

� If a transfer is successful, changes are committed(made permanent).


ATM Bank

$1100

$400CommitTransfer SuccessfulATM Bank

Account 1

Account 2

Transaction Started by Bank $500-$100$400

1) Withdraw: $100Account 1

Account 2$1000+$100$1100

2) Deposit: $100

Commit




� Changes within a transaction are buffered.

� If a problem occurs, the transaction is rolled backto the previous consistent state.


ATM Bank


$1000

$500-$100$4001) Withdraw: $100 Account 1

Account 2FailedDeposit

$1000

$500RollbackErrormessageATM Bank

Account 1

Account 2Rollback

Unsuccessful Transfer with Transactions



What Are Distributed Transactions?

� A resource, like a database, is controlled through software called a resource manager (RM).

� A local transaction is a transaction that deals with a single resource manager.

� A distributed transaction is a transaction that coordinates or spans multiple resource managers.

� Coordination of multiple resource managers is done by a transaction manager (TM).

� A transaction is often referred to as a transaction context.



The Two-Phase Commit Protocol

� The 2PC protocol uses two steps to commit changes within a distributed transaction.

� Phase 1 asks all RMs to prepare to make the changes and if any of them cannot, the transaction is aborted.

� Phase 2 asks all RMs to actually commit and make the changes permanent.

� A global transaction ID (XID) is used to track all changes associated with a distributed a transaction.



XA (Extended Architecture)

� XA:– is the interface used between WLS and Resource

Managers

– implements the 2PC protocol

– allows programs to control RMs that are involved in distributed transactions

ClientTransaction

Manager

RM1

RM2

XA

XA



� A Transaction Manager coordinates several resource managers.

� The two-phase commit (2PC) protocol is used to coordinate the transaction.

� The XA protocol implements 2PC.

Transaction and Resource Managers

Transaction Context started by Transaction Manager

TransactionManager

ResourceManager

ResourceManager

ResourceManager

Database

Printer

AnotherApp

Application

XA

XA

XA



A Successful Two-Phase Commit

Application

TLOG

TransactionManager

ResourceManager

ResourceManager

ResourceManager

Database

Printer

AnotherApp

Applicationpre-commit

ready

TransactionManager

ResourceManager

ResourceManager

ResourceManager

Database

Printer

AnotherApp

commit

committed

Phase 1Phase 2

TLOG



An Unsuccessful Two-Phase Commit

Application

TLOG

TransactionManager

ResourceManager

ResourceManager

ResourceManager

Database

Printer

AnotherApp

Applicationpre-commit

TransactionManager

ResourceManager

ResourceManager

ResourceManager

Database

Printer

AnotherApp

abort

Phase 1Phase 2

TLOG notready

ready

prepare/abort

ready/committed

notready

rolledback



Java Transaction API (JTA)

� WLS uses JTA 1.0.1 to implement and manage transactions.

� WLS JTA provides the following support:– creates unique transaction identifier (XID)

– supports optional transaction name– tracks objects involved in transaction– notifies databases of transaction– orchestrates 2PC using XA– executes rollbacks– executes automatic recovery procedures when failure– manages time-outs



Section Review

� What distributed transactions are

� The XA protocol

� Transaction and resource managers

� The two-phase commit protocol

� The Java Transaction API




Road Map

1. EJB Fundamentals



– JDBC Architecture

– Datasources and Connection Pools

– The Two-phase Commit Protocol




What Is JDBC?

� JDBC is an API for accessing databases in a uniform way.

� JDBC provides:– platform independent access to databases

– location transparency

– transparency to proprietary database issues

– support for both two-tier and multi-tier models for database access



� JDBC Drivers are implementation classes for database operations.

� Drivers fall into two categories:– 2-tier, where clients talk directly to a database

– 3-tier, where clients talk to a middle-tier (WLS) which delegates to a database

JDBC & JDBC Drivers

JavaApplication

JDBCDriver

WLS

JDBCDriver

Database

Database



JDBC Architecture

NetworkServer(WLS)

Native API(C, C++)

ODBCDriver

All JavaJDBC Driver

(Type 4)

JDBC-NetBridge

(Type 3)

JDBC-NativeBridge

(Type 2)

JDBC-ODBCBridge

(Type 1)

JDBC API

Java Application

RDBMS



Type 1 Driver

� The Type 1 driver:– is a JDBC-ODBC bridge & usually runs on Windows

– requires ODBC driver to be installed on client machine

ODBC Driver

Client

DBMS

JDBC-ODBC Bridge

JDBC API

Java App

ODBC-supportedNative Driver

Native program

Java program



Type 2 Drivers

� The Type 2 driver:– requires a native driver to be already installed on the

client machine

– the driver converts JDBC calls to native API calls of the database

JDBC-Native Bridge

Native Driver

Client

DBMS

JDBC API

Java App

Native program

Java program



Type 3 Drivers…

Java App

JDBC API

JDBC-Net Driver

Client[b]

DBMS[b]NetworkServerNetwork

Protocol

DatabaseProtocol[b]

DBMS[c]Database

Protocol[c]Client[c]

Client[a]

DBMS[a]Database

Protocol[a]

…



…Type 3 Drivers

� A network server can apply several techniques to boost performance:– load management

– caching

– pooling

getConnection()

Free Connection

Connection in Use

DBMS



Type 4 Drivers

� Type 4 drivers are ‘all-Java’ driver implementations that do not require client side configuration.

JDBC Driver

Client

DBMS

JDBC API

Java App



Two-Tier Architecture

� In the two-tier model a Java application communicates directly with the DBMS.

� A JDBC driver is needed that can communicate directly with the DBMS.

� This is a client/server configuration.

JDBC

Java Application

Client

DBMS - proprietaryprotocol

DBMS



Multi-Tier Architecture

� In the multi-tier model, commands are sent to a "middle tier" of services, which then sends the commands to the DBMS.

� The DBMS processes the commands and sends the results back to the middle tier, which then sends them to the client.

DBMS

JDBC

Java applet orHTML browser

Client

DBMS - proprietary protocol

Server

Application Server,Business Logic



WebLogic Server Two-Tier Drivers

� The following table shows the two-tier drivers for vendor specific platforms that WebLogic Server provides.

4Weblogic jDriver for Oracle

4Oracle Thin

4Sybase jConnect

4Pointbase (evaluation license)

4Weblogic jDriver for Microsoft SQL

Server

4Weblogic jDriver for Informix

TypeDriver



WebLogic Server Multi-Tier Drivers

� WebLogic Server provides three multi-tier drivers for vendor-neutral database access.

A server-side driver used in distributed transactions across multiple resource managers.

Weblogic JTS Driver

A type 3 driver that can be sued with any two-tier JDBC driver.Weblogic RMI Driver

Enables usage of connection pools from server-side applications such as HTTP Servlets or EJBS.

Weblogic Pool jDriver

DescriptionDriver



Choosing the Correct Driver

� Choosing the correct driver can have significant impact on performance.

� For two-tier applications use the type 1, 2 or 4 driver specific to the DBMS you are using.

� For multi-tier applications use:– the RMI driver (DataSources) in a client class

– a type 1, 2 or 4 driver on the server, specific to the DBMS you are using

– the JTS or Oracle XA driver in EJB or where transaction support is required



Accessing DB Directly with JDBC

� Accessing databases directly consists of:– loading the JDBC driver class

– getting and using a connection from the driver

1001011110

Example of connecting to a database directly:import java.sql.*;...Try{

Statement stmt = con.createStatement();String sql = "SELECT * FROM MYTABLE";ResultSet res = stmt.executeQuery(sql);while(res.next()){

String col1 = res.getString("MYCOLUMN1");int col2 = res.getInt("MYCOLUMN2");

}}catch(Exception e){...}}

Class.forName("COM.cloudscape.core.JDBCDriver");Connection con = DriverManager.getConnection(

"jdbc:cloudscape:c:\data\MyDatabase");



Connection Pools

� Connection pools:– are administered objects that manage database

connections

– are configured with the Administration Console

– provide connection sharing, security etc.

Application ServerConnection Pool

JavaApplication

��

ConnectionAvailable

ConnectionIn Use Database



Data Sources

� Data Sources are:– administered factory objects that provide connections

from connection pools

– bound into JNDI and configured using the Administration Console

Application ServerConnection Pool

JavaApplication

JNDI

Data Source Connection

Database

33

22

11 lookup

getConnection

Use like regular JDBC connection



Create Connection Pools

99

33

22

11

55

66

77

88

44



Target Connection Pool

44

33

22

11



Create & Configure Data Sources

66

55

44

33

22

11

88

77



Using Data Sources to Access DB

� To use Data Sources:– look it up in JNDI

– get a connection from Data Source

– use connection as a regular connection

� Here is a JSP that prints the content of a table:



A JSP That Prints Content of Table

Example of using a Data Source to connect to a database:<TABLE><% try {

InitialContext ic = new InitialContext();DataSource ds = (DataSource)ic.lookup("jdbc/BugDs");Connection c = ds.getConnection();Statement s = c.createStatement();ResultSet rs = s.executeQuery("select * from BUGS");ResultSetMetaData md = rs.getMetaData();int colCount = md.getColumnCount();%><TR BGCOLOR=DDDDDD ALIGN=CENTER>

<% for(int j=1; j<colCount; j++){%><TD><FONT FACE=Verdana SIZE=-1><B><%=md.getColumnName(j)%></TD>

<% }%></TR>

<% while(rs.next()){%> <TR BGCOLOR=EEEEEE ALIGN=CENTER><% for(int j=1; j<colCount; j++){%>

<TD><FONT FACE=Verdana SIZE=-1><%=rs.getString(j)%></TD>

<% }%></TR>

<% }}catch(Exception e){System.out.println(e);}%>

</TABLE>1001011110



Section Review

� Creating & configuring JDBC connection pools

� Creating & configuring JDBC DataSources

� Using DataSources in a database client code




Road Map

1. EJB Fundamentals




– Introduction to Message-Oriented Middleware

– Introduction to JMS



What Is Messaging?

� Messaging is a mechanism that allows programs to communicate with one another.

� There are many messaging technologies:– TCP/IP sockets

– pipes

– files

– shared memory

Message

Program Program



Message-Oriented Middleware

� Message-oriented middleware is used to refer to an infrastructure that supports messaging.

� Typical message-oriented middleware architectures define:– message structure

– how to send/receive messages

– scaling guidelines



Benefits of Msg-Oriented Middleware

� Message-oriented middleware architectures provide many benefits:– multi-protocol, multi-platform support

– user-defined message types

– guaranteed message delivery (GMD)

– load-balancing of messages

– fault tolerance of messaging servers

– cross-platform support

– GUI-based configuration and management

– reduced risk



Types of Msg-Oriented Middleware

� Message-oriented middleware software falls into categories that define which client receives a message.

� WLS-supported categories:– Point-to-Point (PTP)

– Publish-Subscribe (Pub/Sub)

Msg-OrientedMiddleware

Consumer 1

Consumer 2

Consumer 3

Message

Sender



The Point-to-Point Domain

� The PTP domain allows one client (called a producer) to send messages to another client (called a receiver).

One-Way Relationship

Two-Way Relationship

Message

Message

Program Program

ProgramProgram



Queue Manager (Msg-Oriented Middleware

Server)

PTP Queues

� Many producers can serialize messages to multiple receivers in a queue.

Distribution Queue

456789

Consumer 1

Consumer 2

Consumer 3

Message

Message

Message 2

Message 1

Message 3

Messages are deliveredto a single client

Producer

Producer



The Publish/Subscribe Domain

� Message producers (called publishers), disseminate data to multiple consumers (called subscribers).

Message

Message

Subscriber 1Message

Subscriber 2

Subscriber 3

Publisher



Topic Manager (Msg-Oriented Middleware

Server)

Pub/Sub Topics

� Publishing and subscribing to a topic decouples producers from consumers.

Topic

1

1

1

2

2

2

3

3

3

Subscriber 1

Subscriber 1

Subscriber 1

Message

Message

Publisher

Publisher

456789



Durable Subscribers and Subscriptions

� Subscribers can be made durable by having the messaging service persist messages to guarantee delivery.

� Durable subscribers register a durable subscription with JMS service using an ID.

� This ID can then be used to retrieve missed messages.

JMSClient

JMSProvider

Publishesto a topic

JMSClient

Backing Store

If client subscriber notactive: message is persistedfor later redelivery

If client subscriberis active: Message

is delivered



What Is Java Messaging Service (JMS)?

� JMS consists of a set of interfaces that determine how clients access a messaging service.

� A messaging service allows its clients to exchange messages efficiently and reliably.

� A message is a structured asynchronous communication between two programs.



What Does JMS Provide?

� JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.

� JMS supports:– the PTP domain

– the Pub/Sub domain

http://java.sun.com/products/jms/index.htmlhttp://java.sun.com/products/jms/index.html



What Is a JMS Application?

� A JMS Application consists of:– JMS clients

– messages

– JMS provider

– administered objects

JMS Client Destination and ConnectionFactory

Objects

Msg-OrientedMiddleware

AdministeredObjects

JMS Implementation



Administrative Tasks

� Administrative tasks consist of:– creating connection factories

– creating and monitoring JMS servers

– creating and monitoring JMS destinations

– creating various JMS stores

– configuring thresholds and quotas

– configuring durable subscriptions



Section Review

� The purpose of messaging

� The role and benefits of message-oriented middleware

� Different message-oriented middleware domains (PTP, pub/sub, RR)




Module Review

� EJB fundamentals

� Transaction fundamentals

� JDBC fundamentals

� JMS and MOM fundamentals

In this module we discussed:


Documents

26 - Theory and Fundamentals - Slide