We are developing an application with around 400 database tables. and have equal number of EJBs (All are Local interfaces and EJB is stateless) and one EJB is injected into another EJB by @EJB tag.
My doubt is, is having more number of EJBs have any effect on the performance on the application?
Configuration and tuning
You might need to size the system accordingly. Usually, each EJB has an associated pool (but it's app. server specific and I have only experience with Glassfish). So if you have 400 different EJB, that may represent a significant number of object. But all that can be tuned.
Local EJB call
Regarding an EJB calling another one, I made once a few tests. Here are the result I got.
Time to call one EJB that performs a loop with 10’000 call to another helper object which is either a:
I came to the conclusion that EJB calling each other is not a performance issue if they are local. See also Is it worth to use POJO instead of EJB?.
Deployment & administration
The deployment time of the EAR depends also of the number of EJB (to parse the annotations, the deployment descriptor, etc.). You might make a few tests to see how your app. server support such deployment.
Monitoring app. with many EJB can quickly become complicated depending on the app. server. In Glassfish, the JMX console and the web console don't really scale to app. with a lot of EJB. For instance, the EJB we are interested in need to be selected in a dropdown sometime, which is not convenient when there are a lot of them.
EJB/JPA and DAO
SLSB responsible of the business logic should be coarse grained. You can still use fine-grained SLSB for DAO. With JPA, DAO are now really thin and contain mostly JPA queries. It might still be interesting to try to reduce the number of DAO and have some DAO responsible of more than one table, if that's possible. See JPA/EJB3 killed the DAO.
Why would you have one EJB per table? JPA is the persistence mechanism normally used with EJB3, JPA-annotated classes are not EJBs. I would tend to express my EJB layer in terms of coarser grained objects. For example Order might be an EJB with an interface expressed in terms of OrderLines, which are not EJBs.
Having said that, assuming that you are using local calls to your EJBs the run-time overhead need not be very excessive. You pay the cost of the JNDI lookups when you get the references, and the container needs to do a little work when dispatching a method (think about security and transactions) so there is bound to be some overhead, whether it's too much for your app only benchmarking can tell.
My gut feel: you've got more EJBs than you need, and you will be happier with fewer.