Enterprise JavaBeans - Architecture and Goals

7/28/2019 Enterprise JavaBeans - Architecture and Goals

1/46

Lecture 7

Enterprise JavaBeans:

Architecture and Goals


2/46

What are Enterprise JavaBeans

EJB is a semi-automated server-side component management architecture that facilitates

the deployment of enterprise-class distributed object applications in Java.

server-side

highly-available enterprise (24x7)

components

encapsulated (self-contained) portability

object model (inheritance, polymorphism, interface/implementation

disjunction)

reusability

automated management

Persistence (distributed 2-Phase Commit Transactions)

Security

Load balanced/fault tolerant

deployment

enterprise distributed object applications

Java language


3/46

Foundations

EBJ Technology is built on other key J2EE and OMG

foundations:

RMI objects

JNDI naming and location

Does for Novells NDS and LDAP access what JDBC did

for Sybase and Oracle DBMS acccess

Remote method exposure

JDBC

JTS/JTA

CORBA IIOP


4/46

Whats J2EE all about?

J2EE is a specification

Vendor independent

Platform independent (portable)API consistency

Test suite

Reference implementation


5/46

J2EE Technologies

(EJB as a canton in a larger confederacy)

RMI and RMI-IIOP

Java Naming and Directory Interface (JNDI)

JDBC

Java Transaction API (JTA) and Java Transaction Service(JTS)

Java Messaging Service (JMS)

Java Servlet API (JSDK)

Java Server Pages (JSP)

Java IDL (CORBA)

JavaMail API

Extensible Markup Language (XML)

Enterprise Java Beans (EJB)


6/46

Stated Goals of EJB

The EJB architecture will be the standard component

architecture for building distributed object-oriented

business applications in the Java Programming Language.

Sun EJB Specification 1.1

Application developers will not have to understand low-

level transaction and state management details, multi-

threading, connection pooling and other complex low-level

APIs. ibid.

EJBs will follow the Write Once, Run Anywherephilosophy of the Java Programming Language. An EJB

can be developed once, and then deployed on multiple

platforms without recompilation or source code

modification. ibid.


7/46

Stated Goals of EJB

The EJB architecture will address thedevelopment, deployment, and runtime aspects ofan enterprise applications life cycle. ibid.

The EJB architecture will provideinteroperability between enterprise Beans andnon-Java programming language applications.ibid.

The EJB architecture will be compatible with theCORBA protocols. ibid.


8/46

What benefits does the EJB

Architecture Provide? Component Transaction Monitor

Distributed Transaction/2 Phase monitoring

Generic Naming and Implicit component location

clients do not have to know the specific

location of a component to use it

Security

Automated User Authentication via AccessControl Lists


9/46

What benefits does the EJB

Architecture Provide? Persistence

Implicit persisting, activation and deactivation

Implicit component life cycle management

Implicit distributed transaction management Distributed 2-Phase commit

(Begin,End,Commit,Rollback)

Load Balancing/Transparent Failover

Resource Pooling Multi-client support

Metadata Management

Declarative Specification


10/46

Server Architecture


11/46

Client-Server Interaction


12/46

Component Characteristics

An enterprise bean contains business logic thatoperates on the enterprises data.

An enterprise beans instances are created and

managed at runtime by a Container. An enterprise bean can be customized by the

customer at deployment time by editing thebeans metadata

Client access is indirect--it always is via theContainer

The EJB can be deployed in any compliantContainer


13/46

EJB Topology

An EJB may implement:

an object that represents a stateless (highly available)

service

a calculation algorithm (insurance, finance, trading,etc.)

a lookup service

a security manager that validates a user and returns a

token pooled resource

Stateless Session Bean


14/46


15/46

EJB Topology


a high-level abstraction that represents a

business entity that encapsulates business state

and is accessible by multiple clients a Customer object

a Contract object in futures trading

a Policy object in insuranceEntity Bean


16/46

EJB Topology


a middleware observer that listens for certain

events in the system, and acts as a consumer of

events it is interested in a logger object

a trade validator object in futures trading

a claim processor object in insuranceMessage-Driven Bean


17/46

Session Objects

execute some business logic on behalf of a singleclient

can be transaction enabled

does not directly represent data in a database, butcan access one

are generally short-lived

are removed when the Container crashes (client

must reconnect) participate in a Containers scalable runtime

environment, executing concurrently with multipleinstances


18/46

Entity Objects

provide a class (object-encapsulated) view

of data in a database

allow keyed, shared access from multiple

simultaneous clients

are generally long-lived

along with their primary keys and remotereferences survive the crash of the

Container


19/46

Implementing an EJB Object

HomeInterface

The Clients way of creating a local reference

to a server

Defines a single create() method

RemoteInterface (think CORBA IDL)

This interface defines the client semantics for

