This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I think the DAO pattern is one of the most important. I'd hate to see someone going directly against the entity manager. What happens if you move away from EJB? With a DAO, you can move easily. Without it, you're stuck, and that's just a very bad design.
DAO layer is necessary between Session Bean and POJO?
If your session bean is a manager or repository type object whose sole responsibility is entity CRUD operations, then I'd say the answer is no.
I think the JPA or EntityManager is simple enough to process POJO
Only if your session bean's sole responsibility is persistence, and not business logic. Think separation of concerns and functional cohesion.
As for the traditional DAO, I'm not so sure it's that relevant with JPA / EJB3. There's no longer a need to implement abstract factories and families of DAO to cater for physical schema variations or database vendor nuances - that's all abstracted away by the ORM provider. If you do have any native queries, they can be declared in persistence.xml. There may be a case for DAOs if you're planning on moving from an RDBMS to some other form of storage but, in all honesty, how often does that happen?
What happens if you move away from EJB?
Again, how often does that happen? Why introduce another layer for something that, in all likelihood, will never happen?