"fhh" wrote : | Not sure what you mean by that. The whole point of an entity bean is to hold persitent data. | Well, I guess Manuel takes an "Entity" more like a concept, a description, a skeleton of something which has some properties and can behave. "fhh" wrote : | Why not inject the entity bean into the service objects? If you use Seam, you might as well do things the Seam way. | Well, if you started out with a very clear awareness of the behaviors of the entities in your application (for most web applications, that's CRUD), it's best to inject the entity bean into the service objects. That's sending data to computation. But under some situation, you have a clear layout of the data (entity properties) but do not know how to deal with the data in an application from the beginning, you need to send computation to your data. If your entity "knows" how to crunch its own data (and inter-entity data), your entity is more reusable in a larger scale. http://www.isi.edu/expect/papers/papers-ontos.html http://www-ksl.stanford.edu/KSL_Abstracts/KSL-89-50.html Aside from the "knowledge storing" for entities (even if we do not bind behaviours to entities using rule engine), expert systems have been very successful in hardware configuration for decades of years. Nowadays the software is becoming more and more modular, assembling software modules is pretty like assembling hardware modules. Why cannot we use expert systems to configure a big software system given well defined entities and services? That said, personally I feel Seam + Drools approach is more flexible, more expressive and more intuitive than the Spring + AOP thing. Dealing with cross-cutting concerns? Rule engines are _very_ good at that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066852#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...