Der Event Admin Service

Veröffentlicht in: Eclipse, Java, RCP | 0

Bei der Entwicklung von Software-Architekturen bekommt die Verwendung von Events und EventHandlern eine immer größere Bedeutung. Betrachtet man CQRS – Axon Framework – oder die CDI Events von JEE 6, so ist hier in letzter Zeit ein klarer Trend zu erkennen.

Umso erstaunlicher, dass das Konzept der Events schon seit Oktober 2005 im OSGI Standart – OSGI Service Compendium – existiert. So wird es vom Event Admin Service ermöglicht, Events zu versenden. Diese werden von EventHandlern, die als OSGI Service registriert seien müssen, behandelt. Da es sich bei dem Event Admin Service um einen OSGI Service handelt, kann dieser z.B. über die ServiceRegistry abgefragt werden:

ServiceReference serviceReference = context.getServiceReference(EventAdmin.class.getName());
EventAdmin eventAdmin = (EventAdmin) context.getService(serviceReference);

Um nun ein Event zu versenden, wird wie bei JMS (Java Message Service) ein Topic definiert, aufgrundlage dessen sich entscheidet, welche EventHandler auf das Event reagieren. Im Vergleich hierzu haben sich die CDI- und CQRS-Events deutlich weiterentwickelt, da es sich bei diesen um POJOs handelt, die bestimmen welche EventHandler zuständig sind. Die CDI-Events können zusätzlich noch Annotations als Qualifier verwendet werden, falls zu einem Event verschiedene Handler existieren, die aber nicht alle ausgeführt werden sollen. Sowohl die CDI- als auch die CQRS-Events beinhalten die Informationen, die vom Handler zur weiteren Verarbeitung benötigt werden. Beim Event Admin Service muss stattdessen ein Dictonary erstellt werden, welches diese Informationen in Form einer Map beinhaltet:

Dictionary eventProperties = new Hashtable();
eventProperties.put(„message“, „Hello World“);
Event event = new Event(„my/topic“, eventProperties);
eventAdmin.sendEvent(event);

Der EventHandler selbst muss das gleichnamige Interface implementieren und als OSGI Service mit dem entsprechenden Topic registriert werden. Hier die recht simple Implementierung des EventHandlers:

public class MyEventHandler implements EventHandler {
@Override
public void handleEvent(Event event) {
// handle the event
}
}

Folgendermassen wird nun der EventHandler als OSGI-Service registriert:

Dictionaryproperties = new Hashtable();
properties.put(EventConstants.EVENT_TOPIC, „my/topic“);
context.registerService(MyEventHandler.class.getName(), new MyEventHandler(), properties);

Um den Event Admin Service verwenden zu können, werden folgende Bundles benötigt:

  • org.eclipse.osgi
  • org.eclipse.osgi.services
  • org.eclipse.equinox.event
  • org.eclipse.equinox.ds

Events sind ein sehr gutes Mittel um Softwarearchitekturen zu entkoppeln. So ist es recht verwunderlich, dass es so lange gedauert hat, bis sich dieses Architektur-Pattern auch in anderen Frameworks wiedergefunden hat.

Aufsetzten eines CQRS Projektes mit dem Axon-Framework

Veröffentlicht in: Java | 0

Das Axon-Framework ist eine Implementierung des CQRS – Command Query Responsiblity Segregation – Pattern, welches zur Erstellung von skalierbaren und erweiterbaren Software-Architekturen dient. Zum Einsatz kommen hier Commands, Events und Querys, die in verschiedenen Bereichen der Software-Architektur verwendet werden.

Will der Benutzer über die UI mit dem System interagieren, stehen zunächst nur Commands zur Verfügung, die mit Hilfe von einem CommandBus ausgeführt werden. Für die Darstellung von Informationen werden wiederum Querys verwendet, die unveränderbare DTOs – Data Transfer Objects – liefern. Für diesen Teilbereich sind im Axon-Framework keine Implementierungen verfügbar, diese müssen aufgrund verschiedenster Einsatzbereiche selbst erstellt werden.

Die Commands werden in den CommandHandlern behandelt, die sich in einem von der UI getrennten Bereich der Software-Architektur befinden.

Hier können nun entweder direkt Events über einen EventBus verbreitet werden, wobei im Gegensatz zu Commands mehrere EventHandler auf ein Event reagieren können. Die Alternative zur direkten Verwendung von Events ist die Benutzung von Aggregates. Diese können entweder neu erzeugt und anschließend in einem Repository gespeichert werden oder es wird ein bestehendes Aggregate aus einem Repository geladen. Erst nachdem alle Operationen auf einem Aggregate ausgeführt wurden, werden die dazugehörigen Events veröffentlicht und von den EventHandlern verarbeitet. Dies passiert automatisch, sofern das Aggregate aus einem Repository geladen wurde, bzw. sobald ein neu erzeugtes Aggregate gespeichert wurde.

