Hi Peter-
I don't see a compelling reason to use Entity Beans if you're using
an object database for persistence, unless container portability
is a significant and practical requirement. I should mention that
I have been using GemStone/J for quite a while, but have no direct
experience with ObjectStore or Jasmine.
The behavior imputed to entity beans by the EJB spec falls into four
categories (hopefully we can avoid quibbling over my categorization,
I don't intend it as any "official" categorization, but set me straight
if you must):
1) Lifecycle methods: ejbCreate, ejbPostCreate, ejbRemove
2) Finder methods: findByPrimaryKey, etc.
3) State management methods: ejbActivate, ejbPassivate, ejbLoad, ejbStore
(maybe state "synchronization" callbacks is a better term...)
4) Business methods: getters, setters, other interesting behavior
First, with the exception of #4, an entity bean's behavior is largely
oriented toward managing the persistent state of the "entity" and toward
locating the entity in persistent storage. In an ODBMS, we have alternate
ways of accomplishing these tasks that are often simpler.
For example, in GemStone/J (GSJ), there really isn't an I/O process
associated with loading or storing an object, and the state management
callback methods would end up being no-ops. The persistence of an
object in GSJ is a function of that object's reachability from an
already-persistent object, a concept known as "persistence through
reachability". In other words, to persist (store) an object in GSJ,
I can just associate the object with another that is already persistent
(e.g., by adding the object to a persistent collection, or by establishing
an object reference from an instance variable of an already-persistent
object to the to-be-persisted object). There is no process of reading
the state into/out of the object; its just stored as an object. My "data"
is in my domain objects and I directly store my domain objects.
Creating objects would just involve invocation of constructors or
other factory behavior.
Removing an object is the converse of storing one in GSJ. Simply make
the object unreachable from any other persistent object.
Finding an object in GSJ is done through a standard JNDI lookup.
So, if we are contemplating using entity beans for the purpose of
availing ourselves of their lifecycle, finding and state management
behavior, we probably don't stand to gain a lot over the facilities
already provided by the ODBMS.
Second, I don't think entity beans are either equivalent to, or suitable
replacements for, domain objects. It seems to me that entity beans are
more coarse-grained than domain objects. I subscribe to the notion that
entity beans ought to represent (and facade) little graphs of cohesive/
related domain object - not merely conceptually, but in implementation.
For example, a PersonBean might facade a Person domain object with its
associated Address and TelephoneNumber domain objects. In its role as
a domain object graph facade, an entity bean's "business methods" are
relegated to simply delegating to the domain object(s) which actually
implement the interesting business method behavior.
This is the "entity beans as domain object graph" concept, which I realize
is not a concensus position, but has been a point of convergence for a
segment of the entity bean-consuming population. Have a look at
http://www.c2.com/cgi-bin/wiki?HowToUseEntityBeans for more info.
Third, in terms of modelling capabilities, I think good old-fashioned
domain objects are easier and less constraining than entity beans.
Inter-entity bean associations are currently problematic, since they
generally require associations between entity beans to be constructed
from, and deconstructed to, foreign key references. I'd rather be
able to just maintain an object reference and not have to incur the
cost of looking up related objects or reducing related objects to a
foreign key reference at runtime. Then there's multiple cardinality
relationships...
Richard Monson-Haefel's book, _Enterprise Java Beans_, covers the issues
surrounding entity bean relationships on pp. 269-279. BTW, the EJB 1.1
spec apparently opens the door to more direct support for one entity bean
containing another.
Fourth, entity beans are remotable. The EJB spec provides that inter-bean
interactions must be treated as if the beans are remote from one another,
even if the beans really are in the same VM. This provision supports the
location transparency goal. If my session beans have to interact with
domain object *through* entity beans, all of those interactions will be
remote. So, it's actually worse than a single additional message send
(the delegation from entity bean to domain object). The messages must
traverse the full glory of the remote messaging infrastructure.
So, on balance, the tradeoff between the cost of entity beans and the
benefit of entity beans in an ODBMS-based EJB server seems, to me, to
tip in favor of not using entity beans.
I actually do think there are some potential reasons to use them
in the context of an ODBMS. See, for example,
http://www.c2.com/cgi-bin/wiki?SearchResultAsEntityBean.
Hope this is useful to you.
Dave Muirhead
[As for GSJ, see http://www.gemstone.com]
===========================================================================
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".
