EJB

Enterprise Java Bean

Introduction

• Java's most important features is platform independence.

• Java has been depicted as "write once, run anywhere"

• Enterprise JavaBeans (EJBs) is both platform independent but also implementation independent.

• EJBs can run in any application server that implements the EJB specifications

Enterprise Distributed Object Computing (EDOC) • Distributed computing allows business logic and data to

be located on separate computers

• Reached from remote locations at any time from anywhere by any one.

• Recent development in distributed computing is distributed object computing.

• The technologies such as Java RMI, CORBA and Microsoft's DCOM help to accomplish distributed object computing.

– Allows objects running on one computer to be accessed for servicing the clients in other computers.

• Object-oriented (OO) programming languages viz., Java, C++, Smalltalk

– Features• Flexibility, Extensibility and Reusability

– Methodology• Encapsulation, Polymorphism and Inheritance

• In business systems,

– To improve development of GUIs – To simplify access to data – To encapsulate the business logic into business

objects– To support above mentioned features and

Methodology.

Reaching EJB from earlier computing paradigms

• Multi-Tier– Scalability, Performance, Reliability…

• Client does not directly interact with the server.

• Client contacts the middleware, it instantiates the server application and manages the server objects, and it returns to the client.

• Middleware– Concentrate only on business logic– Supports

• Thread Handling• Security• Transaction Management• Resource Management

Transaction Processing (TP) Monitors • TP monitors

– High-speed server platforms– For mission-critical applications

• TP monitors are for applications are written in languages like COBOL

• TP monitors automatically manage the entire environment that a business system runs in:– Transactions– Resource management– Fault tolerance

• With these feature it is eligible to be called operating systems

• The business logic in TP monitors is made up of procedural applications that are often accessed through network messaging or remote procedural calls (RPC).

• RPC is a distributed mechanism that allows clients to invoke procedures on applications in a TP monitor as if the procedure was executed locally.

• The downside for TP monitors is as follows:

– TP monitors are not object oriented

– Work with procedural code that can perform complex and mission-critical tasks but no sense of identity.

– Accessing a TP monitors through RPC is like executing static methods.

– The business logic, which is procedural, is not as flexible, extensible, or reusable.

Object Request Brokers (ORBs)

• Distributed objects allow unique objects that have state and identity.

• Distributed object computing technologies like CORBA and Java RMI, invoking method is on an object instance, not an application procedure.

• Distributed objects are usually deployed on

some kind of ORB - responsible for helping client applications find distributed objects in a transparent manner.

• The down side for an ORB is as follows:

– ORBs do not define an operating system for distributed objects.

– All the responsibility for concurrency, transactions, resource management and fault tolerance rests on the application developers.

– These services may be available from the ORB vendors or can be purchased from third party vendors and can be implemented in an ORB.

– The developer has to write the glue code to incorporate them into the business objects.

• The resource management strategies such as – Instance swapping– Resource pooling– Pre-cached Instances

• Mainly responsible for distributed object systems to scale:– improve performance and throughput and reducing

latency.

• Without automatic support OS features.

• In addition ORBs fail to address the complexities of mission-critical environment, an area where TP monitors have always excelled.

Component Transaction Monitor (CTM)

• Having realized that combining these two revolutionary technologies will do wonders for enterprises

• IBM and BEA started to design a hybrid of ORBs and TP monitor systems, which is referred to as component transaction monitors (CTMs) or application servers.

• These types of application servers combine the flexibility and accessibility of distributed object systems based on ORBs with the robust operating system of a TP monitor.

• CTMs provide a comprehensive environment for server-side components by

– Transaction managing – Concurrency– Transactions– Object Distribution– Load Balancing– Security – Resource Management automatically.

• CTMs have started to come out of several different industries

– Relational Database industry– Application Server industry – Web Server Industry– CORBA ORB industry– TP monitor industry.

• Each vendor offers products that reflect their particular area of expertise.

