I've been thinking of similar issues, though more in terms of general
distributed computing in Java than specifically in EJB. I'm attaching a copy
of a paper I'm constantly revising, in the hopes of someday making my
thoughts concrete to myself. It's about "generic immutable-value classes" in
Java, and using them to add multi-return value semantics to Java. I believe
a more general problem exists than the one you are describing, and this
paper attempts to describe the problem as well as present one possible
solution.
I'd appreciate your thoughts. (Open document in "read-only" mode, and please
forgive glaring grammatical or spelling errors.)
Brian Maso
Blumenfeld & Maso, Inc.
-----Original Message-----
From: Ed Roman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, July 01, 1999 9:51 PM
Subject: EJB value objects
>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".
>
>
Adding Multiple Return Value Semantics to Java.doc