the beanHere is where you declare the methods your

bean will implement


20/46


Bean Implementation (think CORBA Impl)

Here is where you implementthe methods in

the RemoteInterface.

Similar to a CORBA implementation

implementing an IDL interface, the Bean

implementation implements theRemote

Interfaces declared methods.


21/46


The Bean implementation also defines callbackmethods that the Container will use tocommunicate with the bean. These include:

ejbPassivate()ejbActivate()

ejbCreate()

ejbRemove()

ejbLoad(): entity

ejbStore(): entity

ejbFindByPrimaryKey(Primary key): entity


22/46

General Security

2 Levels of security that clients must pass in EJB:

client authentication

verifies the client is indeed whom he claims to be

username/password authentication

after authentication, given a security identity for therest of the session

client authorization

grants permission to a security identity to perform

certain operations occurs during an EJB method call

supports both declarative (container-based) andprogrammatic authorization


23/46

General Security

Security Roles

Security Roles are collections of client

identities, such as general user, privileged

user, system administrator, etc.Every Security Role can be assigned method

permissions, which grant certain roles the rights

to access some defined group of methods on a

home or remote interface

Roles are defined in the deployment descriptor


24/46

General Security

Declarative Authorization (in deploymentdescriptor)

modifySystemProperties [administrator]

searchData [everyone] Programmatic Authorization (based on

java.security.Principal and SessionContext)

isCallerInRole(securityRole) - checks to see

that the current user (per the EntityContext) is amember of a role

getCallerPrincipal() - returns the secure nameof the client user


25/46

Session Bean Persistence

Stateful Session Bean Passivation and Activation

Since Stateful SessionBeans cannot be sharedbut are client-specific, their resources are

limited and can, under load, be persisted topermanent storage and later recalled intomemory

Passivation is the process whereby a stateful

session beans non-transient conversationalstate is serialized to permanent storage. Afterthe container has passivated the state,ejbPassivate() is called to allow the Bean torelease any database or socket connections, etc.


26/46

Session Bean Persistence

Stateful Session Bean Passivation and Activation

Activation is the process where the persisted

state of a bean is deserialized due to client

access on the persisted bean. The state isrestored and ejbActivate() is called to notify the

bean that it should re-establish connections,

handles, etc.

Passivation is performed according to a Least

Recently Used (LRU) strategy. The bean

whose last client access was farthest back in

time is the first to be passivated.


27/46

Container-Managed Persistence

The container implicitly performs all

database operations on behalf of the CMP

entity bean

Primary Key class must be serializable

Object-Relational database mapping is done

declaratively in the deployment descriptor

Programmer generally writes little if any

direct JDBC connection code (but is free to

if he wishes)


28/46

Container-Managed Persistence

finder functions are described in the deploymentdescriptor (ejb-jar.xml):

findAccount

double

>


29/46

Entity Bean Persistence

Bean-Managed Persistence

Bean developer, not the container, provides all

data access logic

Developer implements callbacks such asejbFind(), ejbCreate(), ejbActivate(),

ejbLoad(), ejbStore(), ejbPassivate(),

ejbRemove()

Developer uses JDBC or SQL/J to interact with

the database


30/46

Distributed Transaction Support

JDBC provides default non-distributed

transaction support with autocommit

This is insufficient when dealing with

distributed components which may

severally be involved in a single transaction

ACID Properties (Atomic, Consistent,

Isolated, Durable)


31/46


Only flat transactions are supported currently inEJB, not nested transactions

Multiple database can be updated automatically ina single transaction

Transactions can be handled either declaratively orprogrammatically

Programmatically handled requires programmer

to issue Begin, End, Commit, RollbackDeclaratively handled requires the EJBObject

(container) to issue transaction boundaries onbehalf of the implementation


32/46


EJB Transaction Attribute Values (set in Deployment Descriptor):

TX_BEAN_MANAGED: bean is programmatically handling all

transaction boundaries

TXN_NOT_SUPPORTED: bean operates outside of any particular

transactional context TXN_REQUIRED: bean must always run within the context of a

transaction

TXN_REQUIRES_NEW: bean must always have its own new

transaction created, current transaction, if any, is suspended

TXN_SUPPORTS: bean only runs in a transaction if one is alreadypresent

TXN_MANDATORY: bean must run in a transaction, and that

transaction must already be present and active

(javax.ejb.TransactionRequired exception)


33/46


EJB Isolation Levels (set in Deployment Descriptor)

TRANSACTION_READ_UNCOMMITTED (no

protection from dirty reads, repeatable reads, etc.)

TRANSACTION_READ_COMMITED (eliminates

dirty reads, reading uncommited data)

TRANSACTION_REPEATABLE_READ (eliminates

changing data during updates)

TRANSACTION_SERIALIZABLE (eliminates dirty

reads, unrepeatable reads, and phantom (new) reads)


