外文翻译编写Bean管理持久性的实体Bean.docx

1、外文翻译 编写Bean管理持久性的实体BeanCHAPTER 8 Writing Bean-Managed Persistent Entity BeansIn Chapter 7, we covered some basic entity bean concepts. We learned that there are two kinds of entity beansbean-managed persistent and container-managed persistent.In this chapter, well demonstrate how to program bean-man

2、aged persistent entity beans. When you code these types of entity beans, you must provide your own data access logic. You are responsible for providing the implementation to map your entity bean instances to and from storage. To do this, youd typically. use a database API such as JDBC or SQL/J. This

3、 is in stark contrast to container-managed persistent entity beans, which have their data access handled for them by the EJB container. This chapter will teach you the basics of bean-managed persistence and show you how to build a simple bean-managed entity bean using JDBC.Implementation Guidelines

4、for Bean-Managed PersistenceIn Chapter 7, we saw that all entity bean classesboth bean-managed persistent and container-managed persistentmust implement the javax.ejb.EntityBean interface. This interface defines callback methods that the container invokes on your beans. What you should put in these

5、methods depends in part on whether you are using bean-managed persistence or container-managed persistence. Table 8.1 is a summary of what you should implement in each method, assuming your entity beans persistence is bean-managed. Take a quick glance at the.Table 8.1 Descriptions and Implementation

6、 Guidelines for Bean-Managed Persistent Entities.chart for now. You should refer back to the chart when reading through the code in this chapter or when programming your own entity bean classes. The order of methods listed very roughly models the flow of control of an entity bean instances life cycl

7、e that we saw at the end of Chapter 7.Bean-Managed Persistence Example: A Bank AccountOur first example will be a simple bank account entity bean. This bank account bean can be used to represent and manipulate real bank account data in an underlying relational database. The object model for our bank

8、 account is detailed in Figure 8.1.Lets take a look at each of the files that we must create for our entity bean component.Figure 8.1 The bank account object model.Account.javaAccount.java is our entity beans remote interfacewhat the client sees. Its shown in Source 8.1.Notice that the account remot

9、e interface extends javax.ejb.EJBObject, which all remote interfaces must do. Our interface exposes a number of methods for manipulating entity beans, such as for making deposits and withdrawals. All of our methods throw remote exceptions to facilitate system-level catastrophic.Source 8.1 Account.ja

10、va.failures. Notice that in our withdrawal method, we also throw our own custom application-level exception, Account Exception. Well define that exception bit later.AccountHome.javaOur home interface is specified by AccountHome.java, shown in Source 8.2.Source 8.2 AccountHome.java (continued).We pro

11、vide one method to create a new account. This will create new database data representing a bank account. It returns an EJB object to the client so that the client can manipulate that newly created account. Notice that we throw the application-level javax.ejb.CreateException, which all create() metho

12、ds must throw.We also have two finder methods. findByPrimaryKey() searches the database for a bank account that already exists; it searches by the account ID, which we will define below in AccountPK.java. We also have a custom finder method, findByOwnerName(), which searches the database for all ban

13、k accounts that have the same owners name. Because were using bean-managed persistence. well need to implement both of these finder methods in our entity bean implementation (if we were using container-managed persistence, the container would search the database for us). As with our create method, b

14、oth finders return EJB objects so that the client can manipulate the newly found bank accounts. We throw the application-level javax.ejb.FinderException, which all finders must throw.AccountPK.javaOur entity beans primary key class is defined by AccountPK.java, detailed inSource 8.3.Our primary key

15、is a simple stringthe account ID string. For example, an account ID string could be “ABC-123-0000.” This string must be unique to its bank accountwe rely on the client code that constructs our account ID to make sure its unique. The primary key is used to identify each bank account uniquely.AccountB

16、ean.javaNext, we have our entity bean implementation class, AccountBean.java. Our bean implementation code is quite lengthy, and it is divided into several sections: Bean-managed state fields. These are the persistable fields of our entity bean class. Our bean instance will load and store the databa

