Blog

EJB stands for Enterprise Java Bean. An enterprise bean is a server-side component that encapsulates the business logic of an application. The business logic is the code that fulfils the purpose of the application.

• Session Bean
• Entity Bean
• Message Driven Bean

A Session Bean is an Enterprise Bean that is generated for each session from the client and expires when the client exits. The lifecycle of the Session Bean does not exceed the range from the beginning until the end of the usage of the system by the user. Session Beans are classified into Stateless Session Beans, Stateful Session Beans, and Singleton Session Beans.

Stateless Session Bean is a model in which the state of the session is not managed. Each session from the client needs to be concluded in one invocation of the Bean business method.

Stateful Session Bean is a model in which the state of the session is managed. The EJB container manages the state of the session. Even when one session from the client invokes multiple EJB business methods, the state of each session is saved in between the invocation of the business methods.

Singleton Session Bean is a model in which the state of the session is shared among multiple clients. One instance which is shared among all the sessions is created for an application. You must determine the Bean lifecycle according to the application.

An Entity Bean expresses the entity, and as a prerequisite, must be stored (persisted) in the database. As a result, even when the client exits, the state of the Entity Bean continues to exist in the database. The lifecycle of this Enterprise Bean is longer as compared to that of a Session Bean. Entity Bean two types BMP,CMP.

Bean Managed Persistence is a model for managing the data persistence of Enterprise Bean business methods. The developer of the Enterprise Bean must implement processes such as connecting to the database, assembling and executing SQL statements.

Container-Managed Persistence is a model in which the EJB container manages the data persistence. The EJB container executes processes, such as connecting to the database and storing data, therefore, these processes need not be executed by the business methods of the Enterprise Bean. Use the method provided by the EJB container to define the mapping of the Enterprise Bean data and the tables and columns of the database in which the data is to be stored. At the same time, define the connection information, such as the host name and port number of the database to which you will connect, in a resource adapter or a data source. The EJB container references this definition information, assembles the SQL statements, and references and stores the data in the tables of the database to which you will connect.

 A message-driven bean is an enterprise bean that allows J2EE applications to process messages asynchronously. It acts as a JMS message listener, which is similar to an event listener except that it receives messages instead of events. The messages may be sent by any J2EE component—an application client, another enterprise bean, or a Web component—or by a JMS application or system that does not use J2EE technology.

A collection of synchronized specifications and procedures, which enable solutions regarding deploying, developing supervising multi-tier server-centric applications, is called J2EE.

Java Message Service is a messaging service to create, send and receive messages asynchronously

During runtime, when the changes made in the various properties of server group, are propagated in every associated clone, this process is known as Ripple Effect.

A transaction is a single unit of work items, which follows the ACID properties. ACID stands for Atomic, Consistent, Isolated, and Durable.

Atomic: If any of the work item fails, the whole unit will be considered failed. Success meant, all items execute successfully.

Consistent: A transaction must keep the system in consistent state.

Isolated: Each transaction executes independent of any other transaction.

Durable: Transaction should survive system failure if it has been executed or committed.

Security support: Used to configure Deployment Descriptor (DD)

Persistence support: Used to be persistence in transactions.

Transaction management support: Used to configure Deployment Descriptor (DD)

Management of Session: Call-back methods such as ejbStore (), ejbLoad () are used in the Developer.

Management of Life Cycle: Automatic

An EJB container is a runtime environment that manages one or more enterprise beans. The EJB container manages the life cycles of enterprise bean objects, coordinates distributed transactions, and implements object security. Generally, each EJB container is provided by an EJB server and contains a set of enterprise beans that run on the server. (Source: IBM)

EJB Query Language is quite handy to write custom queries without worrying about underlying database details. It is quite similar to HQL, hibernate query language and is often referred by the name EJBQL.