34/46

Resource Management/Load Balancing

Mechanisms Instance pooling in EJB Servers reduces the number of

component instances needed overall, by allowing clientsto share components individually or collectively

Pooling also reduces the frequency of component creationand removal

Each instance of a component in a pool is equivalent, butsome may have higher priority due to access algorithms(LRU, Round-Robin)

New instances can be created and added to the pool, andother instances can be checked in and out for usage by

clients Pool management is handled intelligently by the container

Database ConnectionPools are supported and user-defined


35/46

Resource Management/Load Balancing

Mechanisms

EJB Servers/Containers provide Instance Swapping

Stateless SessionBeans can easily be swapped for

client access because they maintain no client-specific

state, they are truly equivalent, and one will work aswell as another

Entity beans can also be swapped through the

interaction of the container and the setEntityContext()

and unsetEntityContext() methods

EJB Servers/Containers provide management through

activation and passivation


36/46

Failover Management

Stateless Session Beans: On failure, bean is

automatically reinstantiated in a different server

process

Stateful Session Beans: On failure, manual

reconfiguration on another machine is required

Entity Beans: On failure, Client application reacts

to RemoteException by reinvokingfindByPrimaryKey, which will automatically

map to other supporting groups


37/46

Metadata Management

Deployment Descriptors allow EJB

containers to supply run-time middleware

services (persistence, transaction, security,

etc.) to a generic EJB, thus relieving theEJB from having to hard-code this support

into the bean itself

Entries in a Deployment Descriptorcumulatively make up the beans metadata


38/46

Metadata Management

A beans metadata may also include bean-specificproperties that are become Java properties, that areavailable to a bean at runtime

With EJB 1.0, you had to write a single deployment

descriptor for each bean, and that DD had to be aserializable Java class, based on a plain text filedescription, and a manifest file was needed to describe allthe deployment descriptors in an ejb-jar file

With EJB 1.1, you need only write a single deployment

descriptor for each ejb-jar file, and this descriptor iswritten in XML. Since there is now only one deploymentdescriptor, manifest files are no longer needed


39/46

Deployment Description Overview

Specify Home Interface

Specify Remote Interface

Specify Bean implementation class Specify Bean type (session or entity)

Specify the JNDI name for the home

interface for Clients to use Transaction support definition


40/46

Deployment Description Overview

Transaction isolation level definition

Access Control Lists (ACLs) and attributes

Session Timeout (session beans only) Database member-Class attribute mapping

(container-managed entity beans only)

Reentrancy information (entity beans only) Primary Key class (entity beans only)

Environment specifics


41/46

Abstracting Capabilities of the

Container Multithreading

Resource Pooling

Scaling

Distributed naming and location Container is responsible for make the home interfaces

of its deployed beans available via JNDI

Automatic persistence

Bean-Managed Persistence Container-Managed Persistence

Transaction handling

Distributed Transaction Management


42/46

Responsibilities of the Container for

Session Beans Making the home interfaces of deployed beans

available via JNDI

Implementing the home interface of each installedEJB (EJBHome)

home interface allows a client to create a newsession object (factory method)

home interface allows for the removal of asession object

Implementing the remote interface of eachinstalled EJB (EJBObject)

remote interface allows clients to makebusiness method calls on a session objects


43/46


Session Beans Implementing Handle (support) classes for the

Home and Remote interfaces

Implementing the EJBMetaData class

Must ensure that only one thread can be executingan instance at any time (session objects are

serialized, single-client servants)


44/46


Entity Beans Making the home interfaces of deployed beans

available via JNDI

Implementing the home interface of each installedEJB (EJBHome)

home interface allows a client to create a newsession object (factory method)

home interface allows for the removal of asession object

Implementing the remote interface of eachinstalled EJB (EJBObject)

remote interface allows clients to makebusiness method calls on a session objects


45/46


Entity Beans Implementing Handle (support) classes for

the Home and Remote interfaces

Implementing the EJBMetaData class

Must ensure that reentrant rules arefollowed (intra-transactional legal loopback,illegal concurrent call)

Implementation of robust (long-lived)object references. A client should be able touse an object reference across a server crashand restart


46/46

BEA Weblogic Enterprise

(WLE) WLE combines an ORB and OLTP functionality within ATMI (Application-

to-Transaction Manager Interface), CORBA and EJB

CORBA and EJB objects share the same transaction, security, configuration,

and monitoring infrastructure

Native IIOP communication between RMI, EJB, CORBA Java/C++, and

Tuxedo ATMI (Xopen XATMI compliant) WLE Domain Offerings:

CORBA

EJB

ATMI

Security

TP Monitor

Web Server & Servlet Engine

RMI

HTML/JSP

Documents

Enterprise JavaBeans - Architecture and Goals