Here's something I've been ranting about for awhile.
The Setup
Let's say we have a Web-based E-Commerce deployment spanning the following
tiers:
- A desktop browser (Netscape)
- A Web server (JSP or servlets)
- An application server (containing enterprise beans)
- A database.
Important: each of these tiers is separated by a physical machine boundary.
The Scenario
Let's say we have a catalog servlet, responsible for showing a catalog of
products to the user. The product data is stored in the database. Rather
than accessing the database directly, the catalog servlet uses enterprise
beans to represent the products as in-memory objects. Specifically, we have
a Product entity bean that represents a row in the database.
The Problem
The catalog servlet needs to retrieve and display all the products so it can
display them to the user. The product's name, the product's SKU#, the
product's cost, and the product's description need to be loaded. How does
the catalog servlet retrieve this information from the product entity bean?
One way is if we define get() methods on the product bean. For example, we
could have a getProductName() method, a getProductCost() method, a getSKU()
method, and a getDescription() method. The problem here is the servlet
needs to perform a remote method invocation for each get() method, resulting
in a network bottleneck.
So, for efficiency, we'll define a bulk accessor method, called
getProductInfo(). getProductInfo() will return EVERYTHING in the product,
including the product's name, the cost, the SKU #, and the description.
This sounds like it will solve our problem. But unfortunately, it requires
some coding:
1) We need to write a 'holder' class that will hold our product info when
it's sent over the wire:
public class ProductInfo implements java.io.Serializable {
public String productName;
public Float productCost;
public String SKU;
public String description;
}
2) We need to write the getProductInfo() method. It will look something
like this:
public class Product implements javax.ejb.EntityBean {
// Container-managed fields
public String productName;
public Float productCost;
public String SKU;
public String description;
...
public ProductInfo getProductInfo() {
ProductInfo info = new ProductInfo();
info.name = this.name;
info.productCost = this.productCost;
info.SKU = this.SKU;
info.description = this.description;
return info;
}
}
3) For symmetry, we should probably also write a setProductInfo() method.
This sure is a lot of coding. And it seems like almost every application
will need value objects. In fact, The Theory Center
(http://www.theorycenter.com), an enterprise bean provider, has exactly this
functionality in each of their enterprise beans.
Proposed Solution
I think we should add to the EJB specification a standard way to
automatically extract state from an entity bean, and automatically import
state back into an entity bean. In our product example, there should be a
built-in way to extract product info from a product entity bean, and marshal
that data to remote clients. The container should automatically generate
the value object classes, and automatically fill-in getProductInfo() and
setProductInfo() methods. This will save the developer time, adding to the
rapid application development EJB value proposition.
Open Ended Issues
- When you're extracting state from an entity bean, it may refer to other
entity beans. Should the entire graph of entity beans be packaged up and
send to the client as a value object? Perhaps a deployment descriptor
setting as part of relationships in EJB 2.0 could specify this. We could
have a boolean flag indicating whether a referenced entity bean should be
marshaled or not.
- What should be the on-the-wire format of value objects? I believe this
should be up to the container vendor. The on-the-wire format could be
serialized bit-blobs, or they could be compressed XML documents sent between
corporations.
--
Ed Roman
CEO, The Middleware Company
Author, "Mastering Enterprise JavaBeans and the Java 2 Platform, Enterprise
Edition"
(published by John Wiley & Sons, 1999)
http://www.middleware-company.com
[EMAIL PROTECTED]
512-346-7994
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
