Ein interessantes Thema der Context and Dependency Injection Spezifikation sind für mich die CDI-Events. Mit ihnen lassen sich die Anwendungskomponenten in einer losen Art koppeln. Ich verwende diese Möglichkeit gerne in der Anwendungsentwicklung, damit komme ich ohne zig Injektionspunkte in einer Klasse aus.
Mit Signals hat Quarkus ein experimentelles Feature hinzugefügt, welches die Idee von CDI Events aufgreift, diese aber noch etwas erweitert. Ein Signal besteht dabei aus folgenden Teilen:
- Signal Objekt -> Instanz einer beliebigen Java-Klasse
- optionale Qualifier -> Zur Abbildung unterschiedlicher Ausprägungen von Signalen
- optionale Metadaten -> Attribute zur Übertragung weiterer Informationen
Als Beispiel möchte ich eine einfache REST-API erstellen, mit der man sich zu Vorträgen anmelden kann. Wir starten mit unserem Signal Objekt mit den Registrierungsdaten. Ein Signal Objekt sollte immer immutable sein, daher bietet sich der Einsatz von Records an.
public record Registration(String name, String email, String talk) {
}
Signale senden
Das REST-API bietet über eine POST-Methode die Möglichkeit ein Registration Objekt anzunehmen. In dieser Methode sollten nun die weiteren Schritte zur Verarbeitung der Registrierung ausgelöst werden. Dazu holen wir uns über einen Injektionspunkt das entsprechend typisierte Signal.
@Inject
Signal<Registration> registrationSignal;
Es gibt insgesamt drei Möglichkeiten ein Signal zu versenden. Publish (Multicast) liefert das Signal an alle Empfänger aus. Send (Unicast) sendet das Signal an genau einen Empfänger. Dieser wird nach dem Round-Robin-Verfahren ermittelt. Request (Unicast, Request-Reply) liefert das Signal an einen einzigen Empfänger aus, der mit dem gewünschten Rückgabewert übereinstimmt.
In unserem Beispiel schauen wir uns Unicast mit Request-Reply einmal genauer an. Nachdem die Registrierung eingegangen ist nehmen wir eine Prüfung vor, ob der Vortrag noch nicht ausgebucht ist. Auf Basis dieses Ergebnisses wird ein Confirmation Objekt erstellt, dass wir an den Aufrufer unserer REST-API zurückgeben wollen. Mit dem Aufruf der Methode request initiieren wir das Senden unseres Signals.
@POST
public Response register(Registration registration) {
var result = registrationSignal.request(registration, Confirmation.class);
return Response.ok(result).build();
}
Wie in Quarkus üblich gibt es neben des blockierenden Sendens von Signalen auch den nicht-blockierenden Weg. Dieser liefert ein Uni Objekt zurück, mit dem die Verarbeitung nach Erhalt des Ergebnisses weiterverarbeitet werden kann. Wir nutzen im Beispiel den blockierenden Weg und warten auf das Ergebnis.
Signale empfangen
Die Receiver-Methoden verhalten sich ähnlich zu den Observer-Methoden der CDI Events. Es kann ein Methodenparameter mit der Annotation @Receives versehen werden. Der Parametertyp muss natürlich vom Typ des Signal Objektes sein. Darüber hinaus kann er weitere Annotationen zur genaueren Spezifizierung nutzen. Des Weiteren können auch noch weitere Prameter dazu genutzt werden, benötigte CDI-Beans zu injizieren.
public Confirmation store(@Receives Registration registration, TalkService talkService) {
...
}
Die Methode liefert als Rückgabewert meine Configuration Klasse zurück, die ich dann 1:1 an den Aufrufer zurückgeben kann.
Das kleine Beispiel ist wie immer in unserem GitHub Bereich zu finden.
