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".
