Discussions

EJB design: How about a J2EE application with ONLY SLSB's?

  1. I'm working on a J2EE application: JSP/Servlet/EJB.
    We have interfaces for business methods like this:

    XXXManager.addYYY(YYYModel)
    XXXManager.deleteYYY(id)
    XXXManager.modifyYYY(YYYModel)
    XXXManager.getYYY(id)
    XXXManager.getYYYs()
    XXXManager.doSomething(...)

    I completed part of the app using only Stateless session beans (the XXXManager's), and all is fine.
    Now I'm thinking of continuing with ONLY SLSB's and not using Entity beans at all.

    Will that be OK on the long run? I mean if we can do all the work with SLSB why do we have Entity beans?

    I know that they THEORETICALLY represent persistant data, and they hide all the persistance logic from the client. That is ok and consistant, but if I use my SLSB as a facade for business methods, it's practically the same.

    Don't I get ALL the benefits of J2EE with only using SLSB.

    regards,
    zeron


  2. Using only stateless beans would note certainly harm but, using stateless beans as a facade for database access, I have my doubts!!
    I would like to know how are you managing persistent data store!! are using some helper classes.

    thanks
    sudhen
    sudhi_bs at yahoo dot com
  3. Hi there

    If your usging the stateless session beans (i like to write full text as SLSB's was preety confusing)

    Here the question is your application need !!

    why Stateless session benas or why not entity beans.

    is this you want to know ??

    Cheers
    -Manoj



  4. As I've mentioned in my first post, I have methods to add, delete, modity .. etc the entities. I'm persisting the data in the Database of course!

    My SLSBs communicate with the client using ordinary beans that serve as value objects.
    For example: the getXXX method of a certain SLSB will return a bean (not an ejbean of course) that encapsulates the data from the database. and addXXX(beanModel bm) will do the reverse.

    cheers
  5. I've done a system with only SLSBs, using a home grown ORM for persistence. It worked well.

    The problem with your approach is that the interface your EJBs are presenting appears to be far too low level.

    Have managers with real business methods on them, so that a business event which needs to create several entities just calls a single EJB function. You need this to keep your business logic in one place, and simply for transactional integrity.

    Tom
  6. Absolutely!

    You are 100% correct in stating that, and that IS what I intend to do. Have only BUSINESS methods exposed by the EJB's. But in my application we have business methods that do just that! i.e. add, or delete or modify just one entity that actually maps to one table. It looks low level but this is what is needed by the client. Do u have any other suggestion - as far as method exposure is concerned - as how should I add an entity to peristant data?

    cheers
    zeron
  7. Zeron,

    If that's what your business transactions are, then that's fine.

    Tom
  8. You can go down the route of only using SLSBs, and that's fine: after all, you're achieving the aim of implementing all of your business methods.

    However, you may be making life harder for yourself by doing this. The point of entity beans is that they shield you from having to write all those painful create/update/remove methods, and shield you from changes to the underlying architecture.

    You could argue that writing EJBs to encapsulate all the SQL tables you have would take a long time, and if the database ever gets changed, you have a lot of changes to EJB code to do. However, if this is the issue, then take a look at Oracle 9i JDeveloper, because it can do this synchronisation work for you - reading the database schema and generating EJBs and deployment descriptors from it.

    Has anyone had some real-life experience using this technology?

    regards,
    rob