Sean,
Thanks a lot, Sean, for these information.
Local entities looks to be a step forward in the right direction,
but I am still frustrating with this solution. Here is why:
1-- Dependent objects
---------------------
The concept of dependent object is really important: entity model
imply a per object management of the persistent data.
Dependent objects are used to optimized the O/R mapping-layer-to-RDBMS
communication: the granularity of access, loading and storage are no
more individual objects, but object graphs.
Most of the J2ee projects need to turn the entities
to BMP to manage dependent object graphs and lost a part of
the J2EE productivity gain with JDBC level coding.
2-- Persistence API
-------------------
Local entities sound as a local persistent API. Which is great.
But, Is the entity pattern (Home, ejbLoad, ejbStore) is the best
persistence API? I don't think so.
Instead of local entities, most of the projects need a clear and standard
persistence API in charge of the O/R mapping and caching.
This persistence layer must be reachable from Entity EJBs and EJB session
services as well, and is a local, non-distributed API.
--------- --------------------------------
| Entity | | Session (Stateless services) |
---------- --------------------------------
| |
V V
---------------------------------------------
| Persistence API |
| (local entities, JDO?) |
| O/R mapping, caching, ctx management |
---------------------------------------------
With this solution, the persistence API become a new chapter
in the EJB spec, with a clear separation between the concepts
of remote-entity and persistent ojects.
The Java API to access to such persistence service is JDO.
What is the status of JDO in the new release of the spec?
What are the arguments of choosing between JDO and Local entities?
Cheers,
Thibault Cuvillier
http://www.valtech.com
>-----Original Message-----
>From: Sean Neville [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 08, 2001 8: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".
