AOP@Work: AOP and metadata: A perfect match, Part 2

Summary:  In this second half of his two-part article on combining metadata and AOP, author and AOP practitioner Ramnivas Laddad suggests a novel way to conceptualize metadata as a signature in a multidimensional concern space. He also introduces a series of guidelines for effectively combining metadata and AOP and discusses the impact of metadata annotations on the adoption of aspect-oriented programming.

View more content in this series

Date:  12 Apr 2005
Level:  Intermediate
Also available in:   Russian

Activity:  10822 views
Comments:  

In the first half of this article, I introduced the basics of the new Java™ metadata facility and explained how and where AOP's join point model could be most beneficially fortified by metadata annotation. I also gave an overview of existing metadata support in three leading AOP systems: AspectWerkz, AspectJ, and JBoss AOP. I touched on the impact of metadata on an AOP system's modularity, and concluded with a refactoring example demonstrating the gradual introduction of metadata annotation into an AOP system.

In this second half of the article, I'll suggest a novel way to look at metadata as a pathway into multidimensional signature space. This approach has a practical application in untangling element signatures and is also conceptually useful for designing annotation types, even for developers who do not practice AOP. I will also focus on the most beneficial use of metadata annotation in aspect-oriented programming. Among other things, I will demonstrate an effective use of AOP to reduce the loss of modularity that is sometimes associated with metadata annotation. I'll conclude the article with a set of guidelines for determining when and how best to use metadata. I'll also consider the effects of adding a metadata facility on the adoption of AOP.

The tyranny of the dominant signature

The signature of a program element such as a type, method, or field consists of a few components, including the element's name, access specification, base types, method arguments, exception specification, and so on. Not all components are applicable to every kind of program element, but in any case the name given to a program element is the most precious commodity, as it communicates the role of that element to its users.

In programming without metadata, you can use only one name in each program element. It is common in this scenario to name program elements after their dominant or primary role, which is usually the core logic implemented by the program element. For example, examine the signature for the credit method below:

public void credit(float amount);

The method name reflects only one property of the method: the business logic to perform the credit operation. All of the element's other characteristics are lost. While this signature is sufficient to inform clients using the method of its dominant role, it leaves other clients -- those that implement crosscutting concerns such as security and transaction management -- uninformed. This is the tyranny of the dominant signature, caused by the limitation of expressing the element with only one name.

An analogous situation is often discussed in AOP research literature: the tyranny of dominant decomposition, in which the prominent concerns (usually the business logic) dominate the class design, especially the inheritance hierarchy.

Back to top

Signature tangling

One way to ensure that an element's signature matches its crosscutting roles is to change its name to reflect all of its roles. For example, a credit operation that needed to also run inside a transaction and be authenticated might have the following signature:

public void transactional_authorized_credit(float amount);

While seeing a name like the one above does ensure that you will think about the method's crosscutting transaction and authentication requirements, the resulting code is ugly enough that few developers will utilize it. In fact, it is seen only under special circumstances such as using a special naming convention to mark methods for internal consumption.

The above approach can also pose serious problems as a system evolves. If a program element's crosscutting characteristics change, its name and all its referers will need to be changed accordingly. For example, if in the above example the system evolved so that credit operations no longer needed to be authorized, the method name would need to be changed to transactional_credit() and all of its method calls revised accordingly.

Another problem with this approach is that using names that combine elements from multiple concerns increases the cognitive burden on the caller. For example, the business caller of the above method is unconcerned with the method's other characteristics, but is still subjected to the other concerns.

If you are familiar with AOP, you already know that code-tangling -- mixing code from multiple concerns in a module -- can lead to obscure and difficult-to-maintain code. Signature tangling is similar. When a program element's name reflects its roles in multiple concerns, as it does in the above example, we call it a tangled signature.

Given a choice between signature tangling and obscure signatures (simply ignoring the other characteristics of the program elements and simplifying the above method name, for example, to credit()) most developers will go for simplicity. What you really need, however, is a third option. Adding metadata annotation to your element signatures lets you express non-core characteristics in a systematic way.

Back to top

Untangle me, metadata!

With the metadata facility in Java 5.0, you can use typed annotations to convey non-core characteristics programmatically. For example, the credit method that needs to be executed in transaction management and authenticated for security purposes could be annotated as follows:

@Transactional 
@Authorized
public void credit(float amount);

On the surface, the difference between using annotations versus the signature-tangled method name above seems superficial; after all, I've just moved non-core role designations from the method name to annotations. The real benefit to this approach is on the caller side, where the method's business clients do not need to understand other concerns. Business clients also need not modify their code when annotations attached to the method change.

In addition to untangling element signatures, annotations can be used to express any data associated with your code's crosscutting concerns. In this case, the annotation could incorporate parameters related to the concern. For example, the following method declares that its transaction must have the Required semantics, whereas the permission checked must be "accountModification".

@Transactional(Required)
@Authorized("accountModification")
public void credit(float amount);

As you can see, annotations are very handy for untangling the names of crosscutting elements into multiple pieces. Essentially, annotations let you express a program element's non-core characteristics without tangling their names or placing undue burden on the caller side.

Back to top

Metadata as a multidimensional signature

Conceptually, metadata can be seen as values in additional dimensions, which enable us to express the characteristics of a program element in a multidimensional space. Such a view facilitates a systematic approach toward dealing with metadata and aligning it with the goals of AOP. Even for developers who do not take an aspect-oriented approach, the multidimensional view of metadata is a valuable conceptual aid in designing annotation types.

