Re: SV: Warning: Dependent Objects

2001-03-09 Thread Dan North

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

2001-03-08 Thread Magnus Rydin
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

2001-03-08 Thread Jeff Schnitzer

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

==