Advising Domain Objects without AspectJ
- Share
-
- |
Read later
My Reading List
In a recent article on Java.net Eric Batzdorff considers the application of AOP in respect to singletons versus domain objects. He is exploring the differences as a result of the desire to advise objects to separate concerns. Batzdorff points out that the weight of using such technologies can be much more noticeable when advising domain objects versus singletons:
7
Discuss
1000000 iteration test for 'Create dynamic proxy using Proxy.newProxyInstance()'
WARMED UP in 16 ms
Iterations ,Total Time(ms) ,Avg(ms)/Iteration ,Transactions/sec
1000000 ,7978 ,0.007978 ,125344.71
1000000 iteration test for 'Create regular object using new'
WARMED UP in 0 ms
Iterations ,Total Time(ms) ,Avg(ms)/Iteration ,Transactions/sec
1000000 ,63 ,0.000063 ,15873015 After pointing out the drastic timing differences between a simple new object instanciation versus a dynamic proxy, he continues by exploring a few options to optimize the advising of domain objects which may have many instances being created. These alternatives are considered in comparison to AspectJ due to the learning curve and effort needed to integrate it into development environments.
First considered is using an object pool but as Batzdorff points out this creates a new set of concerns that must be addressed:
- Returning the advised objects back to the pool when clients are done using them.
- Clearing the state within an object before it is used again by another client.
- Hoping that clients do not keep references to any objects that were released back to the pool. If clients do not cooperate, this could cause all sorts of hard-to-track-down data integrity issues.
- Tuning the maximum size of the pool appropriately. The size would need to be based on the hardware, amount of memory allocated to the JVM, etc.
He also looks at the pros and cons of alternative stategies such as simple Java class extension, static decorating proxies, and dynamic decorating proxies.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
Benefits of AOP for domain model
by
Rickard Öberg
Posted
Article Summary
by
Corby Page
Posted
Re: Article Summary
by
Rickard Öberg
Posted
Re: Article Summary
by
Corby Page
Posted
Re: Article Summary
by
Corby Page
Posted
Re: Article Summary
by
Rickard Öberg
Posted
The example doesn't scale well
by
Cristian Herling
Posted
Benefits of AOP for domain model
by
Rickard Öberg
We have been using AOP for the domain model in our code since 2002. We have used CGLIB for the infrastructure, and the patterns and usage is such that the interfaces and aspect implementations are plain Java/JavaBeans, i.e. there's no "framework leakage". We have found it to be a very very nice way to build highly reusable domain models (and the reuse also extends throughout the rest of the system, including UI's), and especially if you combine it with a persistence mechanism that understands "fragmented" objects.
Personally I'm not so worried about the cost of creating objects, as that is done reasonably seldom. The cost per invocation is more interesting. In our case we have tweaked it immensely, and have a base overhead that makes it possible to do about 15-20M "Hello World" calls per second, which is good enough for our purposes.
While I think that the particular implementation of AOP for domain models shown in this article is a bit "kludgy", as too much of it shows through in code, the basic idea is great.
Personally I'm not so worried about the cost of creating objects, as that is done reasonably seldom. The cost per invocation is more interesting. In our case we have tweaked it immensely, and have a base overhead that makes it possible to do about 15-20M "Hello World" calls per second, which is good enough for our purposes.
While I think that the particular implementation of AOP for domain models shown in this article is a bit "kludgy", as too much of it shows through in code, the basic idea is great.
Article Summary
by
Corby Page
Summary: AspectJ is the best way to advise domain objects without proxying overhead. Other high-performance solutions do not scale for complexity.
Re: Article Summary
by
Corby Page
Meaning that the solutions he offers basically involve handcrafting the proxy for each advised domain object. Works fine in an article with one or two domain objects, but not in a more realistic environment where you are used to defining pointcuts that affect a larger number of classes.
Re: Article Summary
by
Corby Page
Also, the solutions assume that you are responsible for instantiating all domain objects yourself. With the prevalence of POJO-based persistence frameworks, I don't find that to be a safe assumption these days.
The example doesn't scale well
by
Cristian Herling
Advising thru static decorators doesn't scale well because each advice/class pair requires a sub-class, the sub-classing effort will be prohibitive. You can indeed "have any number of advisors for Person and we can easily pick and choose which ones we use and can easily choose the order in which they advise Person" but you will end-up with a LOT of sub-classes.
The dynamic decorator example is more interesting, as far as I see you are creating a sub-class which acts as the advice and you are binding it to the original class. Now you are down to one decorating sub-class per advised class rather than one sub-class per advised class/advice as with static decoration. Once again this doesn't scale, imagine trying to implement a cross-cutting concern this way, the mushrooming of sub-classes will get out of proportions.
What you really need is a way to create one advice and have it attached to the target classes in a cost-effective manner. Spring and AspectJ do exactly this, but apparently each one has its drawbacks.
The dynamic decorator example is more interesting, as far as I see you are creating a sub-class which acts as the advice and you are binding it to the original class. Now you are down to one decorating sub-class per advised class rather than one sub-class per advised class/advice as with static decoration. Once again this doesn't scale, imagine trying to implement a cross-cutting concern this way, the mushrooming of sub-classes will get out of proportions.
What you really need is a way to create one advice and have it attached to the target classes in a cost-effective manner. Spring and AspectJ do exactly this, but apparently each one has its drawbacks.
Re: Article Summary
by
Rickard Öberg
Ok, then I see your point Corby. I agree, the solution shown was very "crafted" for each example, which is not really necessary. The framework I built does not have that property, so there is no magic involved with creating new objects, which is essential. I'd hate to see everyone having to use XDoclet just to generate AOP proxies... that'd... suck.
As for the POJO and persistence problem, I agree that creating an AOP-solution for domain model does require that you have a good persistence framework that supports it. But having it instantiate proxies instead of POJO's is probably going to be the least of your problems. It is much trickier to make a persistence layer that understands that one logical object may be composed of many small fragments. It's not rocket science, but does take some consideration.
The approach we took was to use Jisp/JDBM and plain serialization. We mostly access objects using id's, i.e. a navigational approach, but for the next version we are looking into storing the objects as binary XML (Fast InfoSet) and index them using RDF in a separate store. The tests I've done look very very promising, both for performance and what features this gives you.
As for the POJO and persistence problem, I agree that creating an AOP-solution for domain model does require that you have a good persistence framework that supports it. But having it instantiate proxies instead of POJO's is probably going to be the least of your problems. It is much trickier to make a persistence layer that understands that one logical object may be composed of many small fragments. It's not rocket science, but does take some consideration.
The approach we took was to use Jisp/JDBM and plain serialization. We mostly access objects using id's, i.e. a navigational approach, but for the next version we are looking into storing the objects as binary XML (Fast InfoSet) and index them using RDF in a separate store. The tests I've done look very very promising, both for performance and what features this gives you.
