This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: How I'm Using AOP (in Real Apps) Right Now
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
I've seen a lot of people lately who think AOP is a joke because all they see is the typical logging and tracing examples. I personally (professionally) use it, so figured I would mention some of the ways. These are not in toy apps, but in real apps. In all cases these are done via DynAOP or AspectJ depending on various other constraints at the moment. Aspectwerks is high on my list to try out, just haven't yet. I think my experiences with JRockit are holding me back there.
Persistence and Transactions:
Declarative transactions outside of EJB containers are an obvious one up there with tracing and logging. In addition to that, however, a number of other sophisticated persistence systems can be arranged with a good O/R mapping tool and aspects. One of the more useful has been that advice can be applied to constructors to makePersistent new persistent objects created via new magic are also transparently (and transactionally) stored. Declaring a pointcut to match on the o/r mapping metadata I haven't quite worked out yet -- so right now the pointcut def'n needs to be watched as persistent classes are added/factored. This is annoying, but not insufferable. It could be solved via a tag interface, or namespace/naming requirements but that starts to break transparence. I'm using namespace requirement at the moment, but I don't like it much.
Rule-Based Access Policies
Permissions to do CRUD operations on these persistent objects can be managed by a rules system. We have a really big application with a lot of users with incredibly different permissions profiles. We have talked half seriously about having to go to a certified multilevel secure system as we have all but implemented it as such. The tricksy part is being able to conveniently apply access policies across everything. AOP solves this much more easily than JAAS or any home-rolled system I have seen. The collection-projections we can do are the nicest part, Java doesn't provide the ability to actually remove properties/methods so we have to throw exceptions or just noop out things instead. It hurts to think about going back to per-AOP access policy declaration and enforcement.
Transparent Proxying
Sometimes the best solution is a remote object. Not very often, but sometimes. Forget EJB's as interface to RMI, pita. Axis and AOP is much nicer. Side benefit -- can access the same remote object as easily from Ruby (would say Groovy except that I'm not actually doing that in a real app -- and it is a boring example as I would just use Axis again.) Aside from remote, non-transactional objects can act as proxies for transactional objects (as long as the non-transactional one has enough info to build an identity). I've used this, but not yet deployed anything using it. I suspect I will in the future as it makes a large number of clienty things more convenient -- and a convenient client API is important.
Previous Topic
