Sunday, April 22, 2007 

AOP and Layered Virtual Machines

I've been thinking about AOP and virtual machines for a while now. I don't mean adapting virtual machines to better support AOP: that's a relatively straightforward concept, and the subject of a wealth of research. I mean using virtual machines as a metaphor to think about AOP (or, better, AOD).

Let's start looking at the issue from a different angle. Unless you're working on a small embedded system, chances are you're already running your application on a virtual machine. I don't mean something like the JVM or the .NET CLR (although that might be the case). The operating system itself is presenting you with a virtual machine.

In many cases (virtual memory, I/O virtualization, etc) the virtual machine is intercepting your code at a very small granularity, doing some pre/post processing or routing your call to some piece of code. In those cases, your code is totally oblivious (caller obliviousness). Being the OS a general-purpose virtual machine, we also have callee obliviousness (see also my post, Some notes on AOP for a little more on obliviousness).

Let's stay with this concept a little more. The OS is also offering you a set of services which must be explicitly invoked: they can't be hidden through mere virtualization. If I want to open a file and write something, I've to open the file and write something :-). The OS can abstract away a lot of concerns (the file system implementation, the disk driver implementation, etc) but this is not a "ility" that can be somehow injected - it's a functional concern.

Or maybe it is. Maybe it's just a matter of abstraction. Maybe you don't really want to open a file and write something. Maybe you just want to persist an object model. Lo and behold, persistence can be easily modeled as an hidden service, but in a different virtual machine: one that is not working at the OS level, but at the object model level (like the ubiquitous JVM).

In practice, we always have a hierarchy of virtual machines, at different layers and with different granularity. What we often miss is the ability to modify the behaviour of existing VMs (which was the idea behind the Meta Object Protocol concept) or to easily create new (application-level) VMs.

When you look at AOP from this perspective, what a set of pointcuts and advices often does is to create a specialized virtual machine at the application level. Recently, this perspective helped me get a better grip on the design heuristics I'm using in mixed OOP-AOP environments. I'm not completely satisfied, and I've no claims of universality, but it was worth sharing.

On a side note, I did some research to check if the idea had already been explored. I didn't find much, with one notable exception: Concerned about separation by Mili, Sahraoui, Lounis (FASE/ETAPS, 2006). Although the focus is different, the authors elaborate on the idea that some non-functional concerns at the application level can be seen as a functional concern at the virtual machine level. I like this idea quite a bit.

Labels: , ,

Comments:
Molto interessante. Ho alcune domande:

1) a proposito della macchina virtuale per la persistenza: e' solo un esempio o la vorresti davvero? (Magari esiste gia' qualcosa?)
2) che vantaggi avrebbe rispetto a un qualunque framework dedicato fatto bene?
3) quali altre macchine virtuali potrebbero stare a livello dell'applicazione?

Specifico meglio il punto 2. Supponi di avere un sistema che permette di disegnare un document model. Il modello e' utilizzabile dall'applicativo, e sa gestire la persistenza da solo. Questo per me e' un framework. Quanto si avvicina all'idea di macchina virtuale che hai proposto?

Ciao
 
1) e' solo un esempio, piuttosto in voga in ambiente AOP e AOP-like. Ne esistono molte (anche se non vengono presentate come virtual machine), ad es. la famiglia Hibernate / NHibernate. Hanno, come sempre, una sfilza di pro e contro...

2/3) Tieni presente che l'idea della macchina virtuale e' piu' che altro una metafora di design. Se tu approcci un problema (soprattutto in stile AOP, o mixed OOP-AOP) con l'idea "sto costruendo una macchina virtuale che...", il modello di pensiero che adotti e' diverso, la separation of concern avviene su assi [leggermente] diversi. Devo dedicare un post alla cosa con un esempio concreto, non e' proprio un concetto immediato da trasmettere.

Su quanto aggiungi: non so se ho capito :-), ma mi pare piu' vicino ad un esempio di meta-programmazione, ovvero programmi in un ambiente (dove "disegni" il document model) che genera codice usabile dall'applicativo, che tra le altre cose gestisce anche la persistenza. Questo non e' esattamente un framework (se ho capito cosa intendi).
E' molto distante da un concetto di macchina virtuale, che in questo caso dovrebbe essere il piu' possibile invisibile (nel codice ed a maggior ragione nei tool) al programmmatore. Ovviamente, per creare nuovi layer di macchine virtuali abbiamo bisogno di un ambiente run-time ricco; questo e' cio' che piu' di ogni altra cosa sta marginalizzando il C++ (che e' un peccato, vista la vocazione multiparadigma del linguaggio).

Torno sull'argomento quanto prima con un esempio piccolo ma concreto.
 
Si fa sempre piu' interessante, aspetto l'esempio!
 
Post a Comment

<< Home