Your question is really interesting. I do not know an answer, anyway I'd like to extend your question with an additional consideration. Let's have a remote client which communicates with a remote application server. Even in this scenario it's possible to use stateless EJBs: all conversational state may be mantained by the client (in this case a client should send to the server all data needed for processing) or by the application server itself. In fact, an HttpSession-equivalent concept (an "EJBSession" ) may be implemented like an HashMap, in which store the conversational state. Such scenario
would be schematized as follows:
a) Client and server
exchange a SessionID.
b) Each request from client to server simple passes SessionID as parameter, so that EJBs stateless may keep conversational state.
Is it a foolish idea ? Often I read that EJBs stateless are considerably faster than stateful ones, so I wonder if they are really necessary....