Building Java Enterprise Applications

Chapter 4. Entity Basics

This chapter will look at entity beans as a means of accessing the Forethought application’s data storage. I’ll begin with simple entity beans to provide application entry points to the database, and address many questions common to entity bean development. Should you pass around the entity bean? Should you access the data exclusively through session beans, or directly through the entity beans? What are details objects, façade patterns, and good principles of entity bean design? All these questions will be answered, as I discuss not just writing EJB code, but writing effective EJB code.

At the end of this chapter, you will have the first entity bean created and deployed, ready for use. More importantly, you will have a good understanding of basic entity bean programming practices; you’ll have looked at using container-managed persistence, package and class naming, handling method exposure through the remote interface, and more. In other words, you’ll be ready for any basic entity bean problem that comes along, as well as for the advanced topics I’ll address in Chapter 5.

Basic Design Patterns

To access the data that will be stored in the database, you can use EJB’s entity bean functionality. Keep in mind, however, that this is not by any means a book on how to write Enterprise JavaBeans; for that I recommend Richard Monson-Haefel’s excellent book, Enterprise JavaBeans (O’Reilly). Here, I’ll simply focus on using EJBs correctly, and detail some useful design patterns.

In addition to looking at some design patterns and actual code, you must be familiar with two technologies that are intrinsic to EJBs: RMI and JNDI. Remote Method Invocation, or RMI, is the basis of all Enterprise JavaBeans calls. In a nutshell, RMI causes a remote call to a Java object over the network^[18] to behave exactly like a local call. The Java Naming and Directory Interface, or JNDI, allows objects to be bound into a namespace and then referenced by other objects. The namespace in this case is purely an abstract concept, but organization of Java objects and information in this manner does work well; all components of an application can use this single means of storage. Of course, like any other technology, RMI and JNDI require resources. JNDI requires memory in which to store the objects bound into its contexts, and both require runtime resources to operate. For example, looking up an object in the JNDI registry is more time-consuming than referencing a local object, and executing an RMI call is more expensive in terms of resources than executing a local method invocation. As always, you must focus on logical tradeoffs, and use both technologies only when needed. As usual, you should have a good reason for everything. And now, assuming that you are comfortable with these technologies, let’s look at entity beans in detail.

First, you need to address access to entity beans (yes, I’m getting to the code; just be patient!). This might seem like a simple topic, but debates have been raging for years on various email lists concerning the means of accessing entity beans. The arguments center over whether entity beans should be accessed directly by an application (be it a servlet, Java application, or some other code fragment), or whether these calls should pass through a session bean, which then " proxies” the call to the entity bean. In the latter case, more RMI communication is involved, more JNDI lookups occur, and serialization may be necessary in passing returned values. However, accessing entity beans through some sort of proxy is still the preferred means of access.

While it might seem that I am jumping the gun, this topic will affect the way you code entity beans. First, the proxy method of accessing beans allows the entity beans to be more “basic” in nature. In other words, an entity bean can assume that the preparatory work in dealing with data, such as validation, type checking, and so forth, is done by the time it gets that data. The bean also doesn’t have to worry about data conversion, such as from a Java String into a data type appropriate for that bean. These sorts of situations are common when a servlet communicates directly with data entities, but if you assume that session beans play an intermediary role, these are not problems for entity beans. I won’t look at implementing this design pattern (called the façade design pattern) with session beans right now, but I will in later chapters. For now, it is enough to know that the application’s entity beans only need to read and write data, and that the data is appropriate for use by the time it is handed off to these beans.

---

^[18] In reality, EJB servers are often on the same physical hardware as the servlet engine making the RMI calls, especially in development. On the other hand, production environments often have EJB servers on multiple machines, requiring RMI calls between session and entity beans as well as from the servlet engine to the EJB layer. In either case, I use the generic term “network communication” to refer to any communication to the EJB layer; I’ll spend more time on this in Section 4.2.3.