Die EventHandler sind unter anderem für die Speicherung von Daten in einer Datenbank zuständig. Dem Benutzer werden über diesen Weg allerdings keine Daten angezeigt, sondern lediglich manipuliert. Zum Anzeigen von Datenbank-Inhalten werden die anfangs erwähnten Querys und DTOs verwendet.

Kommen wir nun zu einem Beispiel, bei dem zunächst ein Benutzer angelegt und in einem zweiten Schritt manipuliert werden. Es wird hierbei ein UserAggregate eingesetzt, d.h. die entsprechenden CommandHandler Arbeiten nicht direkt mit Events, sondern verwenden stattdessen das Domain Model.

Zunächst einmal wird folgende Dependency benötigt:

<dependency>
<groupId>org.axonframework</groupId>
<artifactId>axon-core</artifactId>
<version>1.0</version>
</dependency>

Für die Integration des Axon-Frameworks in die Anwendung wird in diesem Beispiel Spring verwendet, wobei außer den Spring Bibliotheken keine weiteren Abhängigkeiten benötigt werden.

Hierfür wird der AnnotationCommandHandlerBeanPostProcessor zur Erkennung von Java-Beans mit der CommandHandler-Annotation, der CommandBus und zwei CommandHandler im Spring Kontext registriert. Letztere dienen zum Anlegen bzw. Aktualisieren des Benutzers.

<bean class=“org…AnnotationCommandHandlerBeanPostProcessor“ />

<bean id=“commandBus“ class=“org…SimpleCommandBus“/>
<bean id=“createHandler“ class=“..CreateUserHandler“ />
<bean id=“updateHandler“ class=“..UpdateUserHandler“ />

Der CreateUserHandler erzeugt zunächst ein neues UserAggregate, führt auf diesem die save-Operation aus und speichert es im UserRepository. Events die beim Erzeugen und innerhalb der save-Operation generiert werden, werden erst publiziert wenn das UserAggregate dem Repository mittels add hinzugefügt wird. Es folgt die Implementierung des CreateUserHandlers, der auf das CreateUserCommand reagiert:

@Component
public class CreateUserHandler {

@Autowired
private UserRepository userRepository;

@CommandHandler
public void handle(CreateUserCommand command) {
UserAggregate userAggregate = new UserAggregate(command.getUser());
userAggregate.save(command.getUser());
userRepository.add(userAggregate);
}
}

Das CreateUserCommand wird auf dem CommandBus ausgeführt, welcher mit Hilfe der Inject-Annotation in die gewünschte Klasse injiziert wird. Das Axon-Framework sorgt dafür, dass der gewünschte CommandHandler mit dem Command  als Übergabe-Parameter aufgerufen wird. Zum Ausführen des Commands wird folgende Zeile benötigt:

commandBus.dispatch(new CreateUserCommand(new User()));

Nun wird das UserAggregate erzeugt, dass von der Klasse AbstractEventSourcedAggregateRoot erbt. Wird ein UserAggregate erzeugt, wird gleichzeitig ein AggregateIdentifier angelegt, anhand dessen das Aggregate beim Speichern im UserRepository identifiziert wird. Jede Änderung des Aggregates die im Repository gespeichert wird, erhält eine neue Version, die von der eigenen Repository Implementierung gespeichert werden kann. Neben der Erzeugung des Identifiers wird im Konstruktor ein Event angelegt, dass in der zu implementierenden handle-Methode behandelt wird. Die Events, die in diesem Beispiel verwendet werden, erben alle vom DomainEvent, welches hier als Übergabe-Parameter dient.

Im CommandHandler wurde weiterhin die save-Methode aufgerufen, auch diese wird hier implementiert, wobei ein weiteres Event registriert wird. Hier nun der Beispiel-Code:

public class UserAggregate extends AbstractEventSourcedAggregateRoot {

public UserAggregate(User user) {
super(new UserAggregateIdentifier(user.getDsn()));
apply(new UserCreatedEvent(user));
}

@Override
protected void handle(DomainEvent event) {
// do what you have to do with the created user
}

public void save(User user) {
registerEvent(new UserSaveEvent(user));
}
}

Wie anfangs beschrieben, werden die Events erst ausgeführt, sobald das Aggregate im Repository gespeichert wird.

Folgendermaßen kann nun das UserRepositorys aussehen:

public class UserRepository extends AbstractRepository{

@Override
protected UserAggregate doLoad(AggregateIdentifier aggregateIdentifier, Long version) {
// load aggregate from a map for example
}

@Override
protected void doSave(UserAggregate aggregate) {

// save aggregate in a map for example
}
}

