BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News InfoQ Article: Application Failover using AOP

InfoQ Article: Application Failover using AOP

Bookmarks
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!

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Sure

    by Rickard Öberg,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT