Discussions

EJB design: Need advice about EJB design decision

  1. Need advice about EJB design decision (4 messages)

    Hi guys,
    I work on a project involving EJBs.
    It's a 3 tier archtecture - Web tier, business tier and Data tier, all distributed accross a network.
    The web tier accesses the business tier through an EJB entry.
    The EJB tier consists in performing some heavy calculations as well as some data saving-retreiving funtions.
    I intend to use Stateless Session EJB only.

    My question is:
    What could be the trade-off between separating the calculation functions and the data saving-retreiving funtions in two different EJBs, and leaving them in one EJB ?
    Could be there any impact on the performance of the application ?
    I must mention that in case of two EJBs they must call each other.

    I use Websphere 5.0 server.
    If you have any ideas, or links to articles or books discussing the problem, please let me know.

    Thank you.
    Stan
  2. I´m sure the impact is so minimun compared with the calculations and the cost of accesing to database that you should worry more to do a better design more than performance when you choose the number of EJBs.

    I remember we had one EJB to make several very different operations, and when we separate it in several EJBs according to the kind of operation, we get a 35% more efficiency, as the code was clearer to debug.
  3. Need advice about EJB design decision[ Go to top ]

    I see an EJB as a public interface to a subsystem. The design of your implementation, the number of classes you use, and the way you decompose the problem should not be driven by the number of EJBs.
  4. Need advice about EJB design decision[ Go to top ]

    IMO, the stateless session EJB should, for the most part, only be an entry into the world of the app server. All business logic, calculations, etc should be plain old java objects initiated through EJB.
    You must consider this within the realm of reason, however. Depending on what you are actually use the app server for will determine how coupled your business logic should be. If you are only using the app server only for 2 phase commit transactions and connection pooling then you will likely want no coupling between the two.
  5. Need advice about EJB design decision[ Go to top ]

    I totally agree with Kris's opinion.

    I strongly suggest you remove the calculation code and data saving code into ordinary Java classes (called EJB Helper Classes) and use your SSB as an entry point to the app server. Once you do this you yourselves will be clear enough to take a decesion on whether the calculation code and the data saving code should be required in the same class or you can even split there.

    Ideally to avoid tight coupling your calculation code and data saving code can be in different class and your data saving code can follow a Data Aceess Object pattern.

    Jaise