Responsible Entities - Introduction

When C# is my technology of choice to design a middle tier (and I have the chance to work it out from scratch) I often end up using an open source architectural framework called CSLA.NET (This post isn't about C# or CSLA though. Indulge me a few moments as I try to set the context.). Created by +Rockford Lhotka, CSLA.NET essentially helps you with building an object-oriented business layer by the means of standardizing the implementation of business objects. I usually build a hierarchy of CSLA based business objects for each domain entity in which I encapsulate business logic (business rules, validations, authorization rules if I use any, etc.) and data. CSLA is a lot more than just a series of base classes from which you'd inherit your business objects (its capabilities form a number of books). Suffice it to say that it offers distribution within the middle tier in an easy and configurable way and facilitates the UI interactions (e.g.: data binding, sorting, N-level undo) within the boundaries of Microsoft technologies (e.g.: ASP.NET MVC).
Mapping CSLA to EJB 3.0, each CSLA business object is an equivalent of a Session Bean (a distributed business object that doesn't contain data) and an Entity (a POJO with no business logic). To a lot of developers who work with EJB 3, creating data entities means using JPA. And that, to some extent, is understandable. JPA introduced a much leaner approach to data persistence compared to Entity Beans and is usable both within Java SE environments as well as within Java EE.
But then the question arises, what if one can't or doesn't want to use JPA? For instance, if you are required to adhere to the specification of Java EE 5 where JPA was initially introduced and thus, lacking the features you might need.
Based on the lessons learned from CSLA, I'd like to build a model for entities in which:

1. Similar to JPA, entities are annotated POJOs.
2. Unlike JPA, the core data-related tasks (Population, Validation, and Tracking and Reporting Changes) are delegated to the entities themselves (validation is introduced in Java EE 6 with JSR 303). The advantage of this approach is that you don't have to annotate the entities with the detail of data layer objects such as table or procedure names. Also, entities that track and report their changes not only fulfill data persistence requirements, but also prove useful in the implementation of UI interactions.

In the next few posts, I'll explain the implementation detail of different aspects (Tracking changes, Validation, and Data Population) of the model.