On an aside ... any idea how I can get off the [EMAIL PROTECTED]
email list?!
----- Original Message -----
From: "Evan Ireland" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 2:34 PM
Subject: Re: Article on dependent objects
>
>
> Dan OConnor wrote:
> >
> > 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.
>
> This makes very good reading and I recommend others to check it out.
> I concur with Tyler's comments on the 'ejbRemove' issue, but
> unfortunately this appears to be unfixable unless we force EJB users
> to change their existing stateless session bean code.
>
> > 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.)
>
> In terms of dependent objects, I think that you will be pleasantly
> surprised with the updated draft (and I hope we will be too when we
> get to see it ourselves).
>
> I think it would be wise to "wait and see" and then have a discussion
> on the next 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".
>
> --
>
____________________________________________________________________________
____
>
> Evan Ireland Sybase EAServer Engineering
[EMAIL PROTECTED]
> Wellington, New Zealand +64 4
934-5856
>
>
===========================================================================
> 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".
>
>
===========================================================================
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".
