Ejb Dependent Value Classes

Serializable objects that are exposed in the public interface of an EnterpriseJavaBean. They are ValueObject instances, hence have no intrinsic object identity except that which is defined by equals() and hashCode().

These objects are meant to transfer data to clients, using RMI-IIOP. Alternatively, an XML data-binding of some sort could suffice.

Disadvantages:

Java's strong typing seems to encourage a duplication of effort -- they expect one to create dumb-data objects just for the purpose of transferring data over the wire, when one could easily use java.util.HashMap, though at a relative performance cost (probably not noticable until one uses thousands of elements).

On the other hand, EjbDependentValueClasses do not have to be simply "dumb-data objects". They can have behavior of their own. For instance, they could handle validation and simple business constraints that has no business being executed inside the context (e.g. the transaction context) of the Ejb itself. That, and the modeling benefits granted by having a REAL object there instead of a hash map is where the real benefits of dependent value classes come into play.

However, sometimes your application will be a mix of the two -- minimalist data collections, and/or objects with client-side logic.

A possible solution would be to use a code generator to create the Java code required for the value objects. (This would also enable you to easily use custom serialization, which might make RMI even faster).

Absolutely the right solution! And pretty soon all the IDE's will have the code generators... Also, the custom serialization (e.g. Externalization) idea DOES work in practice. We've seen up to a 50% speed improvement when coding this ourselves...

I tend to prefer dynamic solutions vs. code generated ones. The reason is that there's a duplication of effort in keeping your value classes in sync with your dependent objects / EJB's. It seems to me a OnceAndOnlyOnce violation.

To clarify, other business object frameworks like WebObjects EOF, provide all of their objects with KeyValueCoding? and RelationshipManipulation? interfaces, ( the former somewhat similar to IBM SanFransisco?'s property containers ), as a way to store attributes without the need for all of those (imho generally useless) getters & setters. One can then add validateXXX methods on attributes as needed, or for whole-object validations at the transaction level. RelationshipManipulation? will use the meta-data (i.e. in EOF their EOModel, in EJB this would be a CMP deployment descriptor) to validate the cardinalities & database constraints on the relationships.

The development speed improvement of using a dynamic object framework is even more noticable (to me) than code generation (which isn't that bad either). Just a preference, I guess, since it comes down to strong typing (code generation) vs. dynamic typing (using an internal Map, XML document and/or reflection).