Enterprise Java Beans

Enterprise Java Beans

Objectives • • • •

Three Tiered Architecture Why EJB? What all we should know? EJB Fundamentals

Three Tiered Architecture

Introduction •

Distributed three-tier design is needed for






•

Increased performance Flexibility Maintainability Reusability Scalability

while hiding the complexity of distributed processing from the user.

Standard Three Tiered

Client Tier

Middle Tier

File System Storage

Web Client

GUI Client

Other Client

Data Tier

Middle Tier Server

Other Legacy Storage

Database Storage

Middle-Tier Houses • • • • •

Business Logic/Rules Resource access management (database connection pooling) Remote access between clients and data sources Session and transaction management Security management

J2EE Three Tiered

Client Tier

Middle Tier J2EE Server

Web Client

EJB Container

Data Tier File System Storage

EJB

GUI Client

EJB

Other Legacy Storage

WEB Container Servlet

Other Client

JSP

Database Storage

J2EE Middle-Tier • •

In J2EE scenario middle-tier is always a J2EE App Server It has two containers





EJB Container • For deploying EJB components Web Container • For deploying WEB components

Why EJB?

Answer the Question

Reasons… • • •

Business-Logic Extensibility Scalability

Business-Logic • •

It is not harmful considering performance and security Tradeoffs in writing business-logic in servlet





Servlet holds presentation-logic so manageability is difficult It supports only web-clients

Extensibility

Client

HTML, JSP, Servlet

Java Beans, Session Beans, Message Driven Beans

DAO, Entity Beans, Hibernate

Presentation

Business Logic

Integration

J2EE Scenario

External Resources

Extensibility • • • •

The application is loosely coupled Presentation, Business Logic and Integration is independent of each other Changes if needed in either of this will not affect other parts of the application Above all the Scalability advantage

Scalability Web-Client

Swing-Client

Application Server

xml-Client J2ME-Client

What All We Should Know?

What all we should know? • • • • •

Application server Containers Implicit Services Other auxiliary systems EJB clients

Application Server •

•

A Java application server provides an optimized execution environment for serverside Java application components. Java application server delivers a highperformance, highly scalable, robust execution environment to support distributed application.

Cont… •

•

An application server automates some of the more complex features of multi-tier computing. An application server manages system resources, such as processes, threads, memory, database connections, and network sessions on behalf of the application

Cont… •

•

An application server also provides access to infrastructure services, such as naming, directory, transaction, persistence and security. Some of the more sophisticated application servers offer load-balancing services that can distribute application processing across multiple systems.

Container • •

•

Components execute within a construct called a container. A container provides an application context for one or more components and provides management and control services. Server components are non-visual and execute within a container that is provided by an application server.

Cont… • •

•

AS provides a container to manage the execution of a component. Container automatically allocates a thread and initiates the component, when client invokes a component. The container manages all resources on behalf of the component and manages all interactions between the component and client.

Types of Containers •

The two types of containers are





Session containers • Transient, Non-persistent EJBs whose states are not saved at all Entity containers • Persistent EJBs whose states are saved between invocations

Implicit Services •

The EJB model supports a number of implicit services

•

Lifecycle: Individual enterprise beans do not need to explicitly manage process allocation, thread management, object activation, or object destruction.

Cont… •

•

State Management: Individual enterprise beans do not need to explicitly save or restore conversational object state between method calls. Security: Individual enterprise beans do not need to explicitly authenticate users or check authorization levels.

Cont… •

•

Transactions: Individual enterprise beans do not need to explicitly specify transaction demarcation code to participate in distributed transactions. Persistence: Individual enterprise beans do not need to explicitly retrieve or store persistent object data from a database.

Other Auxiliary Systems • •

Java Naming and Directory Interface Java Transaction API

JNDI •

The container is responsible for making its deployed enterprise beans available to the client through JNDI. Thus, the client can look up the home interface for a specific enterprise bean using JNDI.

JTA •

•

The JTA is a specification of the interfaces between a transaction manager and the other parties involved in a distributed transaction processing system. The EJB architecture requires that the EJB container support the JTA API and the Connector APIs

EJB Client • •

•

These make use of the EJB Beans for their operations They find the EJB container that contains the bean through the Java Naming and Directory (JNDI) interface They then make use of the EJB Container to invoke EJB Bean methods

EJB Fundamentals

The Basics

EJB Fundamentals • • • • • • •

What is an EJB? Types of EJB Session Bean Entity Bean Message Driver Bean Passivation / Activation Deployment Descriptor

What is EJB? •

Enterprise JavaBeans™ (EJB) technology defines a model for the development and deployment of reusable Java™ server components.

•

Components are pre-developed pieces of application code that can be assembled into working application systems.

Cont… •

The EJB architecture logically extends the JavaBeans component model to support server components.

•

Server components are application components that run in an application server.

Types of EJBs • •

There are three types of EJBs They are




Session Beans Entity Beans Message Driven Beans

Session Bean • •

• •

