Just giving this a bump after almost a week. Any one out there with any ideas?
The trouble is that the answer is "it depends", not least because it depends on what you are doing with the EJB's.
At one extreme, you may be using a set of session beans that have a little business logic and JDBC statements to interact with the database. In that environment, it probably makes no difference at all to performance whether you put your methods in a few large session beans or a lot of smaller session beans.
But using larger session beans does make it more difficult for multiple developers to maintain the code base - as more than one may want to work on the same module at the same time.
At the other extreme, you may be working with Entity Beans representing persistent data. At this level, providing very fine grained Entity Beans may slow things down because the Server has to administer all the objects and, in practice, many methods require Entity Beans to be marshalled and handled as a set.
My normal practice is :-
Produce a Session Bean for each use case containing all methods required in that Use Case. This normally gives you about five to ten methods for each Use Case Session Bean.
If more than one Use Case requires the same functionality, use helper classes or an Application Logic layer to eliminate duplicated code.
Design Entity Beans to represent relatively coarse grained objects - although this may not be possible with CMP. Coarse grained objects might be, as examples, sales order plus order lines, or a complete set of tax codes and rates that are always handled together.
You mention that you are using both application clients and servlet clients.
One obvious tactic in the Use Case Session Bean layer is to use the Value Object pattern to minimise the number of network calls and the volume of network I/O. This is probably the single most important factor in speeding up the application.
If you are writing for servlets or JSP pages, you may also find it very helpful to use a support class on the client side. This provides a good place to store state and hides all the complexity of client/server communications, and of exception handling, from the presentation layer.
You should also attempt to handle validation of user data, and generation of data for HTML menu boxes, etc. without a round trip to the server each time. A client side cache works wonders for unloading the network and the server.
Hope this helps. I can provide samples of code if you are interested.
I would be interested to see some of the ejb code you've written (if possible). it's always helpful to see what other experienced developers do. you can point me to some online code or email an attachment to soundres9(at)yahoo.com
I'll dig siomething out and post - but not till I get back home at the weekend !