Last year we built our own version of what Imre's product does (no Imre, we
didn't know about your stuff when we wrote ours). It's extremely similar to
the Ejipt implementation (non-EJB's, extending jdk2 collections). I do hope
that this stuff is available outside of Ejipt because I'll look into
offloading that part of our system and let Valto manage/enhance it ;)
note that the Ejipt stuff probably requires jdk2 whereas ours does not (it
runs fine with the jdk1.1 collections implementation available from sun).
I can say that our version performs excellently and it isn't that difficult
to implement the basics if you wish to roll-your-own.
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 14, 1999 9:19 AM
> To: [EMAIL PROTECTED]
> 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".