You can approach the view of metadata as an enabler of multidimensional signature space in a systematic way: Each dimension of the space represents a concern, and the value expressed in each annotation represents a projection into the multidimensional signature space. Consider the signature for the credit() method just discussed. Figure 1 shows the credit() method in a three-dimensional signature space.

The name of the operation in Figure 1 essentially yields a value in a one-dimensional signature space. The only dimension of such a signature space is the business dimension and the value of the operation in that dimension (a.k.a. projection into that dimension) is "credit." Incorporating the Transactional annotation with the value property set to Required, I am able to evolve the example into a two-dimensional signature space. The value Required is the signature of the same method in the newly added transaction management dimension.

Similarly, consider the Authorized annotation with the value property set to "accountModification." In this instance, the addition of annotation adds another dimension, resulting in a three-dimensional signature space. Most signatures will yield significant value into only a few dimensions. This is similar to projecting a two-dimensional geometrical point into a three-dimensional space: The value of such projection will be zero in one dimension.

Without annotation, element signatures typically ignore non-core dimensions completely. The main cause of this inattention is the unavailability of a proper means to express them. The new Java metadata facility provides a concise way to express program characteristics in every dimension.

Back to top

Mapping signature space to concern space

AOP systems such as Hyper/J (now evolved into Concern Manipulation Environment; see Resources) emphasize the multidimensional view of the concern space; with metadata, we also have a way to provide multidimensional signature space.

In the concept of metadata as a multidimensional signature, each consumer of the signature uses only the projection that is relevant to its concern. So, in the previous example, a projection of the point represented by the signature into the business dimension would yield the name "credit". For the business concern's implementation all that matters is that the operation performed is the "credit operation." It does not know (or need to know about) values in any other dimension. For example, the business concern does not need to know the transactionality property.

Similarly, when the same operation is projected onto the transaction management dimension, we obtain the value Required. Now, from transaction management implementation's perspective, the value of the same point in the business dimension does not matter -- it could be credit, debit, or anything else. As you can guess, the same is true for the authentication concern's implementation: The point's projection into the business and transaction management dimensions are unimportant.

Back to top

Enabling multidimensional interfaces

Extending the notion of the multidimensional signature, annotations enable you to express multidimensional interfaces. Instead of having conventional one-dimensional interfaces expressing only the core dimension, you get multiple interfaces -- one for each concern in the application. The implementation of a concern then considers only the interface projected into the relevant dimension. Just as traditional interfaces serve well the object-oriented view of the world, the metadata-enabled ones -- aspectual interfaces -- serve the aspect-oriented view of the world.

AOP practitioners will recognize that the first introduction to AOP often involves explaining a similar multidimensional decomposition to the one enabled by the use of metadata. It is for this reason that metadata concepts map so well to AOP concepts. In a metadata-fortified AOP implementation, you map core concerns to classes just as you have all along. The difference is that you now map the system's crosscutting concerns to aspects that use a multidimensional interface, which is projected into the associated dimensions.

An example interface

Consider the example of the Account class in Listing 1. Notice how metadata annotation paves the way for the class's projection into multidimensional interfaces.

public class Account {
    @Transactional(kind=Required)
    @WriteOperation
    @Authorization(kind="bankModification")
    public void credit(float amount) {
        ... credit operation business logic
    }

    @Transactional(kind=Required)
    @WriteOperation
    @Authorization(kind="bankModification")
    public void debit(float amount) {
        ... debit operation business logic
    }

    @Transactional(kind=None)
    @ReadOperation
    @Authorization(kind="bankQuery")
    public float getBalance() {
        ... balance query operation business logic
    }

    ...

}

From the business perspective a projection of this interface would map to the following:

public class Account {
    public void credit(float amount) {
        ... credit operation business logic
    }

    public void debit(float amount) {
        ... debit operation business logic
    }

    public float getBalance() {
        ... balance query operation business logic
    }

    ...

}

The above interface simply includes all the members without any annotation. Projecting the same interface into the transaction management dimension would yield the following interface:

public class Account {
    @Transactional(kind=Required)
    * *.*(..)) {
    }

    @Transactional(kind=Required)
    * *.*(..)) {
    }

    @Transactional(kind=None)
    * *.*(..)) {
    }

    ...

}

In this example, I've used AspectJ wildcard notation to represent methods without consideration for name, type, argument, etc. Projections into other dimensions would work similarly.

Other dimensions

As previously explained, when a business client wants to use a method it needs to understand only the projection into the business dimension(s). For example, the transfer() method in the AccountServices class could be implemented as shown in Listing 2.

public class AccountServices {
    @Transactional(Required)
    public void transfer(Account to, Account from, float amount) {
        to.credit(amount);
        from.debit(amount);
    }
}

Apart from the annotation it carries (which you can ignore for the purpose of this discussion), there is nothing special about the above method's implementation. In particular, the business client -- the transfer() method -- does not know or care about the transactionality or authentication dimensions of the credit() or debit() methods.

Like the business client, the transaction management aspect is concerned only with its own dimension. (Note that Listing 3 is a refactoring of the aspect shown in Listing 2 of Part 1 of this article.)

public aspect TxMgmt {
    public pointcut transactedOps(Transactional tx)  
    : execution(@Transactional * *.*(..))
      && @annotation(tx);

    Object around(Transactional tx) : transactedOps(tx) {
        if(tx.value() == Required) {
            ...
        }
    }
}