Aspect-Oriented Programming for Distributed Systems:
Its Use, Its Effect on Language Design, and Its Limits

Abstract

Building distributed applications involves many different concerns,
for example application functionality, distribution structure, tolerance
for partial failure, and security. Instead of trying to build a generic
tool that could handle all these concerns, we will treat each concern
in depth (solve it completely) before going to the next. We consider
each aspect as a partial specification, and the full specification as the
conjunction of all these partial specifications. The crucial property is
independence: each new partial specification that is added should not
invalidate the previous ones. We have been following this approach
for almost a decade now in our work on the
Oz language and the
Mozart system.
In this talk I will give some examples of how it works for real
applications and then conclude with some lessons we have learned.

A first lesson is that language design is an important part of the solution:
keeping independence imposes strong conditions on the language.
A second lesson is that to make each aspect work in realistic conditions,
we have to change the application architecture. Simple source
transformations are not enough. In hindsight this is obvious, since we
have no automatic technique for going from specification to program.
A final lesson is regarding the limits of aspect-oriented programming.
Even with the best possible AOP, complexity increases because of
the large number of aspects, each of which requires changes in the
application architecture. At some point we need to go beyond AOP.
We propose a simple and time-honored solution: to find "good enough"
solutions for certain aspects and then to hide them inside abstraction
layers. We finish the talk by summarizing what we have realized in Oz
and Mozart and outlining the large amount of work that still has to be done.