Hi Vaughn, Thank you for taking your time and writing this helpful answer! your assumption is right: (Example) I don't use a session bean just for wrapping an entity bean. Say I've got entity beans for stock, stockmovement, customer and supplier. To create stockmovements, to reserve quantities in stock, I've got an session bean to coordinate the work of the entity beans. My clients do only talk to the session bean to create a stock movement. Is this the way you do it, or did I get it wrong? number of clients: This can be very low (for small customers) to very high, as we may use our software in an ASP setting. I'd like only use the EJBs for updating the data, not for reading it. Say I want to show the user a table of customers on screen. For this, I don't call a finder method, but read the data (thru a "service") by using jdbc. When the user wants to change a customer, then I'd like to use the session or entity bean. Maybe this takes some load from the EJB container... Ruben -----Urspr�ngliche Nachricht----- Von: Vaughn Vernon [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 7. Dezember 2000 18:27 An: jBoss Betreff: RE: [jBoss-User] jBoss: Can it cope with many bean classes? Hi Ruben, Sounds like you're looking at trying to make some business sense, not just looking for a knee-jerk re-architecture opportunity. Your CORBA-based app probably had a lot of business and software architecture thought put into it already. So I wouldn't want to sell you short in that area. >From what I can tell, you probably have many business scenarios (200?) so I would not automatically conclude that you are misusing Session Beans. (ERP systems are truly complex!) And because of that large number most likely many of those are probably talking to the same entities, my guess is maybe 40+% overlap (160 out of 400). In other words, you aren't providing one Session Bean for every other entity, right? If that's the case it is understandable why you could have 200 Session Beans, although the number does seem high. One thing that your post does not state is how many concurrent users you will have. Can that be determined? If it is relatively low, then it might not be unreasonable to think that you could use CMP for these. This is especially true if the relationships (aggrigation or composition) are simplistic. But if there are complex "joins" occuring, you may have to use BMP, at least for some of the entities. But the reason I bring up concurrent users, and overlapping entity usage, is because of the way an EJB container manages EJB instances in general. As a perk, you are guarenteed that you will not have to write thread-safe code, because every instance can have only one client (in the case of entity EJBs, one Session Bean instance) using it at one time. The container has to create or otherwise allocate (pooling) an instance for each concurrent client (server specific). So if you have a high number of simultanious users, and all of those users are accessing something like 40% of the same *kinds* of entity beans at the same time, the server can really bog down. Depending on the kind of EJB you are using, your server can do a lot of grinding in the swapper scheme (passivate/activate). Also, something that the EJB 1.1 spec states about entity beans is that 'not all database entities sould have an entity bean. If you have Order and OrderItem, Order would be an Entity Bean, but OrderItem will not be.' That's great, but the 1.1 spec does not give us any way to map "dependent objects." While you may not be able to find any EJB *2.0* implementations ready for production any time soon, the *2.0* spec does explain dependent objects much more thoroughly. You can get a flavor for how it *should* be done, according to the spec team. However, some have decided to completely side step the whole issue and deal with entities on their own terms, at least until EJB *2.0* clears this up. An out-of-box solution is the TopLink O-R mapping tool. I am *not* talking about TopLink EJB CMP, just regular ol' TopLink backing Session Beans. From a very simplistic approach (for illustration), you simply let TopLink dump your serialized *simple* bean Java objects into the database, and get them back out for you. I personally know of another ERP *kind of* system being developed with this approach for Web ASP model, and the developers say if really screams. Transactions are handled by the container or O-R mapping tool, so not too much worry there. TopLink can really remove the headaches of doing BMP. Another alternate approach, which we are using right now at a client site, is just doing the entity stuff using simple Java classes doing SQL on their own. There is no caching so not much to go wrong with that. They can determine a relativelty limited number of clients, so in their case this approach works out. Since they are using Container-Managed Transactions, again things are quite simple. You might think of this as a sort of COM+ (Microsoft's DCOM and MTS) hybrid approach. Again, Session Beans are used here to front the entity activities. One big disadvantage you have is the use of *Stateful* session beans. Because of this you may also get into a lot of passivation with a high number of users since Stateful does not have pooling like Stateless. If there is any way to do your stuff as Stateless, you'll immediately eliminate a lot of container overhead. Another thing you did not mention is the hardware platform you are running on, and whether you are doing Web or Swing GUI. Don't count on WinTel platforms to handle a lot of entity bean instances. And if you are doing a Swing GUI with a high number of users the server (jboss anyway) may bog down with simultaneous threads (RMI Reference Implementation is in use at this time), one for each of the connections (as opposed to a pool of threads to handle a fixed number of connections and block all others until they can be handled). Again, hardware will play in here. For a huge Sun box, it may not really matter. jBoss has been tested agains this (seems like E4500) with "5000" simultaneous users. But don't count on WinTel giving you that. Depending on the server load dealing with bean instances, connection thread overhead will just add to the overall load. In any event, if you have the bucks and market to do clustering of EJB servers on a kicking multiway Sun box, yeah you can scale it no matter what. In that case just buy the hardware and use CMP and get the app out to users! But if that's not you, you'll have to think about some of the other things I brought up. Hope this helps. Thought it would be best to give you some options rather than a docmatic viewpoint since I don't really know your system. :-) Vaughn __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED]
