1 / 48

Entity Beans & Persistence

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

tamas
Download Presentation

Entity Beans & Persistence

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

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

  40. Thank You Questions...

More Related