Each Session Bean is usually associated with one EJB Client Each Session Bean is created and destroyed by the particular EJB Client that it is associated with A Session Bean can either have states or they can be stateless However, Session Beans do not survive a System shutdown

Types of Session Bean • •

There are two types of Session Beans They are



Stateless Session Beans Stateful Session Beans

Stateless Session Bean •

•

These types of EJBs have no internal state. Since they do not have any states, they need not be passivated Because of the fact that they are stateless, they can be pooled in to service multiple clients

Stateful Session Bean •

• • •

These types of EJBs possess internal states. Hence they need to handle Activation and Passivation However, there can be only one Stateful Session Bean per EJB Client. Since they can be persisted, they are also called Persistent Session Beans These types of EJBs can be saved and restored across client sessions

Entity Bean • • •

Entity Beans always have states Their states can be persisted and stored across multiple invocations Hence they can survive System Shutdowns

Entity Bean Persistence • •

Persistence in Entity Beans is of two types. They are



Container-managed persistence Bean-managed persistence

Container Managed • •

•

Here, the EJB container is responsible for saving the Bean's state Since it is container-managed, the implementation is independent of the data source The container-managed fields need to be specified in the Deployment Descriptor and the persistence is automatically handled by the container

Bean Managed • • •

Here, the Entity Bean is directly responsible for saving its own state The container does not need to generate any database calls Hence the implementation is less adaptable than the previous one as the persistence needs to be hard-coded into the bean

Message Driven Bean • •

• •

A message-driven bean is an asynchronous message consumer To a client, a MDB is a message consumer that implements some business logic running on the server MDBs are anonymous, they have no clientvisible identity Message-driven bean instances have no conversational state

Passivation /Activation • •

• •

EJB servers have a right to manage their working set Passivation is the process by which the state of a Bean is saved to persistent storage and then is swapped out Activation is the process by which the state of a Bean is restored by swapping it in from persistent storage Passivation and Activation apply to both Session and Entity Beans

Deployment Descriptor • •

•

Deployment Descriptor are serialized instances of a class They are used to pass information about an EJBs preferences and deployment needs to its container The EJB developer is responsible for creating a deployment descriptor along with his/her bean

Points to ponder…

EJB • EJB is a component-based development model • Components are reusable chunks of

functionality • One benefit of EJB is WODA. • You can deploy your EJB 2.0 component to any AS that’s EJB 2.0 compliant

cont… • WODA means you have to learn only one,

standard API rather than proprietary vendor specific APIs • The EJB architecture gives container a chance to step-in and add services • EJB services include transaction, security, resource management, networking, and persistence

Flavours •

Beans come in three flavours




Entity Session Message-Driven

Entity •

• • •

Entity beans represent a uniquely identifiable thing in a persistent store; usually that means a row in a database table As entity bean represents a thing When you think of Entity bean think “noun” An Entity bean IS something

Session • • • • •

Session beans are… everything else Almost any kind of back-end services can and often should begin with a this bean A session bean typically represents a process When you think of a Session bean think “verb” A Session bean DOES something

Message-Driven • • •

Only when you need a JMS consumer A bean that can listen for messages from a JMS messaging service Client never call a message-driven bean directly, in order to get a message –driven bean to do something, a client must send a message to a messaging service

What all is needed? •

for writing an Enterprise Bean




Bean Class Component Interface Home Interface

Bean Class •

Class that implements the Bean



• • •

SessionBean interface EntityBean interface

Writes implementation for methods Holds business logic methods And a create method

Component Interface • •

Interface that extends EJBObject Interface that list the business logic methods

Home Interface • •

Interface that extends EJBHome Interface that provides list of create methods

Coding Time…

Lets try a Stateless Session Bean

javax.ejb.SessionBean • • • •

void void void void

ejbActivate() ejbPassivate() ejbRemove() setSessionContext(SessionContext)

CurrencyConverterBean-Code EJB API Package package com.converter; import javax.ejb.*;

As the class is a SessionBean

public class CurrencyConverterBean implements SessionBean { public double convert (double dollars) { return dollars * 44.50; } The Business The create method Logic Method public void ejbCreate () {} public void ejbActivate () {} Interface method’s blank implementation}

public void ejbPassivate () {} public void ejbRemove () {} public void setSessionContext (SessionContext sc) {}

Question? •

Who implements the Component interface?

•

Why the business method is implemented by Bean class as it is not implementing component interface?

•

What create method is doing here?

CurrencyConverter-Code

package com.converter; import javax.ejb.*; import java.rmi.*;

Interface that extends Remote; is extended by the component interface

public interface CurrencyConverter extends EJBObject { public double convert (double dollars) throws RemoteException; } Every BL method must throw this exception

The businesslogic method

Questions? •

Why component interface should extends to EJBObject?

•

Why BL methods must throw RemoteException?

CurrencyConverterHome-Code

package com.converter;

Interface that is extended by the home interface

import javax.ejb.*; import java.rmi.*; public interface CurrencyConverterHome extends EJBHome { public CurrencyConverter create () throws CreateException, RemoteException; } Every create method must throw this exception

