Hi Edward, Thank you for this detailed and helpful answer. Some more questions: You've got 100 db-entities, but only 8 entity beans. These components seem to be rather powerful and access many db entities at once. Do you have a persistence layer or classes that are not EJBs "behind" the EJBs? Do these correspond to the db-entities? Should we create entity beans at all? Many people advise not to access entity beans directly, but through session beans. What is the value of entity beans then... How do you cope with some classes used in different contexts? Say you have an address and the address class can be used in the context of a customer or in context of an employer or as a supplier. If I understand you right, address isn't a EJB and its located somewhere behind the scene... Ruben -----Urspr�ngliche Nachricht----- Von: Kenworthy, Edward [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 7. Dezember 2000 09:39 An: 'jBoss' Betreff: RE: [jBoss-User] jBoss: Can it cope with many bean classes? If you have 400 different entity beans then it sounds like your entity beans are far too fine-grained (similarly for your session beans). [To give you a for instance, the system I am currently working on has of the order of 100 entities, but only 8 EJB entity beans. It has around 40 session beans (session bean corresponds to use case in our system, and I am of the Ivar Jacobson, *BIG*, ie proper, Use Case school - so 40 use case system is roughly an 40 man-year project, and multi-million pound).] The problem you will have is that to do anything realistic with a fine-grained system (eg 400 entities) will require the instantiation of many EJB entities and that is expensive in terms of both system resources and the app server having to manage all these teeny EJB entities. It migh be worth reviewing your design and seeing if you can cluster your entities together. Eg you may have Customer -->(many)Order --> (many)Product. Is Order really separate from Customer ? Probably not, you probaly only rarely (if ever) deal with it separately from Customer so perhaps Order (entity) and Customer (entity) should be combined into a single EJB entity. The mistake people often seem to make is mapping classes 1:1 to EJBs. EJBs are *components*. The mapping, particularly for EJB entities, I would expect to be many classes in one EJB. A simple rule of thumb to find you EJB entities that we've used is: what's the relationship ? association or aggregation, if the latter then you're probably looking at two classes in one EJB entity (doubly so if its a containment aggregation.) That of course is a technical way of saying look at the life-times and context. Is one ever used (instantiated) without the other ? Hope this helps :-) But probably not in the way you had hoped. Edward PS Oh and for all but the simplest systems, CMP is completely inadequate. it leads to you defining hundreds of tiny EJB entities that will perform like a dog :-) Use BMP. -----Original Message----- From: Bakker Ruben [mailto:[EMAIL PROTECTED]] Sent: 07 December 2000 07:43 To: '[EMAIL PROTECTED]' Subject: [jBoss-User] jBoss: Can it cope with many bean classes? Hello everybody. We've building a large ERP-System and like are planing a transition from a custom CORBA App-Server to EJB. We currently have about 400 different EntityBeans and about 200 SessionBeans most of them stateful. Can jBoss cope with this? Is EJB in general designed for such large applications? Has anybody experience in building large applications with EJB (jBoss?)? Any answer is very much appreciated... Ruben -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED]
