The purpose of a stateless session bean is that you don't need to know where it gets executed. That is, you can have the business logic executed on a different server without your code caring about it, for example for scaling reasons.
OTOH, a stateless session bean also adds a huge amount of performance overhead and code complexity to the system.
I don't have a final answer, but I think I would go with POJOs (Plain Old Java Objects) as long as possible...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Since the stateful session bean already manages your transaction, you probably want to use POJO's behind it. On the other hand, you might want to use a stateless session bean before a bunch of entity beans to make a session facade. This way you keep your options open for possible clustering and distributing your project. You can make a facade with regular POJO's, but this will strap you to the same application server your stateful session bean is running. This is basically the same as Ilja Preuss said, but viewed from an other angle.
So depening on the appication lay-out, and the future expectations of your project, any of the two options is possible:
- One application server, no need to split up the application behind the statefull session bean, no need for remote access to the methods on the so called 'helper classes': definately POJO's
- Session facade wanted (this is a J2EE design pattern), remote access wanted, possibility to scale the application over multiple appliciation servers: stateless session bean will be the answer