An EJB server is a high-level process or application that provides a runtime environment to support the execution of server applications that use enterprise beans. An EJB server provides a JNDI-accessible naming service, manages, and coordinates the allocation of resources to client applications, provides access to system resources, and provides a transaction service.

Server group copies are defined as clone. But unlike Server Groups, clones are linked by means of nodes.

An interceptor method is called by ejb Container before business method call it is intercepting. Following is the example signature of an interceptor method

In Point to Point model, one message is delivered to one receiver only. Here, Queue is used as a message-oriented middleware.

Context is a method of binding a name to a specific object by giving an interface like javax.naming.Context.

Implementation of available methods in the interface of context such as a context called javax.meaning.InitialContext.

An EJB Context object, the Session Context is used for accessing the information and container services.

An EJB client JAR file is an optional JAR file that can contain all the class files that a client program needs to use the client view of the enterprise beans that are contained in the EJB JAR file.

Beaninterface

Beanname

Mappedname

• Mandatory
• Required
• Requires_New
• Supports
• Not_Supported
• Never

Home Object reference is retrieved from the Naming Service via JNDI. Home Object reference is returned to the client. The steps are:

• Created a new EJB Object via Home Object interface.
• Created an EJB Object from the Ejb Object.
• Returned an EJB Object reference to the client.
• Invoked business method by using EJB Object reference.
• Delegate requested to Bean (Enterprise Bean

• Create a database table
• Create entity classes for the table
• Create persistent unit and data source
• Create a stateless EJB
• Update stateless EJBM
• Console based application accesses the stateless EJB.

The act of redeployment, deployment and un-deployment in Web logic when the server is running in EJB is called Hot Deployment.

EJBs are based conceptually on the Java Remote Method Invocation (RMI) model. For example, remote object access and parameter passing for EJBs follow the RMI specification.

The EJB specification does not prescribe that the transport mechanism has to be pure RMI. The Oracle8i EJB server uses RMI over IIOP for its transport protocol, a practice that is becoming common among server vendors.

The following are the flows of the EJB architecture.

1. The client is working on a web browser.
2. There is a database server that hosts a database, like MySQL / Oracle.
3. The J2EE server machine is running on an application server
4. The client interface is provided with JSP / Servlet. The enterprise beans reside in the business tier providing to the client tier.
5. The Application Server manages the relationships between the client and database machines.

Main Components of EJB Architecture

EJB server(s)

EJB container(s)

Enterprise Beans

EJB clients

Other auxiliary systems (e.g. Java Naming and Directory Interface (JNDI) server, Java Transaction Service (JTS)

EJB:

• An EJB is a nonvisual, remote object.
• EJB’s are remotely executable components or business objects that can be deployed only on the server.
• Even though EJB is a component technology, it neither builds upon nor extends the original JavaBean specification.
• EJBs have a deployment descriptor that describes its functionality to an external builder tool or IDE.
• EJB’s have no concept of BeanInfo classes, property editors or customizers and provide no additional information other than that described in the deployment descriptor.
• EJBs are of two types – session beans and entity beans.
• EJB’s may be transactional and the EJB servers provide the transactional support.
• An EJB cannot be deployed as an ActiveX control because ActiveX controls are intended to run at the desktop and EJB’s are server side components. However CORBA-IIOP compatibility via the EJB-to-CORBA mapping is defined by the OMG.

JavaBeans:

• JavaBeans may be visible or no visible at runtime.
• JavaBeans are intended to be local to a single process and are primarily intended to run on the client side.
• Although one can develop server-side JavaBeans, it is far easier to develop them using the EJB specification instead.
• Java Bean is a component technology to create generic java components that can be composed together into applets and applications.
• JavaBeans have an external interface called the properties interface, which allows a builder tool to interpret the functionality of the bean.
• JavaBeans may have Bean Info classes, property editors or Customizers.
• JavaBeans have no types.
• No explicit support exists for transactions in JavaBeans.
• Component bridges are available for JavaBeans.