Section 13.4. RELATED WORK

13.4. RELATED WORK

We have described a mechanism for separately specifying system-wide concerns in a component-based programming system and then weaving the code handling those concerns into a working application. This is the theme of Aspect-Oriented Programming (AOP). OIF is an instance of AOP, and brings to AOP a particularly elegant division of responsibilities. Key work on AOP includes Harrison and Ossher's Subject-Oriented Programming [6] which extends OOP to handle different subjective perspectives; Aksit and Tekinerdogans message filters [1], which, like OIF, reify communication interceptors; Lieberherr's Adaptive programming [9], which proposed writing traversal strategies against partial specifications; and Kiczales and Lopes' [7] language for separate specifications of aspects, which effectively performs mixins at the source-code language level. Czarnecki and Eisenecker's book [3] includes a good survey of AOP technology.

The idea of intercepting communications has occurred several times in the history of computer science. Perhaps the earliest examples were in Lisp: the Interlisp advice mechanism and mixins of MacLisp.

It is common to tackle ility concerns by providing a framework with specific choices about those concerns. Examples include transaction monitors like Encina™ and Tuxedo^® and distributed frameworks like Enterprise Java Beans and CORBA. It is worth noting that the CORBA security specification and many commercial CORBA implementations are emerging with some form of user-defined filter mechanism on communications. While these mechanisms are not as general as OIF, our work can be understood as a methodology for using CORBA filters.

The use of a separate specification language for creating filters parallels the work at BBN on quality of service [10], where the IDL-like Quality Description Language is woven with IDL to affect system performance.