Asynchrone Methoden in EJB 3.1
Die Spezifikation Enterprise JavaBeans™ (EJB) 3.1 enthält Funktionen, die Anwendungsentwickler verwenden können, um asynchrone EJB-Methoden zu entwickeln, die in einem anderen Thread als dem aufrufenden Thread ausgeführt werden.
Dieser Mechanismus entkoppelt die Clientaufrufanforderung von der eigentlichen Methodenausführung. Der Client-Thread kann mit der Ausführung anderer Arbeiten fortfahren, während die EJB-Methode in einem separaten Thread gemäß Anweisung durch den EJB-Container ausgeführt wird.
Später kann der Client das Ergebnis der asynchronen Methodenausführung prufen. Dieses Verhalten wird auch als fire and return bezeichnet. In diesem Fall gibt der EJB-Container ein Objekt an den Client zurück, das die Schnittstelle "java.util.concurrent.Future<V>" implementiert. Der Client kann dieses Objekt verwenden, um den Status, die Ergebnisse oder die Ausnahmen des asynchronen Methodenaufrufs zu prüfen. Alternativ geben asynchrone Methoden möglicherweise keine Ergebnisse zurück. Dieses Verhalten wird auch als fire and forget bezeichnet.
Weitere Einzelheiten finden Sie im Artikel zur Verwendung asynchroner EJB-Methoden in Ihrer Anwendung.
Im Folgenden finden Sie einige Beispieleinsatzszenarien für asynchrone EJB-Methoden:
- Eine Anwendung hat mehrere, unabhängige Arbeitseinheiten, die alle in einer bestimmten Reihenfolge ausgeführt werden müssen,
um das Endergebnis zu erzeugen.
Angenommen, eine Reisereservierung setzt sich aus drei Teilen zusammen:
- Flugreservierung,
- Mietwagenreservierung,
- Hotelreservierung.
- Eine Anwendung hat mehrere, unabhängige Arbeitseinheiten, die sie ausführen muss, und die Ergebnisse dieser Arbeit sind für die Anwendung
nicht von Belang. Angenommen, ein Einzelhändler hat vier Filialen, und die Hauptfiliale möchte
am Ende des Geschäftstags einen Umsatzbericht für jede Filiale drucken.
Der Anwendungsentwickler kann asynchrone EJB-Methoden als Stapelverarbeitungsmechanismus verwenden.
Es können mehrere EJB-Methodenaufrufe verwendet werden, um einen Stapel von
Anforderungen zum Abrufen von Umsatzberichten zu senden, eine Anforderung an jede Filiale.
In diesem Beispiel muss die Anwendung die Ergebnisse dieser Methodenaufrufe vermutlich nicht prüfen. Vielleicht werden die Ergebnisse von einem Mitarbeiter der Hauptfiliale geprüft, der die Umsatzberichte am nächsten Morgen am Drucker abholt. Angenommen, eine der Filialen konnte den angeforderten Bericht nicht liefern. Die Person, die die Berichte einsammelt, kann entscheiden, ob dies zu erwarten war, z. B., weil die Filiale für Renovierungsarbeiten geschlossen wurde, oder ob die Anforderung zum Abrufen des Umsatzberichts erneut an diese Filiale gesendet werden muss.