I read several articles informing that entity beans in a Java EE environment are considered as anemic (means only containing getters and setters without implementing behaviour).
What prevents me to put behaviour into entity beans ? So that session beans (stateless or stateful) could delegate all business logics to them (for logic making sense to be owned by entities).
I don't see why entity beans are necessarily anemic.
From a pure semantic perspective, you would expect an ENTITY bean to be a representation of an entity and its attributes. If you couple this with some logic, then you add additional responsibility to your entity class. And as we know from the Curly's law or the single responsibility principle, each class should do one thing and one thing only:
http://www.codinghorror.com/blog/2007/03/curlys-law-do-one-thing.html
http://en.wikipedia.org/wiki/Single_responsibility_principle
If you believe that you have a strong enough reason to violate this principle, you can, but as far in my experience, no reason was strong enough to violate standard software engineering practices, especially if you, like me, believe that the quality of software is best represented by the quality of its code.
There are no restrictions of implementing functionality on entity beans, but they're not meant to be used throughout your application so most of the time you'll add behaviors that modify entities on your Session Beans just because Session Beans are supposed to be accessed from the front end for example.
If we go deeper, session bean methods are usually decorated with transactional and security aspects while entity beans are not, so your application may not behave the expected way if you added code into entities.
