Entity Beans & Persistence

Chris Alexander

CS 486

Spring 2001

Completing the Sports Team Example

Begins on pg 998 The Remote Interface does not change whether the

Entity Bean has Container or Bean Managed Persistence– This is good because the bean developer needs

to write only to one specification The Remote Interface should never be directly

implemented– The remote interface is used by an application client or a

servlet and contains the stubs for the business methods

Sports Team Continued

The implementation of the Entity Bean class (from javax.ejb.EntityBean) is the one that actually implements the business methods of the remote interface.

A name mapping automatically occurs from the remote interface through the container to your entity bean class.

Sports Team

The client code for testing the Entity Bean is on pg 999-1000

Pseudo-code:

– Set initial properties for JNDI context (Orion specific)

– Look up the Bean’s home interface

– Create a new Sports Team

– Add more data

– Find record by an owner name

– Print the record if found or a message otherwise

Sports Team Notes

The table in the underlying DB must be present if BMP is used

For CMP, it is container implementation specific if a table is required or not.

Many EJB containers create the table on the fly if one doesn’t exist (for CMP).

Deploytool for J2EE creates and drops the tables upon deployment and undeployment of the application (this is customizable though)

Notes cont.

There is a section on how to deploy EJB’s with the Orion application server (pg 1002) (www.orionserver.com)

Relationships

The technique that models DB records in objects is called Object/Relational mapping.

For BMP, it is up to the Bean developer anyway to implement all DB accessing code.

For CMP, the spec says that the container should handle one-to-one relationships at a bare minimum

There is no standard way of handling relationships (EJB 2.0 tries to fix this though)

Completing the Manufacturing Example

The Order Bean– Pg 1008-1009– It has another reference to another EJB

• public Product productOrdered;• This is no problem• The Order and Product beans are related one-

to-one

Order Bean

There are five static variables– Entity Beans only allow static variables if

they are Read-Only– Since many clients can access Entity

Beans, Read-Write static vars would result in some synchronization by the container which it doesn’t do.

Order Bean

The Order Bean has a public key made up of two ints, a sales division and an order #

The public key class must have a manditory no arg constructor and provide an implementation of hashCode() and equals() methods

The two keys must be public so the container can directly access them without going through accessor methods (which you can still have if you want)

Remote Interface (1009-1010)

Any Remote Interface must extend EJBObject and not be directly implemented

All business method stubs that the client can call go here

All Business methods must throw at least RemoteException because any application client that calls these will probably use RMI

RemoteException is thrown when any network problems occur

OrderEJB class (1010-1013)

The OrderEJB class is the class that implements the business methods of the Order Remote Interface and also the callback methods of the Bean’s lifecycle.

There are 2 create() methods– The create() methods that are implemented

follow a naming convention• ejbCreate()• ejbPostCreate()

ejbCreate()

The ejbCreate() method will return the Bean’s public key (either a class if two or more key components, or any serializable class if one key component)

The ejbPostCreate() is called after the ejbCreate() method– It is used for any specialized work that may

need performed after an Entity Bean is created– Normally not used and returns void

ejbCreate()

In this specific example– One takes a String for a product and one

takes a Remote Interface• The String version is used to find an EJB that

has its primary key equal to the String.• The Remote Interface version is a convenience

method in case the client already has a reference to the Product Bean

The Home Interface (1013-1014)

This declares both create() methods which are called “create” instead of ejbCreate()

Also declared 3 “finder” methods for looking up Entity Beans from the DB (just like a query).– The finder methods are declared

implementation specific for the container– For the Orion server, the finder method has

an entry in the Deployment Descriptor

The Product Bean (1014)

Note this contains a linked list of RoutingInstructions class– To be spec compliant, RoutingInstructions

and the liked list class must be serializable

The Remote Interface (1016)

Again, must extend EJBObject and throw RemoteException

There are seven business methods

ProductEJB class (1016-1017)

The only life cycle method of importance is ebjCreate()

The others let the container manage the persistence by itself

Reminder: If BMP was used, all the DB accessing SQL (JDBC) code would go into the lifecycle methods of the Entity Bean

Deployment Descriptor Highlights (1018-1021)

All Beans (Session and Entity) are enclosed in <enterprise-beans> tags

Session Beans are enclosed in <session> tags The Session Type (Stateful or Stateless) are

enclosed in <session-type> tags Entity Beans are enclosed in <entity> tags Entity Bean Persistence Types are enclosed in

