InfoQ Article: Application Failover using AOP

by Floyd Marinescu on Jul 04, 2006 |

AOP has recently been in the midst of controversies with Gavin King snubbing it as a totally over hyped, failed technology and Cedric Beust also expressing serious doubts regarding aspects making it to mainstream programming, branding AOP as a great idea that will remain the privilege of a few expert developers.

In this latest InfoQ article, Debasish Gosh writes about how AOP was used on a large financial project to transparently implement error handling logic over the Oracle 10g RAC database and IBM MQSeries, to enable transparent failover.

The result was great! We achieved the goal with minimal impact on the existing codebase - thanks to the power of AOP. We used AspectJ and compile time weaving - the build time went up, but the client had a happy face using AOP as the enabler technology to prevent the big impact on codebase.

Have you used AOP to solve production issues like this? Share your thoughts!

Related Editorial

Cluster-Wide Caching & Scaling for the Cloud - A Look Inside Resin 4.0

Faster PHP Through Java

ICEmobile in a Minute - The Easiest Way to Mobilize Your Enterprise Apps

Enterprise-class API Patterns for Cloud & Mobile

Agile workshops and training

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or 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

Sure by Rickard Öberg Posted

Re: Sure by Corby Page Posted

Re: Sure by Rickard Öberg Posted

Good article showing a pragmatic use of AspectJ by Ramnivas Laddad Posted

Modularized Failover by Brian Sletten Posted

Re: Modularized Failover by ARI ZILKA Posted

Re: Modularized Failover by Ken Carroll Posted

Sure by Rickard Öberg

I've said this a bunch of times before, but I'll say it again: we created our CMS/portal from scratch in 2002 based entirely on AOP for both services and our domain model (as described in quite some detail on my blog). Some of the things could possibly be done using so-called "simpler" things like interceptors, but some things simply cannot be done using any other technology, such as the domain model whereby each "class" is composed by adding reusable aspects. Some things, like typed aspects as Adrian pointed out to Gavin, are things that are critical to have in a so-called real system.

So to say that AOP is a "failed technology" is simply uninformed and based on limited experience. There are many places where it does not fit, and there are some places where no other technology fits.

Re: Sure by Corby Page

but some things simply cannot be done using any other technology, such as the domain model whereby each "class" is composed by adding reusable aspects.

I certainly agree that AOP is an important and successful technology, but I do get a bit confused about why it is good to compose your domain model from aspects.

The joy I get from AOP is from its flexibility to recompose the system on the fly. I can make a broad, consistent change by introducing or editing a pointcut without touching my core domain or services.

If you decide to compose your domain out of aspects, then it puts a lot of pressure on you to get the aspect separation right the first time. This is something I probably wouldn't trust myself (or most other architects) to do. When you change your mind later, recomposing pointcuts is very easy. Recomposing all of the code that you used to construct your domain model is very hard.

It seems that in a non-trivial system, such as your CMS, composing your domain out of aspects puts too much pressure on getting the upfront design exactly right the first time, at the expense of being able to make flexible changes down the line.

Re: Sure by Rickard Öberg

I certainly agree that AOP is an important and successful technology, but I do get a bit confused about why it is good to compose your domain model from aspects.

The joy I get from AOP is from its flexibility to recompose the system on the fly. I can make a broad, consistent change by introducing or editing a pointcut without touching my core domain or services.

If you decide to compose your domain out of aspects, then it puts a lot of pressure on you to get the aspect separation right the first time. This is something I probably wouldn't trust myself (or most other architects) to do. When you change your mind later, recomposing pointcuts is very easy. Recomposing all of the code that you used to construct your domain model is very hard.

It seems that in a non-trivial system, such as your CMS, composing your domain out of aspects puts too much pressure on getting the upfront design exactly right the first time, at the expense of being able to make flexible changes down the line.

I guess it depends on what tools you use to do schema migration. In our case we simply dump the database to a big fat XML file, to an XSL on it to migrate it to whatever new model or refactorings we've done, and import it back. We can move fields between aspects, split aspects, merge aspects, move fields from one object to a hashmap in a referenced object, etc. etc. And not only *can* we do this, *we have*.

In fact, using XML+XSL is so neat that even people using relational databases might want to consider it as a means for schema migration.

The benefit of being able to use AOP for domain model construction is that you don't have to repeat fields that you want everywhere (last modified timestamps, metadata, ACL's) etc. The alternative would be to use plain OO composition, but that's worse from a lifecycle management point of view, and the code becomes more complicated (been there, tried that). Being able to do "obj instanceof ACL" anywhere to check its capabilities is very powerful and intuitive.

Good article showing a pragmatic use of AspectJ by Ramnivas Laddad

Good article...

These kinds of applications show the real power of AOP and allow discussion surrounding it to move from theoretical arguments to practical facts. Basically, we can discuss merits of AOP in context of applications such as this; if someone hates AOP, they will have to show an alternative solution that is better than this :-).

Automatic failover and other kinds of error-handling are critical to high-availability applications. Yet, we don't see many applications implementing a failover scheme, much less a consistent scheme. The reason, I suspect, is shear cost of implementation. Even when you are ready to pay the cost, scattered code leads to an inconsistent implementation lacking any overall purpose and understanding. AOP-based solutions significantly reduce the cost, produce consistent solution, and lower maintenance cost.

-Ramnivas
ramnivas.com

Modularized Failover by Brian Sletten

It's nice to see this idea being discussed further. This was exactly the problem that made me yearn for AOP in 1999 even before I was familiar with the tools. I considered hand-rolling something with reflection but abandoned the approach because I had other things that needed to get done. The moment I read about AspectJ in 2000, I knew that it would be a great solution for this problem. Since then, with a new way of thinking, I have been able to solve several problems that would have been significantly more difficult or impossible without AspectJ. If there has been a failure, it is a messaging failure, not technical.

Re: Modularized Failover by ARI ZILKA

JDBC failover and MQ failover can be achieved w/o AOP. I feel the example is on a good track, but can be trivially achieved with a "fail-over" capable JDBC driver since JDBC is already behind a clean interface that requires the developer to wrap everything in try/catch. Check out general-purpose clustering w/ fault tolerance. AOP concepts are powerful, I agree. When applied to achieve something like working around Java native Serialization, then AOP delivers where no other solution can.

www.terracottatech.com/

--Ari

Re: Modularized Failover by Ken Carroll

Using AOP is a perfect match for dealing with failover. It simply cannot, except in very simple cases, be done with a failover capable jdbc driver because that is completely unaware of the full context, especially the full transaction context. If, for example, there are multiple sql statements all contained within a single transaction then, with FCF and TAF (and others such as DB2 ACR), the client application must rollback and replay all of the sql statements. Although this article is summary and glosses over such details they are vital to a reliable & robust failover solution. Far too many people have gone down the dead-end road of trying to use a failover aware jdbc driver only to experience serious bad consequences.