• But a CTM that supports the Enterprise JavaBeans standard server-side component model from Sun Microsystems seems to be a more elegant and productive choice.

• Reasons for success:

– Sun Microsystems has framed a number of excellent standard server-side specifications for several technologies.

– The Java Database Connectivity API (JDBC) was one of the shining examples.

Why EJB?

• Sun Microsystems in the beginning put forward Java Remote Method Invocation (RMI) API as a distributed object computing technology.

• RMI specifies how to write objects so that they can talk to each other no matter where on the network they are found.

• RMI says nothing about other characteristics normally required of an enterprise-class distributed environment.

• For example, it does not say anything about how a client might perform a search for RMI objects matching some criteria.

• It also does not specify how those distributed objects work together to construct a single transaction.

• Thus there is a realization for a need of a distributed component model.

• A component model is a standard that defines how components are written so that systems can be built from components by different developers with little or no customization.

• There is already a component model called as JavaBeans in Java.

• It is a component model that defines how we write user interface components so that they may be plugged into third-party applications.

• The magic thing about JavaBeans is that there is very little API behind the specification; we neither implement nor extend any special classes and we need not call any special methods.

• While there are API elements behind Enterprise JavaBeans, it is more than an API.

• It is a standard way of writing distributed components so that the written components can be used with the components we write in someone else's system

• RMI does not support this ability for several reasons listed below:– Security – Searching – Transactions – Persistence

What is EJB? (From EJB Spec.)

• “The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications.“

• “Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure.“

• “These applications may be written once, then deployed on any server platform that supports the Enterprise JavaBeans specification."

What is EJB Technology?

• Cornerstone of J2EE

• A server-side component technology

• Easy development and deployment of Java technology-based application that are:– Transactional, distributed, multi-tier,portable,

scalable, secure, …

EJB Design Principles

• EJB applications are loosely coupled• EJB behavior is specified by interfaces• EJB applications do not manage resources• The container supports the application

developer• EJB applications are tiered• The session tier is the API to the application• The entity tier is the API to the data sources

EJB Applications are Loosely Coupled

• Support the integration of components from different vendors

• EJBs refer to other components and services to which they have access by arbitrary names

• EJB can be authored without a detailed knowledge of the environment

• Applications can be assembled from separate components

EJB behavior is specified byJava interfaces

• An EJB’s interaction with its clients is specified entirely in terms of Java interfaces

– Interfaces expose the methods that clients can call, and thereby set out a ‘contract’ between the client and the EJB

– Implementation is hidden from the client

– Supports portability and modularity

EJB applications do not manageresources

• EJBs get access to external resources (databases, legacy systems) through their container– Programmer does not have to worry about resource

allocation and de-allocation

• It is the container’s job to manage these resources, and make the access as efficient as possible– Container is configured by system admin not through

programming APIs

Container supports applicationdeveloper

• Container provides system services– Persistence– Security– Transaction– Connection pooling– Component lifecycle management– Threading

• Application developer and deployer specifies his/her requirements in declarative fashion (in deployment descriptor)

EJB in aBig Picture of J2EE

Where is EJB?

Web Tier EJB Tier DB

J2EE

EJB Architecture Any distributed component technology should have the following requirements:

1. There should be a mechanism to create the client-side and server-side proxy objects.

• A client-side proxy represents the server-side object on the client-side. As far as the client is concerned, the client-side proxy is equivalent to the server-side object.

• On the other hand, the purpose of the server-side proxy is to provide the basic infrastructure to receive client requests and delegate these request to the actual implementation object

2. We need to obtain a reference to client-side proxy object. In order to communicate with the server-side object, the client needs to obtain a reference to the proxy.

3. There should be a way to inform the distributed component system that a specific component is no longer in use by the client.

• In order to meet these requirements, the EJB architecture specifies two kinds of interfaces for each bean.

• These interfaces specify the bean contract to the clients.• Interfaces are:

