New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

Technical Introduction to Enterprise JavaBeans

 

Course Title: Application Servers                                           Course Number: g22.3033-011

Instructor: Jean-Claude Franchitti                                            Session: 6

 

 

Enterprise JavaBeans (EJB) implement a specification developed by Sun Microsystems that has been adopted by a variety of vendors as a distributed component model for the Java programming language. 

The specification is loosely based on the JavaBeans specification, which defines a component model for in-process components.  EJB represents out-of-process components.  The EJB architecture is a three-tier logical architecture, allowing the database, business logic, and client applications to run separately.

Containers

Every Enterprise JavaBean runs inside of a container.  The container handles the details of all of the system-level semantics for the business programmer, including management, transactional integrity, security, load balancing, error handling, threading, and possibly persistence.  The container is an integral part of any purchased application server.

 

When a client interacts with an Enterprise JavaBean, it actually interacts with the application server.  The application server, in turn, interacts with the container, which interacts with the EJB.


Session Beans and Entity Beans

The EJB specification describes two different types of Enterprise JavaBeans: session beans and entity beans.  The primary difference between session beans and entity beans is that session beans are non-persistent, while entity beans persist over time.  Generally a session bean represents the business logic, while an entity bean generally represents business data. 

For example, a session bean may be used to represent an ATM while entity beans would be used to represent Accounts.  The ATM provides the business transactions to the end user, like deposit, withdrawl, and transfer.  The Account represents the bank account data that the ATM is manipulating.

EJB Architecture at a Glance

Sample EJB Logical Partitioning

The EJB architecture separates the application into logical layers and keeps all application code from doing platform-specific work.

There are two kinds of Enterprise JavaBeans: Entity and Session beans. Entity beans encapsulate data as it is used by the application. Examples of Entity beans might be Customer or Order. Session beans encapsulate the business logic of the application. Session beans handle complex actions such as web-based business transactions.

 

 


The diagram above illustrates a sound architectural pattern. The application is broken into three layers: Data, Business Logic, and Presentation. Functionality for each layer is wholly confined to that layer. In other words, there is no business logic in the Data layer, and no presentation-specific code in the Business Logic layer.

This practice makes for a highly flexible system that can change easily as the business need changes. For example, if a new database technology that offers wildly improved performance appears on the market, a properly layered application can take advantage of the new technology with minimal (if any) changes to the business logic or presentation layers of the application.

This approach also allows multiple layers to be applied. For example, two divisions of a company could implement different Business Logic layers over the same Data Layer. Or an application could offer a windowed desktop user interface and a web browser interface on top of the same Business Logic and Data layers.

The Enterprise JavaBean architecture is specifically designed to implement this kind of system, and, in some ways, actually makes writing a poorly architected system more difficult.

Java also allows a further separation of the code written and the system it runs on. A system designed to run on a very large and expensive UNIX system can be developed in an inexpensive NT development environment.

Sample EJB Physical Partitioning

The diagram below illustrates the physical partitioning of a sample EJB application. Note that multiple EJB and servlet servers or web servers can be added to the mix, providing horizontal scalability and reliability to a properly built EJB application. The same EJB application, however, could be run on a single machine.

 

 

Session Beans

Session beans allow developers to create objects that execute functionality remotely on the behalf of a client.  Conceptually, one instance of a session bean is created for each user, users do not share session beans.  When the user completes the activities using the session bean, the session bean is destroyed.

Stateless Session Beans vs. Stateful Session Beans

Session beans may either be stateless or they may maintain conversational state.  A stateless session bean doesn’t maintain any context with the client between method calls.  Each call is independent; the session bean only uses data passed in as parameters to determine context.  Stateful beans, on the other hand, maintain state as long as the client is using the session. Once the client releases the session bean, the state is destroyed.  In general, stateless session beans provide better performance than stateful session beans because they allow the most flexibility for the application server to pool and share resources.

Building a Session Bean

When building a session bean, the programmer needs to define three things.  A home interface, a remote interface and the session bean class.

Home Interface

The home interface is used to tell the application server to create an instance of the session bean for a client.  When a client wants a new session bean, the client will call a create method on the home interface.  When the client is done with the bean, it will call a remove method on the bean itself.  The home interface extends the javax.ejb.EJBHome interface.

Remote Interface

The remote interface is the client’s view into a specific session bean.  It describes all of the session bean methods that are available to the client.  It extends the javax.ejb.EJBObject interface. 

Session Bean Class

The session bean class has the specific functionality to support the home and remote interfaces.  Session beans extend the javax.ejb.SessionBean class.

