Thanks for posting your analysis, Dan. I'd seen the article and had many
of the same reactions (although I haven't written any code implementing a
2.0 persistence manager 8^}) )
I'm glad to see some good discussion on this list. Now if i survive all of
the bounces I get from sending this...
Comments in line below.
-danch
> 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).
Yes, this comes up about every couple of weeks on the JBoss lists.
> 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."
I don't recall being particularly confused by the 2.0 spec. Overwhelmed,
maybe, but not confused. Or maybe i'm just too dense to be confused
by it. Really, the notion of building a dependent object class just like
the entity except without interfaces seemed pretty natural. Having a spec
that allowed CMP to work with that was really great.
>
> 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.
I agree with you, dan. The life of a dependent object is bound by the life
of its parent - it cannot exists if its parent doesn't exists. This does
not mean that a dependent must suddenly exists as soon as its parent comes
into existence. That's just silly.
>
> (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.
Again, I find that writing dependents like entities without interfaces
makes sense.
>
> 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.
The only real problem I have with the 2.0 spec. persistence model is that
it requires code generation. Note that this is an aesthetic objection
only: I feel that a model that allowed for persistence managers to
support entities without generating code would be more elegent. I could
be persuaded otherwise, if someone were to give good technical arguments,
but I really don't like waiting for code to be generated, and using
preprocessing tools on my beans as part of the deployment process feels
like banging rocks together. I'm just spoiled by JBoss, I guess.
Do you really think that getting rid of dependent objects would improve
the spec? I'm not seeing it, but maybe I should just stop worrying and
love the bomb 8^}).
>
> 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".
>
--
Dan Christopherson (danch)
nVisia Technical Architect (www.nvisia.com)
Opinions expressed are mine and do not neccessarily reflect any
position or opinion of nVISIA.
---------------------------------------------------------------------------
If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
-Eben Moglen
===========================================================================
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".