– Home interface• The home interface will contain methods to be used for creating

remote objects• Extends the javax.ejb.EJBHome

– Remote interface• The remote interface should include business methods that a bean is

able to serve to clients• Extends the javax.ejb.EJBObject

• EJB is a layered Architecture consisting of:– EJB Server, which contains the EJB container

• Responsible for network connectivity to the container.

– EJB Container, which contains enterprise beans.

• Uses the Home Interface and Remote Interface• All basic operation of OS

– Enterprise bean, which contains methods that implements architecture (Business Logic)

EJB Architecture

Types of Beans

• Session Beans– Stateful session beans– Stateless session beans

• Entity Beans– Bean Managed Persistence (BMP)– Container Managed Persistence (CMP)

• Message Driven Beans– JMS– JAXM

• A bean developer has to specify the home and remote interfaces and also he has to implement one of these bean interfaces depending upon the type of the bean.

• For instance, for session beans, he has to implement the javax.ejb.SessionBean interface.

• The EJB architecture expects him to implement the methods specified in the bean interface and the methods specified in the home and remote interfaces.

• During the deployment time, he should specify the home and remote interfaces and bean implementation class to define a bean.

• The EJB container relies on specific method names and uses delegation for invoking methods on bean instance

How to invoke a bean instances

• EJB container for each bean implement a proxy object to the home interface and publishes in the JNDI implementation of the J2EE platform.

• One can use JNDI to look for this and obtain a reference.

• As this object implements the home interface only, he can use one of the creation methods of the home object to get a proxy to the remote interface of the bean.

• When one invokes a creation method on the home proxy object, the container makes sure that a bean instance is created on the EJB container runtime and its proxy is returned to the client.

• Once the client gets hold of the proxy for the remote interface, it can directly access the services of the bean.

• Finally, once the client decides to stop accessing the services of the bean, it can inform the EJB container by calling a remote method on the bean.

• This signals the EJB container to disassociate the bean instance from the proxy and that bean instance is ready to service any other clients.

Session Beans

• Does work on behalf of a single client• Does not use any persistent storage

mechanism.• Is not persistent and hence relatively short lived

– Is removed when the EJB server crashes

• Does not represent data in data store, although can access/update such data

• Bean class implements javax.ejb.SessionBean interface

When to Use Session Beans?

• Use Session beans to model process or control objects specific to a particular client.

• To model workflow, processes or tasks, manage activities (make reservation, purchase...).

• To Coordinate processes between entity beans, control interactions of beans

• To Move business application logic from Client to the Server Side

2 Types of Session Beans

• Stateless: execute a request and return a

result without saving any client specific state information– Transient– Single Method Call– temporary piece of business logic needed by

a specific client for a limited time span

• Stateful: maintains client specific state– Mutiple Method Call

State Instance Data

Examples of Session Beans

• Stateless session beans– Catalog

• No client specific state needs to be preserved

– Interest calculator• No client specific state needs to be preserved• Business logic with no need for database access

• Stateful session beans– Shopping cart

• Items choosen by the client needs to be stored– Method which calculates the price will use.

– For displaying the list of books purchased.

Stateless Session Bean

• Life Cycle of Stateless Session Bean

Does Not Exist

Method -Ready

newInstance()

setSessionContext()

ejbCreate()

ejbRemove()

Stateful Session Bean

• Life Cycle of Stateful Session Bean

Does Not Exist

Ready Passive

remove()

ejbRemove()

ejbPassivate()

ejbActivate()

create()

newInstance()

setSessionContext()

ejbCreate()

Example of Stateless Session Bean

• The enterprise bean Consists of the following classes and interfaces:– Remote interface

• Import javax.ejb.EJBObject and java.rmi.RemoteException interface.

• Access modifier is public• Remote interface name should not be a keyword.• Must Extend from EJBObject interface.• Throws an RemoteException-network failure

– Home interface• Import

