In all but the most trivial interactions between clients and servers, there exists the notion of ConversationalState, which consists of the context of what was said by both parties to date.  For instance, in the classic shopping cart application, each time a client places a product in the cart, that event becomes part of the ConversationalState.  Subsequently, if the client proceeds to check-out, someone is responsible for remembering what's in the cart.

Here's another example.  You have a news service that lets you browse from an index of breaking stories on the markets.  Selecting a line from the index, you can drill down into the story.  If the story has additional "takes", you can now request them.  If the story spans multiple pages, you can "page down" or "page up", depending on where you currently are.  "Where you currently are" constitutes ConversationalState.  If both client and server forget ConversationalState, the application and user likely become confused.

The design decision of interest is whom to charge with responsibility for maintaining this state.  If servers are responsible, then server memory needed to handle the task will grow as the usage base grows, while if this responsibility can be pushed onto the client, no such memory management issue arises.  On the other hand, server side responsibility frees the message exchange from the messy protocols that might be required to represent state, and also insulates the client against the loss of state that would occur as the result of message loss.

For scalability more than anything else (see above), the model that requires clients to maintain their own ConversationalState is often preferred.  The important thing to keep in mind, though, is that 'stateless' does not mean literally without state.  Servers still need to maintain significant state ''on their own behalf''.  Caching for performance, for example, is a good example of a server maintaining state.  The fine point is that clients cannot depend on this state being present in the server.

When folks talk about StatelessSessionBeans and the like, it's ClientState (more accurately, ConversationalState) they are talking about.  There ain't no such thing as a totally stateless application.