• Post Reply Bookmark Topic Watch Topic
  • New Topic

any issues with number of different EJBs  RSS feed

 
deepak yadav
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am having an application which is still in design phase and we have deciding on having the business logic in a number of stateless session EJBs Vs a 1 or 2 of them. I want to know if there are any kind of issues (performance, etc) in having a single (or few) EJB(s) with all the code instead of multiple EJBs when all the EJBs are to be deployed in same container.
The only benefit I see in using large number of EJBs is that work can be divided easly if there are more number of developers and ofcourse if code size is large then ease of maintenance.
Please note that i am not talking about EJB pooling, to make it clear with an example
why would I have stateless session EJBs: EJB_A, EJB_B, EJB_C, EJB_D with 1 or 2 methods each when I can club the functionality in an EJB called EJB_ALL.
TIA
-deepak
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would suggest you to have session beans based on use cases. Putting too many methods will create an maintenance problem.
 
Barry Andrews
Ranch Hand
Posts: 529
C++ Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
WebSphere 3.5 used to have a problem deploying too many EJB's in the same container. I don't remember exactly how many, but I believe it was somewhere around 15-20. I got around the problem by simply dividing my EJB's into several containers. I don't believe since 4.0 came out they have this problem. Also I have not ever seen this problem with WebLogic (any version).
As far as performance issues go, not sure. Maybe someone else can answer that.
regards,
Barry
 
Mark Whipple
Author
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my opinion, there is a fine balance between too many EJBs, and too many methods in an EJB.
I try to use 2 rules from OO design to define the granularity of EJBs. The rules seem to fit well in the EJB model.
Rule 1) Coherency
Rule 2) Responsibility.
Rule 1 states that you do only the things that you are responsible for.
Rule 2 states that you do all that you are responsible for.
As an example, if you have a stock analysis program that has a Stock EJB, you would expose methods on the EJB that set the price, last trading volume, and other data pieces related to stocks. This covers rule 1. But, you would not have a method called addToPortfolio(String portfolioName) in the stock EJB. This would violate rule 2. The second method would belong in the Portfolio EJB.
If you follow these rules, your application definition and use cases will drive the granularity of your EJBs.
Mark
 
deepak yadav
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
would like to add few more things...
I don't doubt over OO design and having use case define the granuality, but would like to have a some practical insight into it.
I want to serve about 1000 requests concurently for each kind of functionality my application provides. Say I have 6 functionalities and and I code 6 different stateless session EJBs (with say 400 lines of code each) with deployment order of 1000 each. So now I have 6000 EJB objects in my pool.
Would it be better to club the functionality in say 1 EJB and have the deployement order of 6000, which would help if the number of requests exceed 1000 for a particular functionality. Or may be I can reduce the deployment order and save some memory (My app server would have several other applications with lots and lots of EJBs within same container (don't ask me why because i don't know )
(I am using weblogic 8.1, that is just for some info... it shouldn't make any difference)
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If your EJB methods' usage profile varies a lot, you could consider separating them into different EJBs to allow the EJB Container to optimize more efficiently (by not keeping so much infrequently needed code in memory). However, I'll add a disclaimer that I don't necessary buy that. It sounds a bit like optimizing in the wrong place...
By the way, some bartender is probably going to ask you to change your name to conform to the naming policy so you might want to consider changing your name.
 
deepak yadav
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lasse,
could you elaborate a little over the code in memory thing your mentioned.
AFAIK only a single copy of code is present in memory and there can be any number of object instances. So the size of an object of class EJB_A (in memory) should be same as size of object of class EJB_B (no matter how much difference is in the size of code as long as they have same type/number of global variables)
Thanks for replying
-deepak
Self Certified Programmer for Java 2 Platform
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36457
460
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, there is a slight performance penalty in looking up the EJB interfaces. Less session beans, means less distinct interfaces to look up.
However, you should do what makes sense from a business perspective as mentioned above. If you find that it is a performance problem, you can always change it later.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
could you elaborate a little over the code in memory thing your mentioned.

Very bad wording, sorry about that. The bytecode of the class is indeed read only once per classloader (thus, typically per application). I can't remember the exact reasoning but you can generally optimize better when the granularity gets smaller (ofcourse the downside would be that managing it becomes more complex).
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, yes having a monolithic session facade does cause maintenance problems. I guess there will be more developers having the same sesion facade checked out from the source control and then might run into merge issues? But tell me something, if you have standard command objects that perform the actual business operations, w'd'nt that reduce the maintenance problem? The session facade might just instantiate the commands / retrieve it from a in-mem store and delegate the work to those instances instead.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!