Entity Beans & Persistence

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

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 doesn’t 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 EJB’s 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 doesn’t 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 Bean’s 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 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

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

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

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 container’s 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 Bean’s 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 container’s 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 -> New -> 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

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

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

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)

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.

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

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

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