Jim,
As Jim Frentress mentioned, it is pretty easy to roll your own scheme. The
idea is to treat both entities *and* collections of entities as "first
class" citizens. Since entity beans are no more expensive than session
beans, we use entities for the collections to take advantage of
CMP/caching/sharing and to have finer control of the bean instances. As a
matter of fact, we use session beans in our customer's architectures only
when client (or session) info has to be maintained on the server.
We don't intend to separate the collection beans from Ejipt. Ejipt through
its cache/CMP mechanism provides optimized support for handling collections.
We are in the process of finalizing samples illustrating collection bean
usage (due out at the end of the month). These samples, in addition to
providing starter code, also assist with db schema development, caching
guidelines/strategies, subclassing scenarios etc.
Imre Kifor
Valto Systems
-----Original Message-----
From: James Cook <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, May 14, 1999 12:48 PM
Subject: Re: findLargeAccounts - why bother?
>Imre, are these collection "beans" available to the developer community
>separate from your EJB container?
>
>jim
>
>----- Original Message -----
>From: Imre Kifor <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Friday, May 14, 1999 10:07 AM
>Subject: Re: findLargeAccounts - why bother?
>
>
>> I agree with your three points. Supporting your second point, I would
like
>> to add that we have been very successfully modeling collections of entity
>> beans through a generic "collection" entity bean (EJBCollection, EJBSet,
>> EJBTree etc.). Since they are not session beans, they can be shared by
>> multiple clients (Note: session beans are just as expensive (!) as entity
>> beans and require more server side processing to support timeouts).
>>
>> Our EJBCollections and their implementations can also be subclassed.
Using
>> this approach, we can easily create "Fund", "Portfolio", "Assets",
>> "Industry" etc. beans as collections of "Security" beans in our financial
>> application. All the collection manipulation operations and even our SQL
>> statements for CMP can all be shared by both the pre-defined business
>> "beans" and the ad-hoc, "what-if" scenario implementations. The ad-hoc,
on
>> demand generated collection entity objects use the query criteria as
their
>> PKs, hence they can be cached and shared with no effort.
>>
>> Imre Kifor
>> Valto Systems
>>
>> -----Original Message-----
>> From: Anne Thomas <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> Date: Friday, May 14, 1999 9:34 AM
>> Subject: Re: findLargeAccounts - why bother?
>>
>>
>> >I (along with many others on this list) am a big fan of wrapping (also
>> known
>> >as encapsulating) entity beans with session beans. This approach
>simplifies
>> >programming for the client (you only have to find one object) and
>increases
>> >performance and scalability (you use fewer resources).
>> >
>> >In many applications, the client wants to look at a list of stuff, then
>> >operate on individual entities within that list. The client often
>operates
>> >on a subset of the list, therefore you frequently don't want to
>instantiate
>> >all of these entities. Therefore it makes sense to generate the list in
>the
>> >session bean using a simple JDBC query. It might be nicer if you could
>> >create the list through the entity bean home interface, but we don't
have
>> >that capability now.
>> >
>> >Chances are high that a number of different applications may want to
>> >retrieve lists of a particular entity bean, so rather than duplicating
>the
>> >code in many session beans, you could build a single session bean that's
>> >responsible for generating the lists for all applications. Yes -- you
>have
>> >two beans that encapsulate this data source, but at least you limit
>> yourself
>> >to two. One deals with collections (this bean could also perform
>reporting
>> >and analysis for you), the other deals with individual entities.
>> >
>> >There are three points here:
>> >
>> >1- from the client's point of view, all the data that it needs to work
>with
>> >is encapsulated by it's primary session bean (the one that represents
>this
>> >particular client on the server).
>> >
>> >2- a bean that manipulates collections of data is inherently different
>from
>> >a bean that manipulates a single entity instance.
>> >
>> >3- do what makes sense for your specific application. We all try to
>design
>> >databases according to third normal form, but we often denormalize the
>> >design for performance reasons. Sometimes we need to do the same for our
>> >object design.
>> >
>> >
>> >
>> >-----Original Message-----
>> >From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]]
>> >Sent: Thursday, May 13, 1999 12:46 PM
>> >Subject: Re: findLargeAccounts - why bother?
>> >
>> >
>> >Perhaps lists that are specific to one entity should be included in the
>> >entity business logic. However, summary data or reporting data spans
>> >entities and is not reusable across scenarios should not be in the
entity
>> >bean (or its home). Why would you encapsulate a summary in the entity
>bean
>> >if it is only used in one scenario? What is the value of that besides
>> >creating hopelessly bloated entities. If you use direct database access
>to
>> >produce a summary from a session bean, then you are encapsulating that
>> >behavior in the session. I realize that my approach breaks persistence
>> >independence, but come on. Were also trying to make systems that
perform.
>> >
>> >-----Original Message-----
>> >From: Ian McCallion [mailto:[EMAIL PROTECTED]]
>> >Sent: Thursday, May 13, 1999 8:46 AM
>> >To: [EMAIL PROTECTED]
>> >Subject: Re: findLargeAccounts - why bother?
>> >
>> >
>> >Richard Monson Haefel wrote:
>> >
>> >>I have a different view point from Ian's. Most listing and summary
data
>> >is
>> >>propriate strategy for 3 reasons: 1) Its more peformant to
>> >access
>> >>the database directly for read-only listing and summary data. 2)
>> >Encapsulation
>> >>is achieved through the session bean (to say its not is to say that
>entity
>> >bean
>> >>encapsulation is some how superior), 3) most listing and summary needs
>are
>> >not
>> >>reusable and should therefor not reside in the entity bean.
>> >
>> >I must have higher aims for encapsulation than Richard! To me
>> >"encalsulating" the data inside two beans is not encapsulation.
>> >
>> >Also, I believe that summary extraction will quite often be reusable.
>> >Indeed one could imaging providing a general query service in which the
>> >selection criteria and fields needed could be passed as parameters.
>> >
>> >Ian McCallion
>> >
>> >
>> >
>>
>>==========================================================================
=
>> >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".
>
===========================================================================
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".
