A stateless session bean (SSB) is a kind of EJB that manages a user's access to an app's domain model. As an EJB, an SSB manages overhead issues like sharing of instances, thread reuse, transactions, and security; this lets the SSB developer focus on implementing code for business logic. Because an SSB is stateless, a user only cares about using an instance from a pool of the same type; since all instances are the same, which one a particular user gets makes no difference.
For example, a banking SSB might have methods like
transferFunds. Each method is stateless, so it needs appropriate arguments like account IDs and payment info.
Services are also considered stateless; all state must be passed in as parameters. Web services are stateless, HTTP itself is a stateless transport.
So in J2EE, it makes sense to implement a service, such as a web service, as an SSB. If the service transport is HTTP, it's easy to add access to an SSB by implementing a service activator (EIP, CoreJ2EE), which in J2EE for HTTP is a servlet. If the transport is JMS, use the service activator pattern again, but this time implement it as an MDB. A J2EE 1.4 container can expose an SSB as a JAX-RPC web service directly; the container acts as the servlet.
Part of the beauty of implementing a service as an SSB is that clients then have great flexibility to invoke it synchronously or asynchronously. I've already discussed asynchronous access using service activators for HTTP or JMS transports. Java clients of the service may wish to invoke the service synchronously, which is easy to do with an SSB--just use its local or remote home and interface. So SSBs make service invocation very flexible.
Some people don't like EJBs. Perhaps they're not using Java, they're using .NET; they'll use .NET's equivalent of an SSB. Perhaps they're using Java but not J2EE, or at least not EJBs. This principle still applies, they would just use a JavaBean/POJO. But that J2SE object would need to handle security, transactions, remoteness, pooling--pretty soon, you've reinvented EJBs, so you should just use EJBs to begin with.
So an SSB isn't the only way to implement a service in Java, but if you want to take advantage of J2EE, then an SSB is a good way to go.