Thought this might be of interest to people if they haven't seen it... -----Original Message----- From: Sean Neville To: [EMAIL PROTECTED] Sent: 3/8/01 10:34 AM Subject: Re: Article on dependent objects Dependent objects have already been marked for removal from the spec; moreover, local entities -- probably at least as controversial -- have been introduced both as a partial replacement for pieces of the dependent object concept and to solve the need to permit parameter pass-by-reference. I would guess that the next pfd of the spec (and probably another article from Tyler, followed by another series of intelligent reviews from Dan, Gene, and others on this list) should surface by late April, but in the interests of spreading the info as early as possible to those who don't happen to work for a vendor and thus already have this info (power to the people), here is a quick and completely unofficial description of local vs. remote EJB's as posed to us in another discussion. It is obviously subject to change, and only the EJB and J2EE specs are in any way definitive. Local ----- Access only with scope of PM No Transaction attribute No Security check Can expose CMP and CMR fields and local refs PBR parameters Local exception model Signatures use full Java type system Typically fine grained methods High coupling due to PBV side affects and fine grained exposure Remote ------ Global access Requires Transaction attribute Requires Security check Prohibits exposure of CMP and CMR fields and local refs PBV parameters Container interposed exceptions Signatures restricted to RMI-IIOP compatible types Typically coarse grained methods As loosely coupled as a procedural object can get -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Christopherson Sent: Friday, March 02, 2001 12:47 AM To: [EMAIL PROTECTED] Subject: Re: Article on dependent objects On Thu, 1 Mar 2001, Alex Smith wrote: > Dan O'Connor <[EMAIL PROTECTED]> writes: > > >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. > > Good article. I do agree that Tyler's objections are misplaced. > > >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." > > This is a mistake in the spec rather than the article -- dependent objects > should not have an identity of their own else they would no longer be > dependent. If you use a relational model to color your perception of the > world, a dependent object may or may not have its "own" (i.e. not composed > from the keys of its parent) primary key. Some data modeling methodologies > recommend creating a unique physical key for each and every entity, a > practice I don't subscribe to. On the other hand if you think in terms of > objects, a dependent object belongs to the parent and therefore cannot have > an identity other than that of its parent. I'd say that the dependent object has no identity that is meaningful outside of the context of its parent. If you have three dependent instances of the same class associated with the same parent, they must have their own identities if you do not consider them equivalent, right? > > I think the spec should provide support for dependent objects with a primary > key but not require it. > > The rest of Dan's comments are right on target. > > Alex Smith > Insight LLC > _________________________________________________________________ > 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". > -- 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". ======================================================================== === 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".
