Entity Beans

1
Entity Beans Persistence

• Chris Alexander
• CS 486
• Spring 2001

2
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

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

4
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 Beans 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

5
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 doesnt exist (for CMP).
• Deploytool for J2EE creates and drops the tables
  upon deployment and undeployment of the
  application (this is customizable though)

6
Notes cont.

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

7
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)

8
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

9
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 doesnt
  do.

10
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)

11
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

12
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
  Beans lifecycle.
• There are 2 create() methods
• The create() methods that are implemented follow
  a naming convention
• ejbCreate()
• ejbPostCreate()

13
ejbCreate()

• The ejbCreate() method will return the Beans
  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

14
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

15
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

16
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

17
The Remote Interface (1016)

• Again, must extend EJBObject and throw
  RemoteException
• There are seven business methods

18
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

19
Deployment Descriptor Highlights (1018-1021)

• All Beans (Session and Entity) are enclosed in
  ltenterprise-beansgt tags
• Session Beans are enclosed in ltsessiongt tags
• The Session Type (Stateful or Stateless) are
  enclosed in ltsession-typegt tags
• Entity Beans are enclosed in ltentitygt tags
• Entity Bean Persistence Types are enclosed in
  ltpersistence-typegt tags

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

21
Recap

• Remember where we are in the model

22
Recap

• Remember, the EJB programmers 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

23
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

24
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

25
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 containers
  temporary storage

26
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

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

28
CRUD callbacks

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

29
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 Beans
  remove() method where the container discards the
  Session Bean instance from its temporary storage
  thus ending the session.

30
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 containers
  operations
• Persistence is greatly improved in the EJB 2.0
  specification

31
Creating an Entity Bean in deploytool

• Assuming
• you have created an application by clicking on
  File -gt New -gt Application and running through
  the wizard
• You have the source code for the Home, Remote,
  and Entity Bean compiled into class files

32
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

33
(No Transcript)
34
(No Transcript)
35
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

36
(No Transcript)
37
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

38
(No Transcript)
39
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)

40
(No Transcript)
41
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.

42
(No Transcript)
43
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

44
(No Transcript)
45
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

46
(No Transcript)
47
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.

48
Thank You

• Questions...