Stateless bean or a helper class?


EJB design: Stateless bean or a helper class?

  1. Stateless bean or a helper class? (8 messages)

    I've recently came across a design issue when writing a component that confirms an order by sending an email message with JavaMail. There are several different implementation approaches I looked at but I still couldn't decide which is best.

    There are basically two options. The "mailer" can either be developed as a stateless bean that gets call by a client directly, or it can be implemented as a helper class for one or more stateful beans. What are the differences and trade-offs in modelling a component as a stateless bean as oppose to a helper class?

    Threaded Messages (8)

  2. stateful vs stateless[ Go to top ]

    You'd want to model it as a stateful session bean if your inherent business process is stateful. That is, if the bean retains conversational state across several method calls. It sounds like just sending an email is a stateless process that only requires a single method call, no? By making it stateless, you enable the application server to more easily pool your bean without resorting to passivation and activation.

  3. stateless vs helper[ Go to top ]

    I agree with what you're saying, but making it stateless would mean the client, whether it be a servlet or JSP, is calling this mailing stateless bean.

    Since business logic should reside in Session beans and servlets should handle View and Control in the MVC model, shouldn't the mailing component be a helper class for the stateful bean that's handling the order instead? Another alternative is the order stateful bean calls the mailing stateless bean. How does performance and resource pooling differ from the two alternative (helper class vs stateful bean calling stateless bean)? And how does one decide which to use?

  4. stateless vs helper[ Go to top ]

    This is a very good (and hard to answer) question. It applies to all sorts of functionality besides this mailer object example.

    It seems that the mailing object carries out a light process that shouldn't be burdened by the overhead of being a session bean.

    I can only think of some guidelines to see if the mailer object you need should be implemented as a stateless session bean or as a helper class.

    1) Do you need to use the mailer object from different types of clients (non-Java, CORBA clients, etc) ? If so, a stateless session bean acts as a remote, server-side object which might be accessible to these clients. A helper class typically is not accessible as a remote object.

    2) Do you need transactional support for the object ? For example, if you were using JMS, you could use a two-phase commit to post the message to the JMS service and mark the message as delivered in your database, all within one transaction.

    In this case, with JavaMail, it might make sense only if you need to log all e-mail messages to a database, in which case a stateless session bean could be useful (connection caching, transaction support, etc.).

    3) Do you have security requirements for sending out these e-mails that would be well served by EJB's security features (roles, etc.) ?

    Perhaps you should save the use of session beans for more coarse-grained tasks, and in this case, have your mailing object be implemented as a helper class.
  5. stateful vs stateless[ Go to top ]

    I have design question. I have some lookup data in the database that doesn't change every day. I would like to
    cache this data in the middle tier so that I don't have to go the DB to load them every time. I want this data to sharable across the server.

    what are options here....?
    Should I use :
          - Stateful Session beans ? They only live between
             method calls.
          - Helper classes to hold the data and put them in the
            servlet context

  6. Stateless bean or a helper class?[ Go to top ]

    I would suggest keeping it simple. Do it as a helper bean until you find a client needs it or you find some other need to make it an EJB then refactor. Do not add the maintenance overhead of an EJB unless you need to.

    So long as you plan your deployment and don't use automated deployment wizards you shouldn't have any troubles at all.
  7. Rick
    You mentioned only using a helper unless you really needed a stateless session bean, would a stateless session bean offer better perfomance than a helper class if it required a great deal of initialization? Since an ejb container can just grab an existing stateless session bean from a pool wouldn't this be faster then creating a new helper class that contained a lot of initialization/startup? Also aren't stateless session bean more scalable as they can be deactivated/activated as needed?
  8. I think Rick has a valid point.
    In your case the mail function ideally is a helper to many other core processes(order mgmt). The components that model the Core processes would ideally handle the major requirements like transactional boundaries, security etc.
    By modelling your helper functions(like mail) as EJBs, the major benefit you draw is that they can be invoked fom distributed namespaces.
    But if your helper functions are never meant to be invoked independently of your core processes then Helper classes are the way to go.
    Implementing them as helper classes have other advantages that easier maintenence.
    In case you need remote calls , you can EJBize the mail function by simply calling the helper class from an EJB.
    It also allows to have one standard ligt-weight implementaion of your mail function, that could be re-used.
  9. Keeping it simple is always a good choice. Helper classes are the simplest route.

    I would recommend following the EJB pattern though... factory method for getting an interface reference to a class instance. This will help insure smooth transition over to EJB when/if the time comes, and will also give you the benefit of a good programming abstraction.

    If you are facing any of the following issues:

    1. Firewall rules for your production environment only allow certain boxes to be used to service the SMTP channel.

    2. Transactional intergrity and guarenteed delivery.

    3. Performance of handling the SMTP traffic on machines deployed as web or app servers.

    EJB will be the way to go today. Again, keep it simple...