Please accept my humble appologies to this list. The message with the rather
large attachment was meant as a private post. I accidentally posted to this
list. I hope I haven't undermined the usefulness or integrity of this list.
Again, please accept my appologies for clogging up your bandwidth.
Brian Maso
Blumenfeld & Maso, Inc.
-----Original Message-----
From: Brian Maso <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, July 02, 1999 3:49 PM
Subject: Re: EJB value objects
>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".
>>
>>
>
===========================================================================
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".
