This chapter is from the book
This chapter is from the book
This chapter is from the book
Design Guidelines
Using entity beans is a practice that many users of application servers do not want to venture into. Part of this is due to the lack of understanding; the other part is due to the lack of capabilities in earlier versions of the EJB specification. As we look at entity beans, keep in mind two important considerations when designing the architecture:
Using local interfaces versus remote interfaces
Container managed persistence versus bean managed persistence
Use the Local Interface
When accessing data remotely, the result of the data has to be moved from one location to another, thus, data has to be serialized. This process of serialization is expensive. In other words, the latency of serializing data, sending it over the wire, and rematerializing the data on the client can be time consuming. With the introduction of EJB 2.0 specification, the capability to call and communicate to an entity bean with a local interface was defined.
Inspiration
The inspiration of local interfaces is specifically to address the performance issues related to serializing data. With the use of session façades or the use of value objects, the need for network ubiquity and serializing data has become less important. Without the need for serialized data, an alternative was needed. This alternative is to pass data by reference rather than value. In other words, instead of copying/ serializing the data, a reference to the data is passed.
Inner Workings
The inner workings of this change in the design are rather simple. If the entity bean runs within the same process, you can access the entity bean using its local interface and pass all data by reference rather than value. There is a drawback to using this method of communication: You lose the concept of network ubiquity. In other words, the client needs to know the location of the bean you want to use, but you gain what was lost in higher performance throughput.
Use CMP Before BMP
When I first started to use J2EE servers, the idea of letting the container manage all the persistence for me seemed unsettling. So I found myself developing persistence code. The process was neither desirable nor ultimately a good, efficient process for developing large-scale applications. I was developing huge portions of code that did nothing other than save, read, and remove instances of data. They were virtually identical except for the details of the SQL statements and member attributes.
Inspiration
With the changes in the EJB specification from 1.1 to 2.0, container managed persistence became all the more important and powerful. Without these necessary changes to the specifications, many developers found that most uses of CMP were limited to simple persistence.
Inner Workings
Container managed persistence supports most of the persistence requirements that any enterprise application needs. Using the container for accomplishing these tasks is not only quicker to develop, but the performance is usually better. If those two reasons are not enough, container managed persistence is by far the most portable of the components within the J2EE architecture.