Oddly, the session bean class does not implement the home interface or the remote interface.  However, it must contain a corresponding method for each method on the remote interface.

Entity Beans

An Entity bean can be thought of as a component representing a row of data from a database table.  While the client program tells the application server when to create and remove an entity bean, the application server determines when to save and read the entity bean to and from the database.

Container-Managed vs. Bean-Managed Persistence

Because entity beans persist over a long duration, they are typically stored in a database.  An application server may handle the storing and loading of the entity, or the programmer may write it into the entity bean class.  When the application server handles the storing and loading of the entity bean, it’s called container-managed persistence.  When the programmer handles the implementation directly, it’s called bean-managed persistence.

Building an Entity Bean

Home Interface

Like the session bean, the home interface of an entity bean is used to tell the application server to create an entity bean.  However, because entity beans stay around beyond any single user interaction, the methods are used slightly differently. 

The create method of an entity bean is functionally equivalent to a database insert.  Every time a client calls the create method, the returned bean represents brand new, never before seen data. 

If a client wants to get a handle to an entity bean that was created previously, the client uses a different method on the home interface.  These methods are called finder methods because they are used to find a previously created entity bean. Finder methods return a remote interface if a single bean was found, or an Enumeration of remote interfaces if multiple beans were found.

Calling remove on an entity bean deletes it from the database.

The home interface extends javax.ejb.EJBHome interface.

Remote Interface

The remote interface is the client’s view into a specific entity bean.  Minimally, this interface will describe how to get and set all of the attributes of the entity bean, except for the primary keys. These can be viewed but never changed.  The remote interface extends the javax.ejb.EJBObject interface.

Entity Bean Class

The entity bean class contains all of the methods to support the home and remote interfaces.  If the programmer decides to use bean-managed persistence, this class also contains the methods that describe how to create, store, load, and remove the entity bean.  The entity bean class extends the javax.ejb.EntityBean class.

Primary Key Class

Like a primary key on a database table, the primary key class is used to uniquely identify an entity bean.  With the primary key a client may get a handle to the remote interface of the entity bean by using a finder method on the home interface.  Because primary keys may be passed over the network, the primary key class implements the java.io.serializable interface.

Deployment

Once a bean is coded, the final step is to tell the application server’s container how to use the bean.  While the container handles naming, management, transactional integrity, security and persistence for the bean developer, the developer still needs to tell the container how these concepts apply to a specific bean.  To do this the developer creates a deployment descriptor class.  The mechanism for creating this class varies from application server to application server, but they all contain the same basic information.

Naming

The deployment descriptor defines a name that is used to find the beans home interface.  Clients will request the home interface from the application server using this name.

Management

The deployment descriptor contains information about the basics of the bean. It is used to tie the home interface, the remote interface, the enterprise bean class, and, in the case of entity beans, the primary key class together.  The deployment descriptor also defines whether a session bean is stateful or stateless.

Transactions

The deployment descriptor contains information about how each method on a bean interacts with a transaction.  The deployment descriptor can contain default interactions at the bean level, or it may contain how each method interacts individually.  The descriptor may contain default transactional support for the entire bean, or it may contain information for specific methods.  There are six different ways that a method may interact with transactions:

q       TX_SUPPORTS.  The method will interact with a transaction if one is already created; however, it doesn’t have to be in one.

q       TX_REQUIRED.  The method can only be invoked if a transaction exists.  If there is no transaction, the container will start a new one.

q       TX_REQUIRES_NEW.  The container will always create a new transaction when invoking this method.

q       TX_MANDATORY.  The method can only be invoked if a transaction exists; however, the container will not create a new transaction before invoking the method.  If the method is called without being part of a transaction, the call will fail.

q       TX_NOT_SUPPORTED.  The method does not participate in a transaction.  A transaction may be in place when calling the method, but the method will not rollback if the transaction fails.

q       TX_BEAN_MANAGED.  The programmer has written the method to handle its own transaction using the Java Transaction API. Because this option takes transactional control away from the container and moves it into the bean this is not a recommended approach.

Security

The deployment descriptor contains information about how specific users may access the bean.  A programmer may set up access control lists that define who can use a specific bean and how they can use it.  Security may be applied at the bean, and the method level.  So a user may have access to an entity bean, but be unable to make changes to it.

While many application servers support authentication and encryption in addition to access control, access control is the only security component that is required by the Enterprise JavaBeans specification.

Persistence

For container-managed entity beans, the deployment descriptor contains information about which attributes are handled by the container.  Some application servers also add information about how the fields are stored.