The create method

Questions? •

Why create method is needed?

•

Why the interface should extends to EJBHome?

•

Why create method must throw CreateException?

How client gets the bean?

Zubair-o-Scope

Client lookup for Home JNDI

Client Home Object

Client Side JVM

EJB Container

Client gets Home stub JNDI

Client Home stub

Client Side JVM

Home Object

EJB Container

Client calls create on stub

Client Home stub

Client Side JVM

Home Object

EJB Container

Container makes EJB Object

EJB Object

Client Home stub

Client Side JVM

Home Object

EJB Container

Container send the stub

Client

EJB Object stub

Home Object stub

Client Side JVM

EJB Object

Home Object

EJB Container

No bean in the container!!! • • • •

Bean creation is not related to the client Container may have a “Bean Pool” or he may create on clients request So far no request is made by the client for the business method on bean Isn’t It?

How bean is created?

Zubair-o-Scope

Container… • • •

constructs the Session Context object constructs the bean instance calls setSessionContext() on the bean by passing the SessionContext object

Construction of objects

Bean Pool

Session Context

EJB Container

Gives SessionContext to bean

Bean Pool

Session Context

EJB Container

Taking bean from pool

EJB Object

Bean Pool

Session Context

EJB Container

Serving to the client

EJB Object

Bean Pool

EJB Object stub

Client

Session Context

Client Side JVM EJB Container

Object interaction diagram Client

EJB Object

Home Object

create() new

new New (bean constructor runs) setSessionContext() ejbCreate()

Session Context

Stateful Session Bean

The Stateful Transitions Bean does not exist

constructor setSessionContext() ejbCreate()

ejbRemove() or timeout timeout ZZZZZZ

Method calls

ejbPassivate()

method ready

ejbActivate()

passivated

Entity Beans

What Entity Bean represents? • • •

Entities are persistent Map to a relational database row It can represent…




Employee Customer Account Holder

for an example… empid: 243 ename: Zubair sal: 5500

Employee Table empid

ename

salary

234

Zubair

5500

435

Nilesh

8750

653

Advait

7500 empid: 435 ename: Nilesh sal: 8750

empid: 653 ename: Advait sal: 7500

Getting Entity Bean •

There are several ways to get the Entity bean





Create a Bean • Using create methods Find a Bean • Using finder methods

Creating bean • • •

You can create a bean by calling create() on Home Stub In this case you’ll get a new bean with every create() method And a new record will be added to your database table

Finding Bean • • • • •

You may don’t want to create a new record always Sometimes you may wish to work with the existing records In such a scenario you can avail of a bean by calling findByMethods() It may use a bean from the pool If not then give you a new bean

Creating Entity Bean

Zubair-o-Scope

create() way Bean Pool

Client Home Object Home Object stub

EJB Container Client Side JVM DB

Asking pool for a bean Bean Pool

Client Home Object Home Object stub

EJB Container Client Side JVM DB

Pool creating bean & context Bean Pool

Context

Client Home Object Home Object stub

EJB Container Client Side JVM DB

Associating them with data Bean Pool

Context

Client Home Object Home Object stub

EJB Container Client Side JVM DB

Taking bean from pool Bean Pool Context

Home Object Client EJB Container Client Side JVM DB

Creating EJBObject EJB Object

Bean Pool Context

Home Object Client EJB Container Client Side JVM DB

Returns EJBObject EJB Object

Bean Pool Context

EJB Object stub

Home Object Client EJB Container Client Side JVM DB

Finding Entity Bean

Zubair-o-Scope

findByMethod() way Bean Pool Context

Client

Context

Home Object Home Object stub

EJB Container Client Side JVM DB

Looking for bean in Pool Bean Pool Context

Client

Context

Home Object Home Object stub

EJB Container Client Side JVM DB

Taking bean from the pool Bean Pool Context

Context

Home Object Client EJB Container Client Side JVM DB

Mapping it with data Bean Pool Context

Context

Home Object Client EJB Container Client Side JVM DB

Creating EJBObject Bean Pool

EJB Object

Context Context

Home Object Client EJB Container Client Side JVM DB

Returns EJBObject Bean Pool

EJB Object

Context Context

EJB Object stub

Home Object Client EJB Container Client Side JVM DB

Help Me? •

•

•

Is there someway; where I’ll work on object relationship and table and their relationship should get created automatically? Is there any possibility where two different clients working on the same record without locking it? Can I have a bean who takes care of database, so that I can concentrate only on the BL

Answer to all questions…

In entity bean • •

I may wish to have bean object relationships but… Relationships are of types like…




•

One to One One to Many Many to Many

Being a Java programmer I can achieve this with objects

Cont… •

But how I can make it work successfully among database tables?

•

Guess the answer???

Um… •

“Leave it on container”

•

Isn’t that simple So, lets write bean without bothering about the database, tables, and relationships

•

Thank You

Zubair Shaikh [email protected] Presentation Version 2.0