Yes, we really appreciate this. I no longer work for a vendor but as an EJB
evangelist I wouldn't like to try and explain to irate customers that the
targets had changed without their knowledge :).
>From: Jay Walters <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Article on dependent objects
>Date: Thu, 8 Mar 2001 11:01:07 -0500
>
>Thanks for sharing that with us!
>
>-----Original Message-----
>From: Sean Neville [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 08, 2001 10: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
>
>===========================================================================
>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".
>
>===========================================================================
>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".
