4 Replies Latest reply on Sep 16, 2004 10:13 AM by jamesstrachan

    Many small EJB's vs large EJB

    Dave Pagel Newbie

      Hi, been searching around and never could find the answer to this. Is it better to have a whole bunch of little EJB's with only 1 or 2 methods or a couple of large EJB's with many methods? We're wondering performance wise, and ease of maintenance.

      The goal of the application is to write most/all of our business methods in EJB's, including connecting to the database, and sending the 'answers' back to a servlet type client and an application type client.

      Right now we're running:

      AMD 64 3200+
      1GB Ram
      Red Hat Linux Enterprise 64 Bit Edition
      PostgreSQL 7.3 Database
      Java 1.4.2
      JBoss 3.2.5


        • 1. Re: Many small EJB's vs large EJB
          Dave Pagel Newbie

          Just giving this a bump after almost a week. Any one out there with any ideas?


          • 2. Re: Many small EJB's vs large EJB
            jamesstrachan Newbie


            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.

            James Strachan

            • 3. Re: Many small EJB's vs large EJB
              madeonmoon Newbie


              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


              • 4. Re: Many small EJB's vs large EJB
                jamesstrachan Newbie


                I'll dig siomething out and post - but not till I get back home at the weekend !