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 oneto-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...