Java Reference
In-Depth Information
typically a remote call that requires using a network resource. (The local EJB specified in EJB 2.0 is an
exception). Even the entity bean caches the object state and therefore does not need to access the
database every time; the network trip from the client box to EJB container box cannot be avoided. A
client of an EJB needs to be aware of this potential performance hit when using an entity bean. More
important, entity-bean developers should consider this when designing and developing an entity bean.
You must look at how the bean's clients might use the methods in the bean's remote interface and then
design the bean to be used efficiently and effectively.
For certain applications, most of the clients may typically want access to only a few attributes of the
bean (or columns in a row of a database table), and they may usually only retrieve or update only one or
two attributes per interaction. That means that in the yacht club example, a given client may want to see
the member's ID and membership_year; another client may want to see only a member's phone and
e-mail; yet another client may only want to see a member's street_address, city, state and
zip_code .
In this situation, you can design the entity bean to promote individual access to each persistent attribute.
You design the bean's remote interface just as I do in the MemberEJB 's remote interface: there is a
separate getter and setter for each attribute. To address the real-life scenario, you add getters
and setters for other attributes such as streetAddress, city, state, zipCode, country,
phone, fax, e-mail, lastDuePaymentDate, spouseName , and so on.
In most real-life situations, it is difficult to predict how the clients will use the EJB. If an entity object has
many attributes, it is unrealistic to assume that the client only needs very few of them for every
invocation. If clients normally need most of the attributes when they invoke a bean's business method,
the multiple network trips may cause significant performance overhead. In addition to multiple network
trips, this approach has the following drawbacks:
 
Transaction overhead. The EJB architecture recommends letting the EJB container handle
transaction demarcation. Notice that each method invocation involves a separate transaction and
that the EJB container must perform some house keeping work such as calling ejbLoad and
ejbStore . If several attributes need to be updated, the separate methods cause the EJB
container a lot of unnecessary work. Although it is possible for the client to get around this by using
client-side transaction demarcation, the client developer must write transaction code that violates
the sprit of EJB architecture.
 
Difficulty in validating business logic. It is difficult to validate business logic when such
validation requires more than one attribute value. For example, suppose you need to add a new
business logic to the MemberEJB that invites the member and the member's spouse to a party if
the member has paid his due in the past month and lives in a specific city. Inside the
inviteMemberCouple method, you have to have code to check lastDuePayment , city , and
spouseName (to make sure it is not empty). This requires three invocations of the getter method.
For a large-scale system, since the entity objects are shared by many clients, the three separate
setters may have the risk of certain temporary data inconsistency.
A recommended practice to overcome such drawbacks is to use a value object. Rather than accessing
each entity attribute individually, you can set up your entity bean's remote interface to access all
attributes in one call. Essentially, the client makes one request to either retrieve or update all the
attributes of the bean instance. All persistent attributes are accessed via one remote call and within one
transaction. This reduces the network and transaction overhead to a minimum. This approach is
especially suitable for situations where clients generally require access to most (or even all) of the
attributes at the same time.
To access all persistent attributes in one method invocation, your entity bean uses a value object. A
value object is nothing more than a JavaBean, that is, a Java class with public getters and setters
that implement the Serializable interface. You basically remove the individual getters and
setters from the remote interface (and from the implementation class) and place the equivalent
methods in the value object class. Then you add methods to the EJB remote interface: one to retrieve
the entire value object and the other to set new values. Of course, you include the implementation for
these new methods in the EJB's implementation class.
Search WWH ::




Custom Search