Discussions

EJB design: Required suggestions for using EJBs(SessBeans) across the appl.

  1. Hi All,
    I am planning to develop a new EJB application and decided that most of the business logic is handled by EJBs.

    There are a few functionalities which do not REALLY require any of the services provided by the EJB container. They are simple and straight forward and could be done using JavaBeans. For example, user registration.

    Now the questions I have are:
    1. Is it good design if I use EJBs for some functionality and ordinary java classes for others?
    2. If I use EJBs for everything, would it REALLY impact the application performance?

    I understand that the performance is impacted because of these additional EJBs. But is this performance degrade that significant?
    Is it good practise to develop some funcitonality in EJBs and some using ordinary java classes. Will this impact the extensibility of the applications going forward.I am sure that lot of apps have this issue.
    I would like to know the best practises that are generally applied for such cases.

    I would really appreciate if people in this forum could guide me in implementing the best solution.
    Thanks in advance,
    Satish
  2. Hi Satish,

    Generally, it is not a good practice to spread the business logic in both "pojos" and in EJBs. It's considered good practice to always place the logic in pojos, and if needed wrapping these in EJBs. This approach makes it way easier to unit test your business logic.

    However, I believe you should really think through why you REALLY need to be using EJBs. Is the need to distribute beans on a BEAN/COMPONENT LEVEL really what you need? If not, you will save yourself a lot of trouble by skipping using EJB, and implement the whole lot using pojos and (for example) spring as a mini container. You will NOT gain any performance imporovments by using EJB.

    But to answer your second question: no, it will not impact performance. The only impact will be on the development process.

    /Niklas
  3. Hi Niklas,
     Thanks for your response.
     Depending upon the application requirements we have decided to use EJBs. Also we are expecting the user base to be huge.
    Thanks again,
    Satish
  4. Now the questions I have are:
    1. Is it good design if I use EJBs for some functionality and ordinary java classes for others?
    -------> Its ok to do so as long as you ensure the java classes are thread safe and the client doesn't end up using them outside the context of the ejbs and also that you dont store any state info in these java classes. Typically the EJB model may not be used this way. By putting a ton of logic in the POJO's you generally lose out on the features the EJB container provides.
    2. If I use EJBs for everything, would it REALLY impact the application performance
    -------> You need to have a good reason to use EJB's. Some of the reasons being,
    1. is it an enterprise application for eg. which will run on multiple servers and you are worried about transaction isolation, security and scalability, how many users will use the app ... etc?
    2. 1 in turn will be defined by the size of the application. Is it really big or going to become big in due course which will justify use of EJB's.
    EJB containers cost either for the product or the support or both so it needs to be thought through and more importantly they are also strictly non-compliant to J2EE standards with their proprietary hooks all over...and their staggered supports for version support.
  5. Hi PB,
     Thanks for your response.
     As mentioned in my previous post, its decided that we would be using EJBs in the application. Yes user base is expected to be high and also application itself would also grow going forward.
    Thanks again,
    Satish
  6. Hi!

    Just can't restraint myself on giving some comments... ;)

    Making an enterprise application is not itself a justified reason of using EJBs. The EJBs themselfes do not provide any scalability functionality other than object pooling, which is not needed in an stateless environment. The session beans can be implemented as simple stateless pojos, i.e. singeltons, which can be managed using Spring. No object pooling is needed. If fact, it will actually degrade performance.

    The multiple servers issue is not dependent on EJBs or not, given that you do not distribute on an component level. Load balancing using multiple sets of the same application is not dependant on EJBs.

    Transaction isolation, etc, is not a reason of using ejbs. If actually JTA transactions are needed, the TransactionManager is a part of the application server anyway, and NOT a part of the EJB conainer. What I mean is that you do not need the EJB container to use the TransactionManager with JTA. And as always, Spring can help you use the TranMan transparently. :)

    Having a large user base is itself not a reason to use EJB, neither high scalability demands. Rather, it is a question of good design.

    I'm not saying that you shouldn't use EJBs, I'm just hinting that most of the reasons that people choose EJB are actually not relevant. The ONLY time EJB is really needed, is when distributing on a component level.

    Just my 2 cents... ;)

    /Niklas
  7. Making an enterprise application is not itself a justified reason of using EJBs. The EJBs themselfes do not provide any scalability functionality other than object pooling, which is not needed in an stateless environment. The session beans can be implemented as simple stateless pojos, i.e. singeltons, which can be managed using Spring. No object pooling is needed. If fact, it will actually degrade performance.
    ----------------------> thats not true. POJO's are not only not thread safe they cant scale!! If you have to go back to pojo's you are better of with C/C++ which will atleast give a big performance gain..

    Transaction isolation, etc, is not a reason of using ejbs. If actually JTA transactions are needed, the TransactionManager is a part of the application server anyway, and NOT a part of the EJB conainer. What I mean is that you do not need the EJB container to use the TransactionManager with JTA. And as always, Spring can help you use the TranMan transparently. :)
    ---------> the application server is conformant with the J2EE standard and thats the reason it exists in first place and this features are base features of ejb's. Spring is supposed to make j2ee easy os it sits on the top of the j2ee framework i dont understand how it replaces it. Lets wait and see how many applications adopt spring for anything at all.

    Having a large user base is itself not a reason to use EJB, neither high scalability demands. Rather, it is a question of good design.
    ---------> At this time there is no alternative model which can scale....
  8. 1. "Pojos are not threadsafe, and cannot scale" - Jesus, I believe we are up for some fundamental discussions here! A pojo is a pojo is a pojo, it it what ever you make it to be. Make it thread safe if it must be. What to you mean they cannot scale? Take the simplest example, a stateless singelton pojo, which is the closest to a stateless ejb you can get. Simply write thread safe code in it, as you would in any stateless ejb anyway, and you have a perfect threadsafe well scalable piece of code. How on earth would it not be able to scale? Of course it depends on the business logic, but the design decision at least enables extremly scalable code. Good code scales, bad doesn't. It does not matter if you decide on EJB, pojos, c++ or whatever.

    2. "Spring replaces j2ee, and application servers only exist as a base for EJB" -
    Spring does not replace j2EE. Most definitly not! It does not replace anyting at all, but simply makes access to resources more simple and uniform (ok, this explanation is quite simplified, but will do in this context). Spring itself does not either replace the ejb container. You do not need spring to skip ejbs. It is just a simple way to do so. The point is, there is nothing you can do with EJBs that you can't also do with simple pojos + spring in an easy way EXCEPT DISTRIBUTING ON AN COMPONENT/BEAN LEVEL. If you do not need to do so, you do not need EJBs! EJBs do no magic other than that!! The rest is the responsibility of the app server, and NOT the EJB container.

    And please... "Lets wait and see how many applications adopt spring for anything at all", Spring has been in production for ages now, and I have personally been responsible for implementing business critical applications in large organisations using Spring for over 2 years now, and very successfully. One case was a critial financial app with high demands on transaction throughput, data quantity and stabity, in one of northern Europe's biggest retail companies.

    I have made the decision to keep the EJB container ONLY in the case where we need MDBs. For simplicity's sake, not because it cannot be solved in other ways. But only mdbs, no session or entity beans were used.

    Spring + pojos has been the right path to go simply because we have not been needing the ejb container. As simple as that. And we have not been needing the ejb container becase we have not been needing the ability to distibute ON A BEAN/COMPONENT LEVEL! (Can't stop repeating this mantra...). We have however load balanced the application, i.e. distributed it across several machines, but not on a bean level. And, needless to say, the applications have scaled very well, thanks to well written code (no other magic than that)!

    3. "At this time there is no alternative model which can scale" - You have A LOT of catching up to do!

    I must say... sometimes this forum scares me... hope I have not caused any confusion. Good luck Satish!

    /Niklas
  9. For point
    1. Thats exactly my point. Why are we using POJO when a good framewrok like ejb exists. Whats that compelling need for businesses which create a new technology everyday!!. Even bad code scales quite a lot if you use EJB, doesn't mean you write bad code its like understanding the tolerance factor for a design.
    2. Your advocacy of Spring is just taken with a grain of salt. My first hand experience with likes of Morgan chase, and others.. etc is they use EJB mainly for its platform independent support over .net and right now the only two major players in this business who really make any difference is J2EE and .Net. Spring is more like for user forums and discussion groups. Nevertheless I dont deny its use by some companies possibly for reasons unknown. Every new technology has to have a life-cycle more than the hype it carries around before it can be proven and accepted. I know ejbs dont do any magic.. but they provide a scalable n-tier architecture based on RMI with all the necessary components instead of going back to POJO's and reinventing the wheel!! And remember by itself JAVA is a big overhead because its a interpreted language. J2EE gives additional
    advantage for JAVA. And frankly whats the app server? Isnt it a conglomerate of various servers - web container, ejb container, directory server - all a part of the j2ee specification.. i mean your naivete appals me!! Its like apache advocating log4j and then the AOP advocates coming across and advocating cross-cutting. These technologies are like every individual business decision based not on succes stories but have to based off of convincing design intent provided by the J2EE specification!!!
    3. I meant besides .net and j2ee there is nothing else that can "really" be deployed for enterprise apps! Yes a lot is coming up but does it have a lot of value from business standpoint!! - thats more of an open question!!! Frankly what scares me is the thought that people who run businesses should realize a compelling reason to adopt a technology and how its going to make more $$ for them rather than jump on everything that comes from symposiums, novelties, user forums or wherever!!