<persistence-type> tags

Execution

The execution of the Manufacturing Example requires the Orion application server.

The details of how to run the example occur on pages 1021-1025.

Recap

Remember where we are in the model

Recap

Remember, the EJB programmer’s main responsibility is to write business logic.

The EJB specification tries to relieve us of any system level tasks.

It does this in exchange for the programmer to structure their code in a particular way.– Naming conventions– Argument lists– Deployment Descriptors– Container Callbacks

What the bean programmer has to do

There are three Java files that the Bean programmer must create– The Home Interface– The Remote Interface– Your Bean class(es) that contain the

business logic and the required container callbacks

• In the case of Entity Beans, your class will implement javax.ejb.EntityBean

Entity Beans

Remember, Entity Beans provide an object oriented representation of data.

They are a shared, transactional state verses a private, conversational state in Session Beans– What this means is that Entity Beans provide

a single access point for data that all clients will use compared to Session Beans where they are accessible only to a single client

Entity Beans are just rows in a DB

Entity Beans can be thought of as a proxy to the database data.

The create() method of the Home Interface for an Entity Bean essentially inserts a record into the DB

The create() method for a Session Bean creates an instance of that Bean in the container’s temporary storage

create()

The create() method of the Home Interface returns the Remote Interface of the Bean where as the ejbCreate() method in the Bean implementation returns the Primary Key of the Bean.

The create() method of the Home Interface must throw java.rmi.RemoteException and javax.ejb.CreateException

create()

Entity Beans need not have any create() methods at all.

This would be the case if no new data will be inserted into the DB.

CRUD callbacks

In order for the container to manage persistence, the CRUD callbacks are used– Create ejbCreate()– Read ejbLoad()– Update ejbStore()– Delete ejbRemove()

ejbRemove()

An important note to realize is the client should NOT call remove() on an Entity Bean unless they want to remove that record from the DB.

This differs from a Stateful Session Bean’s remove() method where the container discards the Session Bean instance from its temporary storage thus ending the session.

BMP/CMP

BMP Callbacks are used to allow the Bean developer to control all the persistence manually

CMP Callbacks (with the exception of ejbCreate()) are used only to fine tune the container’s operations

Persistence is greatly improved in the EJB 2.0 specification

Creating an Entity Bean in deploytool

Assuming…– you have created an application by

clicking on File -> New -> Application and running through the wizard

– You have the source code for the Home, Remote, and Entity Bean compiled into class files

Creating an Entity Bean in deploytool

Click on Enterprise Bean button on the tool bar

The wizard will pop up Enter the name of the JAR (can be anything)

into the JAR display name field Click on add that is to the right of the window

and select the Home, Remote, and Bean .class files to add them to the JAR

Continued

Click next In the bean type area, click on Entity Select the Home, Remote, and Bean classes

in the appropriate pull down menus Give your entity bean a name also here Click Next

Continued

This screen is where you will select either BMP, CMP 1.1, or CMP 2.0

Since we are talking about CMP 1.1, click that Check all the fields you want persisted into

the DB Enter the primary key class type (any

standard serializable object or one of your own) and select the primary key field of your bean

Continued

The next few windows deal with outside references to other EJBs or environment issues such as security, these can be left blank for now

In the Transaction Management window, select Required for all the business and finder methods in your bean. The other methods can be left as Not Supported (per documentation)

Continued

In the next window is where the magic occurs. No deployment descriptor is needed to be written by you. It is taken care of by deploytool.

This significantly decreases deployment time and takes away any errors that might be introduced if the deployment descriptor is written by hand.

Finishing

The only thing the developer needs to provide is the SQL code that the container will use to access the DB.

Most of this is done for you also– Click on the bean in the left window and

then click on the Entity tab on the right– Click Deployment Settings…– Click on Database Settings and enter

jdbc/Cloudscape for the JNDI name

Finishing

Make sure Cloudscape is running then hit OK Then click on Generate Default SQL… This will generate almost all SQL code for the bean The only thing needed is for you to provide the

WHERE clauses for the finder methods– ex: SELECT “name” FROM “myTable” WHERE

“phone” = ?1– The ?1 corresponds to the 1st parameter in the

finder method

Finishing

Remember to re-save the application. This takes a lot of the hassle out of the

programmers hands by generating the deployment descriptor on the fly.

Either a servlet or an application client can be added into deploytool to test the EJB.

Thank You

Questions...