Hi,
Tyler Jewell, the BEA training director for Java and XML
technologies, yesterday published an article called "What's Wrong
with the EJB 2 Specification" at
http://www.onjava.com/pub/a/onjava/2001/02/28/ejb.html. In this
article, he identifies "dependent objects" as what is wrong with the
EJB 2 specification.
I have seen indications that container managed persistence in the
EJB 2.0 specification will be modified significantly from its
Proposed Final Draft form (see, for example, several postings to
this news group, or the comment in the release notes of the J2EE
beta). I hope that any changes to this (IMHO) excellent
specification will only make it even better. I am of course
concerned that the opposite is possible, so I hope to begin a
discussion based on Tyler's article. (I am not part of the Java
Community Process and do not have access to any work
subsequent to the proposed final draft.)
First, I would like to correct what I believe was a fairly basic
technical mistake in Tyler's article. He says, "Dependent objects
don't require primary keys." I would like to suggest that the
opposite is the case, and I cite from 9.4.4.1 in the spec (proposed
final draft): "The dependent object class instance must have a
primary key value that is unique across all instances of the
dependent object class."
Second, I would like to talk about implementations of this spec.
Tyler says: "Despite the number of vendors that have embraced the
EJB 2.0 specification, I'm not aware of a single vendor that's
implemented dependent objects, including BEA WebLogic and
JBoss Server, which are usually the most updated
implementations. It's likely that the confusion described here is felt
by others in the industry too."
It is not particularly surprising that there are no commercial
implementations of a draft specification. Some vendors have
expressed on this list a distaste for providing implementations of
draft specifications as not being in the best interest of their
customers, and I take them at their word. However, there are at
least two vendors who have implemented dependent objects for
preview to customers: Orion Application Server, and my company
MVCSoft, which provides an "educational" version of an EJB 2.0
persistence manager for (ironically) JBoss Server. I have personally
implemented the majority of the specification, and I feel confident in
saying that confusion would not defeat the engineers at any major
application server vendor, including BEA.
To be fair, Tyler may have meant that vendors have not
implemented dependent objects because they did not feel the
concept would survive to the final iteration of the specification. I can
pretty much guarantee that the JBoss community did not feel this
way at the time the EJB 2.0 proposed final draft was released. This
is significant only because he cited JBoss in particular, along with
his own company.
Tyler has three specific objections to dependent objects. They are:
(1) [Tyler:] "Dependent objects are meant to be all things to all
people." [Dan:] Specifically he is referring to their dual use as local
fine-grained objects and as objects that track the life-cycle of their
parent. I honestly don't see why this dual use is bad, so I find it
difficult to voice agreement or disagreement with this point. For that
reason, I hope some list residents choose to respond to this point
in particular (with clarifications, agreement, or disagreement).
(2) [Tyler:] "Dependent objects have a cascading delete
deployment descriptor option that instructs a container to manage
the destruction of dependent objects attached to parent objects.
This is needed to manage life cycle objects. The other
characteristic needed to support life cycle objects, an automatic
creation mechanism, does not exist, which makes the intentions of
the specification developers murky." [Dan:] It seems to me that
these two operations in the life-cycle of a dependent object are not
symmetrical. The cascade-delete rule can often be specified free
from context data (e.g. delete the line item whenever you delete the
order) but creation almost always requires context data (how could
you create the line items apart from application logic?) So I do not
find this objection compelling.
(3) [Tyler:] "Since dependent objects can only be accessed locally,
home and remote interfaces are not necessary." [snip...] "The
additional syntax that an EJB developer will have to learn will
confuse new developers." [Dan:] I have two comments in response
to this: [A] It seems to me that the inclusion of home and remote
interfaces for local objects adds unnecessary complexity to the
development process. Of course, most people will use tools to
generate them, but still there are extra files to keep in synch; to
worry about when debugging; to manage in your development
environment; and to scan through when writing and maintaining
code. Also, [B] it seems to me that providing home and remote
interfaces for local objects implies the wrong semantics. Why
provide remote interfaces for local objects? This is more likely to
confuse developers than the simple semantics of a dependent
object.
I am a big fan of the EJB 2.0 specification's persistence model.
However, there are definitely people with a different point of view.
(See, for instance, the comments on this article at
theserverside.com.) There's always room for improvement, and if a
new version of the specification were to get rid of dependent
objects (as Tyler suggests should happen) this could indeed be an
improvement. However, I'm not convinced based on Tyler's
arguments, and I would welcome comments on both sides of the
issue.
Thanks,
Dan O'Connor
P.S. Given the identity of Tyler's employer, I hope this doesn't
count as a Weblogic-specific question.
===========================================================================
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".
