Discussions

EJB design: Using hashtable to return data instead of VOs

  1. We need to produce jsp's with specific data of a EJB. If we create one VO for each screen we'd be tying my web layer into the ejb layer. If I use a generic VO we'd be wasting bandwidth (we use a expensive satelite). We create a design that asks for especific data (sending a page code and retrieved in the server using reflection and xml for setting up) that populates a hashtable and then serializes it back to the client. Have someone used this design ? If this design is strange what's the best solution.

    Emerson
  2. Hi,
    I would prefer the following architecture for this problem:Create a standard VO with x properties and assign each property an index number. The VO is instantiated on both sides (both EJB and JSP layer) and uses a simple transfer class for transporting the values. This transfer class uses a byte array for storing the indexes (assuming the VO doesn't have more than 256 properties) and an object array for the values.
    This design provides a nearly transparent use of a small carrier object and needs less bandwidth, as instead of objects byte values are used for indexing the needed information.
    Here's a simple example to clarify things:

    public class SomeBeanVO {

    private Integer value; // #1
    private String name; // #2
    // more properties

    private int count; // Counts the used properties

    // Example of counting properties with setters
    public void setValue(Integer v) {
    if (value==null && v != null)
    count++;
    if (value!=null && v == null)
    count--;
    value=v;
    }

    // more getters and setter

    // This method request the data from the bean
    public Carrier getCarrier() {

    Carrier c=new Carrier();
    c.index=new byte[count];
    c.values=new Object[count];

    // encode properties
    int place=0;
    if (value != null) {
    c.index[place]=new Byte(1);
    c.values[place]=value;
    place++;
    }
    if (name != null) {
    c.index[place]=new Byte(1);
    c.values[place]=value;
    place++;
    }
    // add other properties if needed
    return c;
    }
    Carrier ret = beanRemote.getData(c);

    public SomeBeanVO(Carrier c)

    // decode c
    for (int i=0;i<c.index.length;i++) {
    if (c.index[i]==1) {
    value=c.values[i];
    continue;
    } else if (c.index[i]==2) {
    name=c.values[i];
    continue;
    }
    //...
    }
    count=c.index.length;
    }
    } // from class

    public class Carrier extends Serializable{
    public byte[] index;
    public Object[] values;
    }

    The Remote Interface of the EJB uses Carriers instead of VO, but both EJB class and client can use the standard behaviour of a simple VO, which uses the carrier for creation.

    Wishing you success,
    Markus Zywitza
  3. This line does not belong there:

    Carrier ret = beanRemote.getData(c);

    Markus Zywitza
  4. "We need to produce jsp's with specific data of a EJB. If we create one VO for each screen we'd be tying my web layer into the ejb layer."

    Your web layer is tied to the EJB layer -- it can only read/write properties which the EJB layer understands.

    VOs will tell you this at compile time, HashMaps won't.

    You can make both the Web layer and EJB layer depend on a set of interfaces which define the minimum set of properties a particular VO must have.

    Tom