The thing I would look to have satisfied by the spec architecturally
is the following - support both a pure data model and object model
so the EJB layer can act as a complete facade. I would look to design
dependent objects so that the data modeler need not bastardize his
design to support EJB and likewise the object modeler. Maybe this
is not possible but my guess is that the dependent objects were
introduced in this vein.
>From: Dan Christopherson <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Article on dependent objects
>Date: Thu, 1 Mar 2001 23:44:52 -0600
>
>On Thu, 1 Mar 2001, Gene Chuang wrote:
>
> > In the same vein with the ejbRemove issue is the inconsistent definition
>of
> > ejbCreate between session and entity beans.
> >
> > EntityHome.create() is used to create a brand new row, while
> > SessionHome.create() is used to grab an available session bean.
> > SessionBean.ejbCreate() is ALWAYS invoked when a client wants a session
>Not quite. ejbCreate is always invoked at some point before a business
>method is invoked - for stateless sessions, it is only called when an
>instance is added to the pool.
>
> > bean, but EntityBean.ejbCreate() is not; hence most beginner EJB
>developers
> > (I'll be the first to admit I fell into this trap ;-)) would put
> > initialization codes in both Session and Entity ejbCreate() and puzzle
>over
> > why initialization is done consistently on Sesison beans but
>sporatically on
> > Entity beans!
>I don't think the ejbCreate callbacks are so bad: they're called when a
>bean is created. What's probably confusing to people is the entity
>lifecycle: just because there isn't an object instance in memory that is
>identified as a particular entity doesn't mean that that entity doesn't
>exists. The entity EJB lifecycle is similiar to the lifecycle of objects
>in an ODMG compliant database - in the ODMG Java binding, constructors
>were to be called only when a persistent object was actually created, not
>when the object was merely fetched from the persistent store. I think this
>is perfectly parallel with ejbCreate on an entity, and that is the actual
>source of confusion.
>
>I guess what all that says is that your entity initialization _does_ go
>into ejbCreate, and it is called when the entity is created, quite
>consistently and not sporadically: the problem is in how you define
>'create' and 'initialization'.
>
> >
> > The solution to this would be to rename SessionHome.create() to
> > SessionHome.find() or something more apropo.
> >
> > Gene
> >
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > To: [EMAIL PROTECTED]
> > Sent: 3/1/01 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".
> >
>
>--
>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".
>
>===========================================================================
>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".
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.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".
