enterprise javabeans - architecture and goals

Session Objects• execute some business logic on behalf of a single client • can be transaction enabled • does not directly represent data in a database, but can access one • are generall

Lecture 7

Enterprise JavaBeans: Architecture and Goals

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

• EBJ Technology is built on other key J2EE and OMG

foundations:

– RMI objects

• JNDI naming and location

– Does for Novell’s NDS and LDAP access what JDBC did for Sybase and Oracle DBMS acccess

• Remote method exposure – JDBC

– JTS/JTA

What’s J2EE all about?

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

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 level transaction and state management details, multi-

low-threading, connection pooling and other complex low-level

APIs.” ibid.

• “EJBs will follow the Write Once, Run Anywhere

philosophy of the Java Programming Language An EJB can be developed once, and then deployed on multiple

platforms without recompilation or source code

modification.” ibid.

Stated Goals of EJB

• “The EJB architecture will address the

development, deployment, and runtime aspects of

an enterprise application’s life cycle.” ibid.

• “The EJB architecture will provide

interoperability between enterprise Beans and

non-Java programming language applications.”

ibid.

• “The EJB architecture will be compatible with the

CORBA protocols.” ibid.

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 Access Control Lists

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

Server Architecture

Client-Server Interaction

• Client access is indirect it always is via the

Container

• The EJB can be deployed in any compliant

Container

EJB Topology

• An EJB may implement:

– an object that represents a stateless (highly available) service

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

EJB Topology

• An EJB may implement:

– an object that represents a conversational session with a particular client (contradistinguished from HTTP

protocol)

• Extension of client business functionality on the server side

– avoids Fat clients and 2-tier scenarios

• Typically will handle database operations on behalf

EJB Topology

• An EJB may implement:

– 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 insurance

• Entity Bean

EJB Topology

• An EJB may implement:

– 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 insurance

• Message-Driven Bean

Session Objects

• execute some business logic on behalf of a single client

• can be transaction enabled

• does not directly represent data in a database, but can access one

• are generally short-lived

• are removed when the Container crashes (client

must reconnect)

• participate in a Container’s scalable runtime

• are generally long-lived

• along with their primary keys and remote references survive the crash of the

Container

Implementing an EJB Object

• Home Interface

– The Client’s way of creating a local reference

to a server

– Defines a single create(…) method

• Remote Interface (think CORBA IDL)

– This interface defines the client semantics for the bean

– Here is where you declare the methods your

Implementing an EJB Object

• Bean Implementation (think CORBA Impl)

– Here is where you implement the methods in the Remote Interface

– Similar to a CORBA implementation

implementing an IDL interface, the Bean

implementation implements the Remote

Interface’s declared methods.

Implementing an EJB Object

• The Bean implementation also defines callback methods that the Container will use to

communicate with the bean These include:

• occurs during an EJB method call

• supports both declarative (container-based) and programmatic authorization

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

• Programmatic Authorization (based on

java.security.Principal and SessionContext)

– isCallerInRole(securityRole) - checks to see

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

– getCallerPrincipal() - returns the secure name

of the client user

Session Bean Persistence

• Stateful Session Bean Passivation and Activation

– Since Stateful SessionBeans cannot be shared but are client-specific, their resources are

limited and can, under load, be persisted to

permanent storage and later recalled into

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 is

restored 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

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

Entity Bean Persistence

• Bean-Managed Persistence

– Bean developer, not the container, provides all data access logic

– Developer implements callbacks such as

ejbFind…(), ejbCreate(), ejbActivate(),

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

ejbRemove()

– Developer uses JDBC or SQL/J to interact with the database

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)

Distributed Transaction Support

• Only flat transactions are supported currently in

EJB, not nested transactions

• Multiple database can be updated automatically in

a single transaction

• Transactions can be handled either declaratively or programmatically

– Programmatically handled requires programmer

to issue Begin, End, Commit, Rollback

– Declaratively handled requires the EJBObject

Distributed Transaction Support

• 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

already present

– TXN_MANDATORY: bean must run in a transaction, and that transaction must already be present and active

(javax.ejb.TransactionRequired exception)

Distributed Transaction Support

• 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)

Resource Management/Load Balancing

Mechanisms

• Instance pooling in EJB Servers reduces the number of component instances needed overall, by allowing clients

to share components individually or collectively

• Pooling also reduces the frequency of component creation and removal

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

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

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 as well 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

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 reinvoking

findByPrimaryKey, which will automatically

map to other supporting groups

Metadata Management

• Deployment Descriptors allow EJB

containers to supply run-time middleware services (persistence, transaction, security, etc.) to a generic EJB, thus relieving the EJB from having to hard-code this support into the bean itself

• Entries in a Deployment Descriptor

cumulatively make up the bean’s metadata

Metadata Management

• A bean’s metadata may also include bean-specific

properties that are become Java properties, that are

available 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 a

serializable Java class, based on a plain text file

description, and a manifest file was needed to describe all the 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 is

written in XML Since there is now only one deployment descriptor, manifest files are no longer needed

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

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

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

Responsibilities of the Container for

Session Beans

• Making the home interfaces of deployed beans

available via JNDI

• Implementing the home interface of each installed EJB (EJBHome)

– home interface allows a client to create a new session object (factory method)

– home interface allows for the removal of a

session object

• Implementing the remote interface of each

installed EJB (EJBObject)

– remote interface allows clients to make

business method calls on a session objects

Responsibilities of the Container for

Session Beans

• Implementing Handle (support) classes for the

Home and Remote interfaces

• Implementing the EJBMetaData class

• Must ensure that only one thread can be executing

an instance at any time (session objects are

serialized, single-client servants)

Responsibilities of the Container for

Entity Beans

• Making the home interfaces of deployed beans

available via JNDI

• Implementing the home interface of each installed EJB (EJBHome)

– home interface allows a client to create a new session object (factory method)

– home interface allows for the removal of a

session object

• Implementing the remote interface of each

installed EJB (EJBObject)

– remote interface allows clients to make

business method calls on a session objects

Responsibilities of the Container for

Entity Beans

• Implementing Handle (support) classes for the Home and Remote interfaces

• Implementing the EJBMetaData class

• Must ensure that reentrant rules are

followed (intra-transactional legal loopback, illegal concurrent call)

• Implementation of robust (long-lived)

object references A client should be able

BEA Weblogic Enterprise

(WLE)

(Application-to-Transaction Manager Interface), CORBA and EJB

and monitoring infrastructure

Tuxedo ATMI (Xopen XATMI compliant)