Entity Beans & Persistence Chris Alexander CS 486 Spring 2001

Completing the Sports Team Example n Begins on pg 998 n 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 n 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 n The implementation of the Entity Bean class (from javax.ejb.EntityBean) is the one that actually implements the business methods of the remote interface. n A name mapping automatically occurs from the remote interface through the container to your entity bean class.

Sports Team n The client code for testing the Entity Bean is on pg n 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 n The table in the underlying DB must be present if BMP is used n For CMP, it is container implementation specific if a table is required or not. n Many EJB containers create the table on the fly if one doesn’t exist (for CMP). n Deploytool for J2EE creates and drops the tables upon deployment and undeployment of the application (this is customizable though)

Notes cont. n There is a section on how to deploy EJB’s with the Orion application server (pg 1002) (

Relationships n The technique that models DB records in objects is called Object/Relational mapping. n For BMP, it is up to the Bean developer anyway to implement all DB accessing code. n For CMP, the spec says that the container should handle one-to-one relationships at a bare minimum n There is no standard way of handling relationships (EJB 2.0 tries to fix this though)

Completing the Manufacturing Example n The Order Bean –Pg –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 n 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 n The Order Bean has a public key made up of two ints, a sales division and an order # n The public key class must have a manditory no arg constructor and provide an implementation of hashCode() and equals() methods n 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 ( ) n Any Remote Interface must extend EJBObject and not be directly implemented n All business method stubs that the client can call go here n All Business methods must throw at least RemoteException because any application client that calls these will probably use RMI n RemoteException is thrown when any network problems occur

OrderEJB class ( ) n 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. n There are 2 create() methods –The create() methods that are implemented follow a naming convention ejbCreate() ejbPostCreate()

ejbCreate() n 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) n 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() n 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 ( ) n This declares both create() methods which are called “create” instead of ejbCreate() n 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) n 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) n Again, must extend EJBObject and throw RemoteException n There are seven business methods

ProductEJB class ( ) n The only life cycle method of importance is ebjCreate() n The others let the container manage the persistence by itself n 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 ( ) n All Beans (Session and Entity) are enclosed in tags n Session Beans are enclosed in tags n The Session Type (Stateful or Stateless) are enclosed in tags n Entity Beans are enclosed in tags n Entity Bean Persistence Types are enclosed in tags

Execution n The execution of the Manufacturing Example requires the Orion application server. n The details of how to run the example occur on pages

Recap n Remember where we are in the model

Recap n Remember, the EJB programmer’s main responsibility is to write business logic. n The EJB specification tries to relieve us of any system level tasks. n 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 n 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 n Remember, Entity Beans provide an object oriented representation of data. n 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 n Entity Beans can be thought of as a proxy to the database data. n The create() method of the Home Interface for an Entity Bean essentially inserts a record into the DB n The create() method for a Session Bean creates an instance of that Bean in the container’s temporary storage

create() n 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. n The create() method of the Home Interface must throw java.rmi.RemoteException and javax.ejb.CreateException

create() n Entity Beans need not have any create() methods at all. n This would be the case if no new data will be inserted into the DB.

CRUD callbacks n In order for the container to manage persistence, the CRUD callbacks are used –CreateejbCreate() –ReadejbLoad() –UpdateejbStore() –DeleteejbRemove()

ejbRemove() n 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. n 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 n BMP Callbacks are used to allow the Bean developer to control all the persistence manually n CMP Callbacks (with the exception of ejbCreate()) are used only to fine tune the container’s operations n Persistence is greatly improved in the EJB 2.0 specification

Creating an Entity Bean in deploytool n 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 n Click on Enterprise Bean button on the tool bar n The wizard will pop up n Enter the name of the JAR (can be anything) into the JAR display name field n 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 n Click next n In the bean type area, click on Entity n Select the Home, Remote, and Bean classes in the appropriate pull down menus n Give your entity bean a name also here n Click Next

Continued n This screen is where you will select either BMP, CMP 1.1, or CMP 2.0 n Since we are talking about CMP 1.1, click that n Check all the fields you want persisted into the DB n 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 n The next few windows deal with outside references to other EJBs or environment issues such as security, these can be left blank for now n 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 n 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. n This significantly decreases deployment time and takes away any errors that might be introduced if the deployment descriptor is written by hand.

Finishing n The only thing the developer needs to provide is the SQL code that the container will use to access the DB. n 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 n Make sure Cloudscape is running then hit OK n Then click on Generate Default SQL… n This will generate almost all SQL code for the bean n 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 n Remember to re-save the application. n This takes a lot of the hassle out of the programmers hands by generating the deployment descriptor on the fly. n Either a servlet or an application client can be added into deploytool to test the EJB.

Thank You Questions...