But I am still confused with when to use hibernate and when to use Enterprise beans
They are interchangable technologies - both being persistance layers.
You are right to be sceptical of sawan parihar's post - it doesn't make any sense (sorry sawan parihar, unless you can justify what you say?).
Why not use Entity Beans? Well, this is all well documented, but I'll summarize it here:
Entity Beans are not portable, despite claims to the contrary. They always require platform specific configuration, some thing Hibernate doesn't.EJB-QL is a subset of SQL, and restrictive as a result. HQL: on the other hand is as rich, and Hibernate allows direct SQL if you find a case where you absolutely need it.Entity Beans come with a lot of baggage - you mention CMT and Security. Why are these a requirement of the persistance layer when it is already provided by Session Beans?You need SessionBeans to access EntityBeans. The same is not true about Hibernate (which doesn't need a container at all)Entity Beans force the use of DTOs (or something simmilar) since you can't pass an Entity Bean to a client. You can pass POJOs.Entity Beans work well enough for CRUD operations, but badly for large reads (which tend to be the norm in web applications). There's more but that should be enough to make my point. BMP is not a tennable technology unless you have
very specialist requirements. If CMP is the technology you know, then there is perhaps a case for using it. But I'd seriously consider another ORM route.
(BTW: If you check other posts I've made you may notice that I am an unappologetic fan of Hibernate - so some people may disagree with some of the downsides I list.)