– java.io.Serializable– Java.rmi.RemoteException– Javax.ejb.CreateException– Javax.ejb.EJBHome

• Extend EJBHome– Create() method – With RemoteEXception and CreateException

– EJB class• Import

– Java.rmi.RemoteEXception– Javax.ejb.SessionBean– Javax.ejb.SessionContext

• Implement SessionBean and Remote Interface• Write the following methods

– ejbCreate()– ejbRemove()– ejbActivate()– ejbPassive()– setSessionContext()

Deployment Descriptor• To mange enterprise bean at run time we use

Deployment Descriptor.

• Deployment descriptor is an .xml file and contains information about deployment of enterprise bean.

• It contains the following information

– Then Access Control list (ACL) of the entities authorized to invoke classes or methods.

– The name of the EJB class– The name of the EJB home interface– The name of the EJB remote interface– A list of container- managed files if the enterprise bean is an

entity bean.– A value specifying whether the enterprise bean is stateful or

stateless, in case of a session bean.

Example of Stateful Session Bean

• Shopping cart, Credit card validator..• You can choose to implement Stateful

session bean if:– The bean instance need to be initialized when it

is created.– The client application is an interactive one.– The client is likely to invoke multiple method-

calls.– The bean needs to store client-specific

information across method calls.

Entity Beans

• Provides object view of data in data store– Its lifetime not related to the duration of interaction with clients– Lives as long as data exists in database i.e.Long lived– In most cases, synchronized with relational databases

• Shared access among multiple clients• Bean class implements javax.ejb.EntityBean interface.• Used in EJB application where data about business

entities such as customers, accounts and products have to stored in database.

• Models Persistent data

Key Features

• Persistence– By storing the state of the bean in the bean– It is done by mapping itself with a row in a table.

• Shared Access– Multiple clients can access an entity bean at a

particular instant.– Manipulation can be done simultaneously.

(transaction management)

• Primary Key– Used to identify the bean in the data store by the

client. e.g.: product bean-product code.

Entity Beans

• Clients normally look up (find) an existing entity EJB– Creation means adding a row to a database

table– Finding means finding a row in a existing

database table– Removing means removing a row from a

database table

2 Types of Entity Beans

• CMP (Container Managed Persistence)– Persistence is managed by Container– Persistence requirements are specified in

deployment descriptor– Bean developer does not have to worry about

providing persistence logic in his code

• BMP (Bean Managed Persistence)– Persistence logic code is provided by Bean

developer

Terminologies to be known• Table Relationship

– One to One• One entity related to one occurrence

– One to Many• One entity related to many occurrence

– Many to Many• Every entity related to many occurrence

• Transaction– Single Atomic Operation in series of steps.– Successful only when all steps within it will execute– Commit or rollback– ACID– Persistent– Declarative and programmatic transaction

• Authorization– Ensure that clients are authorized to perform operation– Declarative and programmatic authorization– isCallerInRole() & getCallerIdentity()

• Security Exception– System and Application Exception– Database connectivity & Logical Error Respectively

Examples of Entity Beans

• Customer– Customer data has to persist, thus is

maintained in the database– Customer data has to survive server crash– Customer data is shared by many clients– Each customer has unique identification such

as customer number

When to Use CMP vs. BMP?

• CMP– Database independence– Higher performance– Easy to develop and deploy

• BMP entity beans– More programmatic control is desired

Life cycle of Entity Bean

Does Not Exist

Pooled

Ready

ejbActivate() ejbPassivate()

Create()

ejbCreate()

ejbPostCreate()

newInstance()

setEntityContext()unsetEntityContext()

remove()

ejbRemove()

Session Beans and EntityBeans

Message-Driven Beans (MDB)

• Acts as a consumer of asynchronous messages

• Cannot be called directly by clients– Activated upon message arrival– No home or remote interface

• Clients interact with MDB by sending messages to the queues or topics to which they are listening

• Stateless