Im CommandHandler wird beim Aufruf der add-Methode des Repositorys die abstrakte doSave-Methode ausgeführt und das Aggregate gespeichert. Anschließend werden die registrierten Events ausgeführt. Hierbei wird das UserCreateEvent im Aggregate selber behandelt, dass UserSaveEvent aber im folgenden SaveEventListener, welcher lediglich zum Speichern des im Event befindlichen Users in der Datenbank zuständig ist:

@Component
public class SaveEventListener {

@Autowired
private HibernateTemplate hibernateTemplate;

@EventHandler
public void handle(UserSaveEvent event) {
hibernateTemplate.saveOrUpdate(event.getUser());
}
}

Für die Behandlung von Events sind folgende Spring-Konfigurationen vorzunehmen:

<bean class=“class=“org..AnnotationEventListenerBeanPostProcessor“ />
<bean id=“eventBus“ class=“org..SimpleEventBus“ />
<bean id=“updateListener“ class=“..SaveEventListener“ />

Interessant dürfte noch die Umsetzung eines UpdateUserHandler sein, da hierfür ein bestehendes Aggregate aus dem UserRepository geladen wird:

@Component
public class UpdateUserHandler {

  @Autowired
  private UserRepository userRepository;

  @CommandHandler
  public void handle(UpdateUserCommand command) {
    UserAggregate userAggregate = userRepository.load(new UserAggregateIdentifier(command.getIdentifier()), command.getVersion());
    userAggregate.save(command.getUser());
  }
}

Nachdem die save-Operation mit aktualisierten Benutzer-Daten aufgerufen wurde, muss das Aggregate nicht erneut im Repository gespeichert werden. Das Axon-Framework erkennt automatisch, dass es sich hierbei um eine neue Version des geladenen UserAggregates handelt und führt nach vollständigem Durchlauf des CommandHandlers alle registrierten Events aus.

In diesem Fall wird erneut das UserSaveEvent aufgerufen, der entsprechende Listener ausgeführt und damit die Änderung des Benutzers in der Datenbank gespeichert.

Dieses Beispiel soll einen Einblick in die Funktionsweise von CQRS und das Axon-Framework liefern, wobei einige Teilbereiche, wie z.B. der EventStore, ungenannt blieben. Ein Blick in den Reference-Guide sei allemal empfohlen.

CDI Events – Das Observer Pattern in Java EE 6

Veröffentlicht in: Java, JEE 6 | 2

CDI Events können als ein neues Architekturmuster für Java EE 6 Anwendungen gesehen werden, dass am meisten dem Observer Pattern ähnelt. Auch hier gibt es ein zu überwachendes Objekt, auf welches verschiedenste Komponenten reagieren, deren Implementierung aber unbekannt bleiben soll.

Um dies zu ermöglichen benötigt das zu überwachende Objekt Möglichkeiten zum Registrieren und Entfernen von sogenannten Observern, welche bei bestimmten Änderungen des Objektes benachrichtigt werden.

Bei CDI Events reichen einfache Annotations aus, um die Observer im CDI Kontext zu registrieren. Eine Registrierung beim überwachten Objekt selbst, ist nicht mehr nötig.

Dieses Objekt, bzw. Event ist ein ganz normales POJO mit beliebigen Attributen und entsprechenden getter– und setter Methoden.

public class UserEvent {

private String username;

public UserEvent() {}

public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
}

Um das Event zu feuern, auf welches anschließend von den Observern reagiert werden soll, ist folgendes Code Fragment nötig:

 @Inject
private Event<UserEvent> event;

public void doSomething() {
event.fire(new UserEvent(„Mustermann“));
}

Das Registrieren von Observern im CDI Kontext erfolgt mittels der Annotation @Observes und dem Event als Übergabe-Parameter. Der Observer kann nun seine Aufgabe verrichten und dabei auf das Event zugreifen. Die Implementierung eines Interfaces ist nicht mehr nötig:

public class UserHandler {
public void handleUser(@Observes UserEvent event) {
// do what you have to do …
}
}

Soll die Abarbeitung innerhalb eines Observers asynchron erfolgen, d.h. nach dem Aufruf der fire-Methode des Events nicht auf den Observer gewartet werden, kann dies mit der Annotation @Asynchronous innerhalb des Observers definiert werden:

@Stateless
public class UserHandler {

@Asynchronous
public void handleUser(@Observes UserEvent event) {
// do what you have to do … but asynchronously
}
}

Mit Hilfe von CDI Events kann man die Software-Architektur recht einfach entkoppeln und hat eine Möglichkeit geschaffen, leicht Funktions-Erweiterungen implementieren zu können.

Bereits vor CDI gab es Frameworks, die Events unterstützt haben. Hier sei das Axon Framework (CQRS – Command Query Responsibility Segregation) genannt, wobei hier das Event-, bzw. Command-Handling nur eine Komponente von vielen war.

Ganz neu ist die Event Idee auf jeden Fall nicht, nun hat sie aber ihren Weg in den Java EE Standard gefunden.