Der folgende Artikel beschäftigt sich mit Spring 3.x AOP, wobei Spring lediglich den Support für das eigentliche AOP-Framework AspectJ zur Verfügung stellt. Die Aspekt orientierte Programmierung – kurz AOP – ermöglicht es, die eigentliche Business-Logik einer Anwendung von querschnittlichen Aspekten zu trennen. Als typische Aspekte seien hier Logging- oder Security-Layer genannt. Statt nun die Aspekte mit der Business-Logik zu verweben, findet eine klare Kapselung statt, die es ermöglicht, die Aspekte autonom umzusetzen und anschließend explizit über die Business-Logik zu legen. So können öffentliche Methoden, ganze Projekte, einzelne Packages oder nur bestimmte Methoden eines Services mit Aspekten versehen werden.
Der Artikel erläutert wann und wie ein Aspekt in den Programmfluss eingreifen kann und wie die Aspekte mit der Business-Logik verwoben werden. Ersteres wird über Advices, Zweiteres per Pointcuts realisiert.
Bevor es an die Implementierung geht, müssen zunächst die entsprechenden Libraries eingebunden werden. Für den Spring AOP Support werden die Libraries core und context benötigt, die aktuell in der Version 3.1.0 verfügbar sind:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.1.0.RELEASE</version>
</dependency><dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.1.0.RELEASE</version>
</dependency>
Wie bereits erwähnt handelt es sich bei Spring lediglich um den Wrapper um die AOP-Schicht. Für das eigentliche AOP Framework AspectJ werden folgende Libraries verwendet:
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>com.springsource.org.aspectj.runtime</artifactId>
<version>1.7.0</version>
</dependency><dependency>
<groupId>org.aspectj</groupId>
<artifactId>com.springsource.org.aspectj.weaver</artifactId>
<version>1.7.0</version>
</dependency>
Um den AspectJ-Support für Spring zu aktivieren, muss folgende Zeile in der Spring-Konfiguration aufgenommen werden:
<aop:aspectj-autoproxy/>
Anschließend wird die Klasse MyService erstellt, welche die eigentliche Business-Logik beinhalten soll.
public class MyService {
public void doSomeStuff() {
// do some business logic
}
}
Dieser Service soll nun mit einem Aspekt versehen werden, der z.B. das Logging von der Business-Logik kapselt.
@Aspect
public class MyAspect {@Before(„execution (* de.mz.MyService.doSomeStuff(..))“)
public void aspect() {
// do some logging
}
}
Nun muss sowohl der Service als auch der Aspekt als Spring-Bean definiert werden:
<bean id=“myAspect“ class=“de.mz.MyAspect“ />
<bean id=“myService“ class=“de.mz.MyService“ />
Wird nun die Methode doSomeStuff des MyService aufgerufen, wird nicht nur die eigentliche Methode, sondern auch der Aspekt ausgeführt. Die Reihenfolge wird hierbei über den Advice definiert. In obigen Beispiel wird dieser über die Before-Annotation festgelegt, so dass zuerst der Aspekt und erst anschließend die Methode des MyService ausgeführt wird.
Die folgenden Advices bieten die Möglichkeit Eingriffe im Programmfluss vorzunehmen:
- Before – Der Aspekt wird vor der eigentlichen Methode ausgeführt.
- Around – Die Methodenausführung findet im Aspekt selber statt. Es kann also vor und nach der Methodenausführung eingegriffen werden.
- After – Der Aspekt wird erst nach der Methodenausführung aktiv.
- AfterReturning – Dieser Aspekt wird ebenfalls erst nach der Methodenausführung aktiv, es kann allerdings zusätzlich auf den Rückgabewert zugegriffen werden.
- AfterThrowing – Der Aspekt wird nur aktiv, sofern in der eigentlichen Methode ein Fehler auftritt.
Um Methoden mit Aspekten zu versehen, werden die bereits erwähnten Pointcuts verwendet. In obigem Beispiel wurde der Pointcut einfach in der Before-Annotation mit angegeben. Wesentlich eleganter ist es, Pointcuts separat zu definieren und im Advice lediglich auf sie zu verweisen. So können die Pointcuts mehrfach verwendet werden und sind beliebig kombinierbar:
@Pointcut(„execution (* de.mz.MyService.doSomeStuff(..))“)
private void pointcutForDoSomeStuff() {}@Before(„pointcutForDoSomeStuff()“)
public void aspect() {
// do what the aspect has to do
}
Nun wird in der Pointcut-Annotation auf die doSomeStuff-Methode vom MyService verwiesen, wobei der Pointcut selber lediglich aus einer leeren Methoden besteht, deren Rückgabetyp void seien muss. Auch wenn es nicht zwingen notwendig ist, wird als Sichtbarkeit private festgelegt, damit der Pointcut nicht aufgerufen werden kann. Auf die Pointcut-Methode wird nun in der Before-Annotation verwiesen.
Es gibt verschiedene Möglichkeiten mit denen Pointcut-Ausdrücke auf entsprechende Java-Resourcen gematched werden können. Um auf Methoden zu matchen, wird der bereits verwendete Pointcut-Designator (PCD) execution verwendet. Es ist nicht zwingend notwendig, dass hier nur explizit auf eine Methode verwiesen wird, so kann z.B. auch auf alle öffentlichen Methoden des MyService verwiesen werden:
@Before(„execution(public * de.mz.MyService.*(..)))“)
Alternativ können auch alle öffentlichen Methoden – bzw. alle Methoden mit einer fest definierten Sichtbarkeit – mit einem Aspekt versehen werden:
@Before(„execution(public * *(..))“)
Will man Aspekte nicht für Methoden sondern auf einer bestimmten Package-Ebene definieren, wird statt dem execution Designator within verwendet:
@Pointcut(„within(de.mz.*)“)
Sollen zusätzlich die Sub-Packages mit Aspekten versehen werden, muss das Statement minimal angepasst werden:
@Pointcut(„within(de..*)“)
Weiterhin kann man alle Klassen, die ein bestimmtes Interface implementieren mit einem Aspekten versehen, indem man den Designator this verwendet. Würde der MyService nun das Interface IMyService implementieren, würde auch folgender Pointcut matchen:
@Pointcut(„this(de.mz.IMyService)“)
Es gibt noch viele weitere Möglichkeiten, so dass sich hier ein Blick in die Dokumentation allemal lohnt:
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/aop.html
Wie bereits erwähnt, können Pointcuts auch kombiniert werden. Hierbei sind AND &&, OR || und NOT ! Verknüpfungen möglich.
Sollen die Methode doSomeStuff und doSomeOtherStuff denselben Aspekt erhalten wird zunächst ein weiterer Pointcut für die zweite Methode definiert:
@Pointcut(„execution (* de.mz.MyService.doSomeOtherStuff())“)
private void pointcutForSomeOtherStuff() {}
Anschließend können beide Pointcuts mit ODER Verknüpft werden, so dass der Aspekt ausgeführt wird, sobald eine der Methoden aufgerufen wird:
@Pointcut(„pointcutForDoSomeStuff() || pointcutForSomeOtherStuff()“)
private void allPointcuts() {}
Weiterhin kann es nützlich sein im Aspekt auf die Übergabeparameter der aufgerufenen Methode zugreifen zu können. Hierzu wird die Methode doSomeStuff um zwei Übergabeparameter vom Typ String erweitert:
public void doSomeStuff(String para1, String para2) {
// do some business logic
}
Der bestehende Pointcut wird mittels UND mit dem Designator args verknüpft, welcher Zugriff auf die Parameter gewährt. Diese stehen dem Aspekt dann als eigene Übergabeparameter zur Verfügung:
@Before(„pointcutForDoSomeStuff() && args(para1,para2)“)
public void printParams(String para1, String para2) {
// nice aspect with access to parameters
}
Interessiert einen nur der erste Parameter, sieht das Statement so aus:
@Before(„pointcutForDoSomeStuff() && args(para1,..)“)
Für Zugriff auf den zweiten Parameter muss folgende Modifizierung vorgenommen werden:
@Before(„pointcutForDoSomeStuff() && args(..,para2)“)
Da aus Programmierer Sicht kein Unterschied zwischen Before- und After-Advice existiert, beschäftigt sich das folgende Beispiel mit dem Around-Advice. Hier ergeben sich interessante Möglichkeiten, da der Aspekt Zugriff auf den JoinPoint erhält und für dessen Ausführung zuständig ist. Bei dem JoinPoint handelt es sich um die mit einem Aspekt versehene Methode. Dadurch das die Ausführung dem Aspekt obliegt, kann im Fehlerfall eingegriffen und z.B. ein Retry-Mechanismus implementiert werden. Die Exception kann gecatched und der Methoden-Aufruf beliebig oft wiederholt werden:
@Around(„pointcutForDoSomeStuff“)
public Object retryexecution(ProceedingJoinPoint joinPoint) throws Throwable {
Exception exception = null;
int i = 0;
while (i < MAX_RETRY) {
try {
return joinPoint.proceed();
} catch (MyException e) {
exception = e;
}
i++;
}
throw exception;
}
Grade beim Aufruf von externen Services in verteilten Systemen kann so ein Retry-Mechanismus Sinn machen. Geht der erste Aufruf noch auf einen defekten Service, so kann der zweite erfolgreich die gewünschte Arbeit verrichten. Der Benutzer bekommt hierbei nicht einmal mit, dass ein Fehlverhalten aufgetreten ist.
Wer bereits mit Spring 2.x AOP gearbeitet hat, dem wird das Handling der obigen Beispiele vertraut vorkommen. Tatsächlich hat sich die Spring-API im AOP-Bereich seit der letzten Spring Version nicht geändert. Aufgrund der komfortablen API ist dies aber auch nicht Notwendig.