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 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 by Java 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 manage resources 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 application developer 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 a Big Picture of J2EE

Where is EJB? J2EE Web Tier EJB Tier DB

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.

These interfaces specify the bean contract to the clients. 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 Entity Beans Message Driven 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

Stateless: execute a request and return a 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 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 newInstance() setSessionContext() ejbCreate() ejbRemove() Method -Ready

Stateful Session Bean Life Cycle of Stateful Session Bean Does Not Exist create() newInstance() setSessionContext() ejbCreate() remove() ejbRemove() ejbPassivate() Ready Passive ejbActivate()

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 EJB class Import Extend EJBHome java.io.Serializable Java.rmi.RemoteException Javax.ejb.CreateException Javax.ejb.EJBHome Extend EJBHome Create() method With RemoteEXception and CreateException EJB class 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 Shared Access Primary Key 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 BMP entity beans 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 newInstance() setEntityContext() unsetEntityContext() Pooled Create() ejbCreate() ejbPostCreate() remove() ejbRemove() ejbActivate() ejbPassivate() Ready

Session Beans and Entity Beans

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