OSGi and AspectJ into Equinox Aspects
In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method.
Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies—including procedural programming and object-oriented programming—support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they “cut” across multiple modules in a program.
Any AOP language has some crosscutting expressions that encapsulate the concern in one place. The difference between AOP languages lies in the power, safety, and usability of the constructs provided. For example, interceptors that specify the methods to intercept express a limited form of crosscutting, without much support for type-safety or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, an aspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). An aspect can also make binary-compatible structural changes to other classes, like adding members or parents.
Many AOP languages support method executions and field references as join points. In them the developer can write a pointcut to match, for example, all field-set operations on specific fields, and code to run when the field is actually set. Some also support things like defining a method in an aspect on another class. AOP languages can be compared based on the join points they expose, the language they use to specify the join points, the operations permitted at the join points, and the structural enhancements that can be expressed.
AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely-used de-facto standard for AOP by emphasizing simplicity and usability for end users. It uses Java-like syntax and has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.
Equinox Aspects: the goal is to allow developers to use the Equinox together with AspectJ by combining the benefits of both worlds. Using a load-time weaving extension you are able to add AspectJ aspects to your bundle-based system just by putting them into general OSGi bundles. It does not matter if the pointcuts you defined inside the aspects contain join points that are defined by classes within the same bundle or any other bundle in your installation. The load-time weaving extension will take care that your aspects are woven with the appropriate classes at load-time.
Finally aspects become dynamic (Martin Lippert)
I recently committed some changes to the Equinox Aspects project which allows the Equinox Aspects runtime to handle dynamically uninstalled aspects correctly with regards to the woven bundles in the system. Having this it was only a small step to also deal with dynamic updates to aspect bundles as well as woven bundles at runtime. And now, finally, we are there: real dynamics for aspects. You can install, update and uninstall aspects at runtime as you like and the Equinox Aspects runtime takes care that everything will be woven and re-woven correctly. This is really really cool and a huge step towards real OSGi-enabled AOP, I think.
But what happens if aspect bundles are installed, updated or uninstalled at runtime? All other bundles that need to be woven, that need to be re-woven or that need to be un-woven from the aspect are updated automatically by the aspect runtime using the OSGi mechanisms. This means also that your system should be able to deal with OSGi dynamics and bundles coming and going (which is not a trivial thing to do). So be a good citizen of the OSGi world and your bundles will behave well when aspects are coming and going at runtime… 🙂