Aspect-oriented programming is, among other things, the attempt to define and centralize cross-cutting concerns. In other words, it's not much more than the tried-and-true principle of modularization. Having possibly unseen aspects operating on a given class, however, can complicate an initial examination of the code. Therefore, it's important to be aware of what portions of the OMERO code base are "advised" and where to find the advisors (in the case of OMERO solely interceptors).

In Spring, advisors are declared in the bean definition files (under http://trac.openmicroscopy.org.uk/omero/browser/trunk/components/server/resources/ome/services, most important are services.xml, services.xml, hibernate.xml, and others.

In these configuration files, various Spring beans (shared objects) are defined with names like "proxyHandler", "eventHandler", "serviceHandler", and "transactionHandler". Each of these is a method interceptor which is passed execution before the actual logic is reached. The interceptor can inspect or replace the return value, but can also stop the method execution from ever taking place.

Unlike with AspectJ, the AOP implementation used by OMERO only allows for the advising of interfaces. Simply creating a new service implementation via "new QueryImpl?()" will not produce an advised object, which can in turn will not function properly if at all. Instead, an advised objects can only be acquired from the Spring ((Omero Context|context)).

By and large, only the API service methods are advised in OMERO.

Why

Often, when implementing or adding code, it becomes clear just how many requirements are placed by libraries, the application server, and existing code on any new code. This can include transaction handling, session handling, security checks, object validation, logging, etc. As a code-base grows, these dependencies slow development and makes code unmanageable. AOP tries to reduce these dependencies by defining each of these concerns in a single place.

As a quick example, in OMERO transactions and exceptions are handled through method interceptors. Rather than writing:

    void method1(){
        try {

            Transaction tx = new Transaction();
            tx.begin();
            // your code goes here
            tx.commit();
        } catch (TxException e) {
             tx.rollback();
        } catch (OtherException e) {

        }

    }

one just writes:

    void method1(){
        // your code goes here
    }

References:

• http://static.springframework.org/spring/docs/2.0.x/reference/aop.html -- Spring AOP documentation
• http://aopalliance.sourceforge.net/ -- Joint project defining interfaces for various AOP implementations.
• http://eclipse.org/aspectj/ -- The arguable leader in Java/AOP development. Not used in Omero, but a good starting point.
• http://en.wikipedia.org/wiki/Aspect-oriented_programming