I agree with what Ian says in this and his previous emails on sub-entities. We call
sub-entities
"dependent objects". As there is no EJB API for dependent objects (the container is
not aware of them), we hardly mention them in the spec. In the section on entity
beans, we
have a short discussion on how to identify a dependent object in an application design.
We recommend implementing dependent objects *not* as Entity beans, but as Java classes.
>From the perspective of the container runtime, the Java classes appear as part of the
>"parent"
Entity bean to which they are logically linked.
It would be nice to be able to defer the decision whether a component is an Entity
bean or a
dependent
component (i.e. sub-entity) to deployment time, not to be forced to hard-code this
decision at
the component development time. Although the EJB spec currently does not architect
this, I think
that a component developer can create components that can be deployed both as dependent
objects and as fully-blown Entities.
Vlada
----- Original Message -----
From: Ian McCallion <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 17, 1999 2:44 AM
Subject: Re: Using collection bean to represent a list of entity beans- wa s RE :
Application Server
container related question
> Jim,
>
> Agree with almost all you say.
>
> Your solution is an optimisation which works well if the application's
> needs are served by storing the collection of items as a "blob in the
> pstore". However in many applications the items need to be accessed
> individually eg to find how much of a particular stock is on order. In
> these cases a RDBMS (or OODBMS) that is aware of the structure of "item"
> needs to be used and that takes us back to BMP and persistence code in the
> methods (I think).
>
> The purpose of inventing sub-entity beans is to provide an
> "instantiation-independent" target for code generated directly from OO
> models. (Entities fail at this for reasons we have gone over endlessly
> here.) Sub-entity beans can be composed into different entity beans for
> different use cases. This composition step would:
> (a) define the parent subentity
> (b) group the sub-entities according to selection rule(s)
> (c) export the appropriate methods on the sub-entities as methods on the
> entity
>
> Intra-sub-entity (UGH!) calls would be highly efficient... No need for
> (smart) proxies between them as you'd be calling them directly. No need for
> spec-violating intra-vm optimisations. No need for a separate anticipatory
> loading mechanism.
>
> EJB already defines a composition step. So one could speculate that
> something like this was what Sun had in mind for EJB initially but that it
> got lost when developing the detailed architecture. The only remaining
> value-add of the composition step we have today is it allows the developers
> to declare that a particular set of EJBs is complete and ready for the
> deployers.
>
> And yes, you can share the soapbox - it's is big enough for two!
>
> Ian McCallion
> CICS Business Unit
> IBM Hursley
> [EMAIL PROTECTED]
> Tel: ++44-1962-818065
> Fax: ++44-1962-818069
> ------------------------------------------------
> Jim Frentress wrote:
> > <snip>
> >> One way to do this, using the shopping basket example again, is as
> >> follows:
> >>
> >> * Design the application so that a shopping basket,
> >> including all items in the basket, is an Entity Bean,
> >>
> > >> one of many options is to use a collection (or whatever) for
> the
> >items. these will serialize into a blob (byte[]) in the pstore.
> >
> >> * Within EJBLoad, instantiate the Basket Entity Bean by
> >> an SQL call on the "Baskets" table to load information
> >> about the basket, and an SQL call on the "Items" table
> >> to load all items in the basket.
> >>
> > >> if you use blob for "item" storage, you can use CMP as well as
> >BMP and simply deserialize/serialize the objects in ejbLoad/ejbStore. only
> >one call to the pstore loads the entire basket. i haven't run across
> >anything that persists as quickly as a byte stream.
> >
> >> * as processing of the basket within the transaction
> >> proceeds, load the individual items into simple objects
> >> (we could call them sub-entity beans) as needed and
> >> maintain a "write-back list".
> >>
> > >> with the collection, there's no need to maintain a special
> list.
> >if the basket is dirty, the items serialize and persist on one call in
> >ejbStore.
> >
> >> * Within EJBStore write back the state of objects in the
> >> "write-back list" to the database.
> >>
> > >> no need to do this. CMP does it for you by including the items
> >column to the list of CMP attributes. if you're BMP, you just add a single
> >attribute to the update statement to persist all items.
> >>
> >> Yes I know this can't be done with CMP,
> >>
> > >> CMP works perfectly with collections (or maps or any other
> >serializable structure).
> >
> >> and I know that it embeds some
> >> messy details of persistence into the methods on the bean, but its the
> >> only
> >> way, within the EJB framework, that I can see to solve some real
> problems.
> >>
> > >> i'm not sure we addressed the original question, which seemed
> to
> >be more related to the issues surrounding when to use references and when
> to
> >use copies of data on the client. in any case, this is a worthwhile
> >discussion.
>
> >> <soapbox>
> >>
> >> If you'll allow me to use your question as an excuse for drawing
> together
> >> a
> >> number of threads on the mailling list, I'd say that:
> >>
> >> 1. Agressive local optimisation of inter-bean calls
> >> that violates the EJB spec (as done by Weblogic)
> >>
> > >> if you mean optimization of intra-vm calls, this is done to
> >address the cost of out-of-process calls. WebLogic has stated publicly
> that
> >they are changing their server to be RMI (EJB) compliant but will continue
> >to allow intra-vm optimization as an option.
>
> >> 2. Smart Proxies (as per Rickard Oberg's package)
> >>
> > >> Proxy says most of what this addresses. On top of that, "Smart"
> >addresses reliability issues of network activity in general and remote
> >computing in specific.
>
> >> 3. Anticipatory loading of entity beans (not sure
> >> who claimed to do this - I think it was Gemstone)
> >>
> > >> this addresses latency between ejb server and pstore. Chris
> Raber
> >can cover the details and correct me if i'm wrong.
> >
> >> 4. My hack above
> >>
> > >> this addresses some of the issues surrounding very fine grained
> >objects.
>
> >> are all attacking different aspects of the same problem, namely the
> >> granularity of object models vs the granularity of architected
> server-side
> >> objects.
> >>
> > >> kind of. my interpretation is that they're addressing different
> >but sometimes overlapping issues related to distributed computing.
>
> >> The ideal solution, in my opinion, would be to allow every object
> >> in the model to be an efficiently callable CMP "sub-entity bean" and to
> >> compose sub-entities at deployment time into coarse-grained entity beans
> >> working approximately as I described above. Unfortunately "sub-entity
> >> beans" are not yet architected.
> >>
> >> </soapbox)
> >>
> > >> hey, wait a minute... who's soapbox is this anyway ;)
>
> ===========================================================================
> 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".