17、se data into these fields.Source 8.3 AccountPK.java.Business logic methods. These methods perform services for clients, such as withdrawing or depositing into an account. They are exposed by the remote interface, Account.EJB-required methods. These are EJB-required methods that the container will ca

18、ll to manage our bean. They also include our creator and finder methods defined in the home interface.The code is presented in Source 8.4. Notice how cumbersome the code isjust for a simple bank account. This is an unfortunate drawback of bean-managed persistence because you must provide all data ac

19、cess code.Notice that most of the logic in our bean is JDBC code. Our withdraw and deposit methods simply modify the in-memory fields of the entity bean instance. If the client tries to withdraw from a negative account, we throw our custom application-level exception, AccountException. Whenever we p

20、erform persistent operations, we retrieve a JDBC connection via the getConnection() method.We acquire our environment information from the EntityContext by calling getEnvironment(). We then use that environment as a parameter to the JDBC DriverManagers getConnection() method. This environment specif

21、ies the JDBC drivers to load, via the jdbc.drivers property. We specify this property in the Source 8.4 AccountBean.java (continues).application-specific environment properties that ship with our bean, as well see very shortly. We also specify the particular database to connect to via a property we

22、call JDBC_URL. This property is passed to the DriverManager as well, so it knows with which database to hook up.In our bank account example, we retrieve our JDBC connections via the JDBC call DriverManager.getConnection(). We also close each connection after every method call. This allows our EJB co

23、ntainer to pool JDBC connections. When the connection is not in use, another bean can use our connection.Although this works with BEA WebLogic server, it is not a standard, portable way for connection pooling. WebLogic performs pooling directly beneath the JDBC 1.0 driver shell, but other EJB vendor

24、s may require different mechanisms for pooling database connections. Connection pooling is unfortunately not specified by JDBC 1.0, which means that any enterprise beans that use JDBC 1.0 are not very portable.There is a light at the end of the tunnel. The new JDBC 2.0 specification, which has been

25、finalized, supports a portable mechanism of database connection pooling. Already vendors are beginning to support JDBC 2.0, and by the time you read this, most every serious relational database vendor should have a JDBC 2.0 driver. The Java 2 Platform, Enterprise Edition (J2EE) specification mandate

26、s support of JDBC 2.0 as well, which is good news for anyone writing to J2EE and the EJB 1.1 specification. Furthermore, EJB 1.1 specifies a portable way to retrieve a JDBC driver through the Java Naming and Directory Interface (JNDI), which we detail in Appendix D.Our finder methods use JDBC to per

27、form SELECT statements on the relational database to query for bank account records. We create a new primary key class for the data we find, and we return the primary key to the container. The container will then instantiate EJB objects that match each primary key, so that the clients can start work

28、ing with the data. To create a new bank account, the client calls create() on the home object, which calls our ejbCreate() and ejbPostCreate() methods. Notice that we insert some data into the database using JDBC in ejbCreate(). We also assign our member variables the data passed in from the client.

29、 We dont need to use ejbPostCreate() for anything. Our entity bean is now associated with some specific database data and is associated with a client-specific EJB object.Notice that we dont hold any bean-independent resources, so our setEntity- Context() and unsetEntityContext() methods are fairly b

30、are-boned. We also dont hold any bean-specific resources, so our ejbPassivate() and ejbActivate() methods are empty.When the container synchronizes our bean with the database, the ejbLoad() and ejbStore() methods perform JDBC persistence, thus keeping everyones data in synch. Notice that ejbLoad() a

31、cquires the primary key via a getPrimaryKey() call to the Entity Context. This is how it figures out what data to load.JDBC can be very tough to debug due to incompatibilities between databases. Its much easier to debug JDBC if you log what JDBC is doing behind the scenes. To do this, see the commen

32、ted code in the getConnection() method of AccountBean.java. Simply uncomment those lines to enable logging.AccountException.javaOur custom exception class is AccountException.java, displayed in Source 8.5. It simply delegates to the parent java.lang.Exception class. Its still useful to define our own custom exception class, however, so that we can distinguish between a problem with our bank account component, and a problem with another part of a deployed system.Source 8.5 AccountException.java.Client.javaOur last Java file is a simple test client to exercise our b