So what you are saying Jaime, Session Bean(service) ===> Stateless Session Bean(DAO) ===> JPA ?
yes that is the idea. The DAO tier hides the data access mechanism, in this case JPA but it also could be JDBC, iBatis, Hibernate, flat file or JNDI/LDAP and so. There's nothing new about this, i'm only applying core j2ee patterns
Is this applicable if the Session Bean(service) is Stateful ?
There's no point to use a stateful EJB because the DAO bean is to be used as a facade for the entity managers and entity classes, in this case of JPA use. It's not a component intended to be a client extension like the stateful beans are.
Is there really a need for the DAO layer at all ?
Of course, you could require to change internal representation from JPA to Hibernate or to make part of it based on JDBC or to include other data sources like LDAP. Or still better you could provide mock implementation for DAO facades to facilitate the parallel development between the DAO tier and another tiers with dependencies to it. Not to use DAO means to create dependencies to persistence mechanism within tiers not requiring to know about that, hurting the low coupling.