Re: SV: Warning: Dependent Objects
I know it's bad form to send a me-too to a mailing list, but: Hear hear! At 07:46 09/03/2001 +0100, you wrote: >Personally, >I already hate the distinction between local and remote EJBs. >Any such distinction could be handled by a descriptor. It shouldnt force >the developer to develop different classed depending on local or remote >usage.. That sucks so bad my teeth hurt. > >WR > > > -Ursprungligt meddelande- > > Från: Jeff Schnitzer > [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] > > Skickat: den 8 mars 2001 08:56 > > Till: Orion-Interest > > Ämne: Warning: Dependent Objects > > > > > > Heads up: > > > > If you're using (or planning to use) Orion's support for EJB2.0 > > dependent objects, you should take note of this thread on the > > ejb-interest list. > > > > Jeff > > > > -Original Message- > > From: Sean Neville > [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] > > Sent: Thursday, March 08, 2001 7:34 AM > > To: [EMAIL PROTECTED] > > 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]>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>http://www.on > java.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 mist
SV: Warning: Dependent Objects
Title: SV: Warning: Dependent Objects Personally, I already hate the distinction between local and remote EJBs. Any such distinction could be handled by a descriptor. It shouldnt force the developer to develop different classed depending on local or remote usage.. That sucks so bad my teeth hurt. WR > -Ursprungligt meddelande- > Från: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] > Skickat: den 8 mars 2001 08:56 > Till: Orion-Interest > Ämne: Warning: Dependent Objects > > > Heads up: > > If you're using (or planning to use) Orion's support for EJB2.0 > dependent objects, you should take note of this thread on the > ejb-interest list. > > Jeff > > -Original Message- > From: Sean Neville [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 08, 2001 7:34 AM > To: [EMAIL PROTECTED] > 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
Warning: Dependent Objects
Heads up: If you're using (or planning to use) Orion's support for EJB2.0 dependent objects, you should take note of this thread on the ejb-interest list. Jeff -Original Message- From: Sean Neville [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 08, 2001 7:34 AM To: [EMAIL PROTECTED] 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 ==
