EJB - Enterprise Java Beans

  • Model for defining server-side components
  • Model for defining distributed client interfaces to services provided by these components.
  • Standard operations for allowing container to create, destroy, allocate, persist, and activate component instances
  • Model for defining component that encapsulates a data source entry with object-to-relational mapping handled by the container (in container managed).
  • Ability to seperate presentation logic from business logic from data layer logic.
  • Standard way to configure and deploy a component independent of its implementation (uses XML)
  • Standard way to define transaction attributes of a component (uses XML).
  • J2EE Conector Architecture (JCA) and Java Message Service (JMS) APIs can be used to integrate EJBs with non-Java application.

 

EJB and JavaBeans

These are very different software components.

Common

  • they are components...thats it

Differences

  • JavaBeans: used to develop reusable components mostly for GUI components....hence can be thought of as client-side technology.
  • JavaBeans: either a view bean or a data bean...view (GUI) is the most common. Sometimes data bean can be used as a "data container" to transfer data between a servlet and an EJB...but, other solutions better.
  • JavaBeans: consist of one class, is local to a single process, and can not be shared by multiple users.
  • EJB: consists of one interface and one class (previous version =two interfaces + two classes) and can be shared by multiple users, server-side.

 

EJB Application Server (J2EE Application Server)

You need an EJB application server to deploy and run your EJBs. Some possibilities:

  • BEA's WebLogic Server
  • IBM's WebSphere
  • Open source JBoss
  • Sun's J2EE Application Server (Sun ONE)

 

Kinds of EJBs

Session Beans

Used to perform some action on the enterprise system and possibly deliver results to client

  • typically used to encapsulate business logic
  • best practice: use when only one client has access to a bean instance and the state does not need to be persistent.
  • Think of a session bean as a grouping of related business operations
    • BankTeller session bean does withdrawl, checkaccount, deposit
    • LoanManager session bean does loan_application, loan_approval

      Stateless Session Beans

      created with no regard for the maintenance of any state between subsequent calls by a client.

      Statefull Session Beans

      maintain state for a particular client between alss before some amount of time has expiered.

Entity Beans

 

NO LONGER EXISTS FOR LASTEST VERSION OF EJB ( have been replaced by Java Persistence API entities. For information about entities, see Chapter 16, Introduction to the Java Persistence API.)

Used to encapsulate some data contained in the enterprise system. Such data may be created, removed or found by clients.

  • Have special primary key classes defined for them that relate to primary keys of an associated entity stored in a database.
  • Typically do not directly interface between clients to Entity beans but through middleware of a session bean.
  • best practice: use if multiple clients can access bean and state needs to be persistent.

Bean-Managed Persistence (BMP) Entity Beans

the bean itself has code to deal with the insert, deletion, querying and update of data to the relation data source.

Container-Managed Persistence(CMP) EntityBeans

container provides code to deal with insert, delete, query, update of database. Rely on deployment descriptor to mab EBJ class fields to columns (keys) of database table. It then generates the SQL as necessary.
Message Driven Beans

Used to provide a service whose invocation is asynchronous and driven by the arrival of enterprise messages (JMS) OR other kinds of messages.

  • It normally acts as a JMS message listener, which is similar to an event listener except that it receives JMS messages instead of events.
  • Meassages can be sent by any Java EE component (an application client, another enterprise bean, or a web component) OR by a JMS application OR system that does not use Java EE technology.
  • Message-driven beans can process JMS messages OR other kinds of messages.
  • Instance variables of the message-driven bean instance can contain some state across the handling of client messages (for example, a JMS API connection, an open database connection, or an object reference to an enterprise bean object).
  • All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently.

  • A single message-driven bean can process messages from multiple clients.

Characteristics

  • They execute upon receipt of a single client message.

  • They are invoked asynchronously.

  • They are relatively short-lived.

  • They do not represent directly shared data in the database, but they can access and update this data.

  • They can be transaction-aware.

  • They are stateless.

Lifecycle

  • When a message arrives, the container calls the message-driven bean’s onMessage method to process the message.
  • The onMessage method normally casts the message to one of the five JMS message types and handles it in accordance with the application’s business logic.
  • The onMessage method can call helper methods, or it can invoke a session bean to process the information in the message or to store it in a database.

 

best practice: use when you want to develop loosely coupled system and process asynchronous messages.

EJB directory Structure

directory structure

 

EJB deployed by self.

OPTION1: uncompressed

use directory structure above and specify directory (assembly root) as directory of EJB code

OPTION 2: compressed

compress into JAR/EAR file and deploy this to server.

EJB deployed as part of a Web Application

Packaging Enterprise Beans in WAR Modules

Enterprise beans often provide the business logic of a web application.

Packaging the enterprise bean within the web application's WAR module can make deployment easier.

OPTION 1: not compressed, class files in WEB-INF/classes directory

To include enterprise bean class files in a WAR module, the class files should be in the WEB-INF/classes directory.

OPTION 2: compressed, JAR file.

To include a JAR file that contains enterprise beans in a WAR module, add the JAR to the WEB-INF/lib directory of the WAR module.

NOTE: on ejb-jar.xml in this case:

WAR modules that contain enterprise beans do not require an ejb-jar.xml deployment descriptor. If the application uses ejb-jar.xml, it must be located in the WAR module's WEB-INF directory.

EXAMPLE:

Suppose a web application consisted of a shopping cart enterprise bean, a credit card processing enterprise bean, and a Java servlet front-end. The shopping cart bean exposes a local, no-interface view and is defined as follows:

package com.example.cart;    
@Stateless  public class CartBean { ... }

The credit card processing bean is packaged within its own JAR file, cc.jar. It exposes a local, no-interface view and is defined as follows:

package com.example.cc;    
@Stateless  public class CreditCardBean { ... }

The servlet, com.example.web.StoreServlet handles the web front-end and uses both CartBean and CreditCardBean. The WAR module layout for this application looks as follows:

WEB-INF/classes/com/example/cart/CartBean.class  
WEB-INF/classes/com/example/web/StoreServlet  
WEB-INF/lib/cc.jar 
WEB-INF/ejb-jar.xml  
WEB-INF/web.xml