That's the core problem with EJB entities which mix-up distribution and
persistence in the same concept.
I'd like to see the persistence related points in the spec moved from the
chapter "Entity" into a the chapter "Persistence".
J2EE must integrates persistence API such as JDO.
So, I 100% agree with John: Entities should be designed in the JEB spec as a
"Distributed facade" to the persistence layer.
IMHO, EJB 2.0 do not solve this problem, and probably add more confusion.
>-----Original Message-----
>From: John Harby [mailto:[EMAIL PROTECTED]]
>Sent: Friday, March 02, 2001 2:51 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Article on dependent objects
>
>
>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".
>
===========================================================================
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".
