All of alternative components have pros and cons.
It depends to your requirements.
stateless session beans and servlets are usable if you have some stateless ;-) request, e.g. update something and get OK/KO, the next request any following request will send the required data.
-> mean that the instance of the service can be reused, it is not a hard requirement that the call is short-lived, but it helps for a better performance.
statfull session beans are helpful if you need a state accross multiple calls, e.g. login.
-> but here you have to think about failover in a cluster and you burden the server's JVM with long living objects, also what about if the client does not remove the session?
To use JMX service bean and JBoss POJO I'm not a friend, for specific server internals YES. But not as common distributed, we have some in projects with different problems of maintenace.
You have to think about the transaction lifetime, shorter is better for resources.
Also it depends what you want to provide as interface, EJB, WebService, plain http or many more?
Feel free to ask more specific ;-)
About point 4) using JMX service beans (@org.jboss.ejb3.annotation.Service annotated beans)
I tested a @Service bean and realized that its invocations were NOT sequential, but concurrent: its messages called by different clients (servlets) were executed simultaneously in multiple threads by the container.
So my statement in my previous mail (point 4)) seems to be wrong.
1) Could you approve that @Service annotated beans can work concurrently?
2) Is there any official JBoss specification about this topic?
3) Does this mean that a developer is responsible to implement the logics of a @Service annotated bean thread-safe?
Otherwise these beans may not work correctly in a multi-threaded context...