I am no expert at this but let me take a stab at it. Say we have instantiated a bean representing the collection of say 'Item' beans and return a remote reference to the client. When the client asks for some info on the list of items, then is the assumption that the collection bean has a list of references of the item entities but it iterates over them on the server side and returns a list of data objects to the client ? Here is how I understand it. An ItemCollection bean helps us to avoid activating all the individual Item beans when you do a find. To do what you have described above, you just need a session bean. You dont need a collection bean. The session bean wraps the Item entity beans' finders can iterate through the collection on the server side. If you follow the Weblogic/Anne Thomas recommended model of wrapping all entity bean access with session beans, you have these session beans already. My understanding of the "collection of beans as a bean" model as discussed by the Valto folks/Jim Frentress etc is to define an ItemCollection bean which would load all the information requested by the client from storage when the ItemCollection bean is created. The primary key for this CollectionBean would be the "where clause"/restriction which identifies the collection. If a second user needs an ItemCollection with the same "where clause"/restriction then the collection is cached (subject to the number of beans in cache/idle time out etc). These are read only beans. What I dont understand about this model is how an ItemCollection gets refreshed when a new Item bean is created or deleted. If the information required by the second client is a different set of Item fields then you have two choices. 1. Define an ItemCollection2 which would load the set of fields required by the second client. or 2. Define ItemCollection to load the superset of Item fields required by client 1 and client 2. And have two methods which return the different set of fields. To me, the issue is not whether you iterate through all the Item beans that satisfy a particular criteria in the client or the server. In either case, it is a big expense. You shouldn't have to instantiate/activate all those Item beans and load all the detail information associated with each Item bean just to get a summary set of fields for the list of Items that match your search criteria. The folks who recommend "session bean" wrappers for every entity bean suggest that you bypass the entity beans and fire SQL using JDBC against the database to solve the issue. Anil =========================================================================== 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".
