Stateless Session Bean versus static method calls

[flindet]

Hi,

I have managed to get myself confused over when to use Stateless Session Beans versus just making calls to static methods. I know there's lots of documentation about when to use Session Beans, but I haven't found anything discussing this particular comparison. I'm hoping someone can help me get my head around this because I'm pretty new to J2EE. Thanks.

I am working on a middleware system that basically routes messages between several applications state-wide, and indirectly nation-wide. I wanted to write two classes. One uses Hibernate to store each message in the database as it passes through the middleware. Then when all the responses for a request come in, this class will pass the message bundle to my second class, a router. The router class is meant to do some minor security and then send the message bundle off to the proper destination. I had originally thought these two classes would just be Stateless Session Beans that would be invoked from an MDB when a new message reaches my JMS Queue.

However, our consultant thought it would be a far better idea to use a class with static methods instead of Stateless Session Beans. Because these classes do not have state information, the static approach should work, he said. The static approach would supposedly use less memory because there are no beans (other than the MDBs) being pooled, and only one instance would be in memory. He claims there will be no concurrency issues because an MDB can still call a static method without worry of when the other MDBs call the static method. Again, the methods are stateless, and supposedly no MDB would block waiting for another MDB to finish (just like how anyone can call System.out.println() without worry that some other class called it at the same time).

All of that sounds fairly reasonable, but now I've got myself confused. With this in mind, why does anyone ever use Stateless Session Beans? I hope that doesn't sound accusatory. I'm certain that Sun know what they're doing! ;-) I'm just confused. The one benefit is JNDI look-ups, obviously, but if the beans are going to be on the same box is there any reason to use the Stateless Session Beans?

Please help! I've gotten myself confused and I'm sure I'm just having a brain freeze here. Anyone who can set me straight would be GREATLY appreciated, so that I understand when I should use a Stateless Session Bean, and what the trade-offs are for these two approaches.

If I need to better explain anything, just let me know. I have commercial support too, but I hate to bother JBoss with something that is probably so obvious to those of you with more experienced. Thanks!

[flindet]

Okay, I did manage to find one thread discussing a similar topic. The original poster basically had the same question. There's good conversation here explaining that the singleton or static class approach IS a good idea.

http://forum.java.sun.com/thread.jspa?threadID=555658&tstart=255

However, I'm still confused on when it's a good idea to use a Stateless Session Bean. When is it better to use a Stateless Session Bean versus a static class?

Thanks for clarification.

[jamesstrachan]

Static method calls are a very useful tool but have limitations.

You cannot access a static method from outside the JVM in which the class resides.

And there are potential concurrency issues if your static methods access shared data. One thread may change data on which another thread relies.

Concurrency issues also need to be considered when you re designing servlets and stateless session beans.

But the real decider is that you must use a session bean to gain access from a client outside the server JVM.

Rereading your original query, you should be able to use static method calls from the Message Driven Bean - that is already inside the container. The normal access from the client is presumably to put a message on a JMS queue. You would only need to use a Stateless Session Bean approach if the client cannot do this.

[darranl]

Another reason for using session beans is that they allow you to define their security and transaction requirements of the session beans seperately from the configuration of the message driven beans.

Depending on the amount of work your static methods are going to be performing this may or may not be something you need to consider.

If your application code is split up into different beans, with the correct use of ejb references you can change which beans are used by just changing the deployment descriptors without needing to recompile your code. If you have made calls to static methods your only option is to recompile the code.

Finally is you are going to use 'memory saved' as an argument for a design decision I think you should make sure that it is quantified.

[kipflip]

Don't forget that with static methods you also can't use interfaces, abstract methods, method overriding, and all the rest of that OO goodness.

You'll end up with hard interdependencies between classes, which will also make you unit testing harder.

Finally, *right now* you don't have state, but if later you add state (for whatever reason) then pooling instances will require changing all calling classes.

At least, those are reasons I can think of why you might prefer a singleton pattern to static calls.

Why you might prefer EJBs to a plain j2se app is always about whether you want to make use of all the "pre-provided" extras as mentioned above, such as security and transactions, etc.