Asynchrone Beans
Eine asynchrone Bean ist ein Java™-Objekt oder eine Enterprise-Bean, die von einer Java EE-Anwendung unter Verwendung des Java EE-Kontextes des Erstellers der asynchronen Bean asynchron ausgeführt werden kann.

Asynchrone Beans können die Leistung verbessern, indem sie ein Java EE-Programm in die Lage versetzen, Operationen in parallele Tasks zu gliedern. Asynchrone Beans unterstützen die Erstellung von aktiven Stateful-Java EE-Anwendungen. Diese Anwendungen adressieren ein Segment des Anwendungsbereichs für Anwendungen, die Anwendungsthreads, aktive Agenten in einer Serveranwendung oder Funktionen für verteilte Überwachung erfordern).
- Internationalisierungskontext
- Anwendungsprofile, die für Anwendungen der Java EE Version 1.4 nicht unterstützt werden und für Anwendungen der Java EE Version 1.3 veraltet sind
- Arbeitsbereiche
Schnittstellen für asynchrone Beans
- Work-Objekt
- Es stehen zwei Work-Schnittstellen zur Verfügung, die im Prinzip denselben Zweck erfüllen. Das traditionelle Work-Schnittstelle für asynchrone Beans ist com.ibm.websphere.asynchbeans.Work, und die CommonJ-Work-Schnittstelle ist commonj.work.Work. Ein Work-Objekt wird parallel zum Aufrufenden von der Methode startWork oder schedule des Arbeitsmanagers (startWork für traditionelle asynchrone Beans und schedule für CommonJ). Anwendungen implementieren Arbeitsobjekte, um Codeblöcke asynchron auszuführen.
- TimerListener
- Diese Schnittstelle ist ein Objekt, das die Schnittstelle "commonj\timers\TimerListener" implementiert. TimerListener werden aufgerufen, wenn ein temporärer Zeitgeber für Hochgeschwindigkeitstransaktionen abläuft.
- AlarmListener
- Ein Alarmlistener ist ein Objekt, das die Schnittstelle "com.ibm.websphere.asynchbeans.AlarmListener" implementiert. Alarmlistener werden aufgerufen, wenn ein temporärer Hochgeschwindigkeitsalarm abläuft.
- EventListener
- Ein EventListener (Ereignislistener) kann jede Schnittstelle implementieren. Bei einem Ereignislistener handelt es sich um einen asynchronen Lightweight-Benachrichtigungsmechanismus für asynchrone Ereignisse innerhalb einer JVM. Ein typischer Fall für die Verwendung eines Ereignislisteners besteht darin, Java EE-Komponenten innerhalb einer Anwendung zu aktivieren, damit diese einander über verschiedene asynchrone Ereignisse benachrichtigen.
Unterstützende Schnittstellen
- Arbeitsmanager
- Arbeitsmanager sind Thread-Pools, die Administratoren für Java EE-Anwendungen erstellen. Der Administrator gibt die Eigenschaften des Thread-Pools an sowie eine Richtlinie, die festlegt, welche Java EE-Kontexte die asynchrone Bean übernehmen wird.
- Arbeitsmanager von CommonJ
- Der Arbeitsmanager von CommonJ gleicht dem Arbeitsmanager. Der Unterschied zwischen diesen beiden Arbeitsmanagern ist der, dass der Arbeitsmanager von CommonJ eine Teilmenge der Methoden des Arbeitsmanagers für asynchrone Beans enthält. Obwohl der Arbeitsmanager von CommonJ in einer Java EE-Umgebung der Version 1.4 funktioniert, gibt eine JNDI-Lookup-Operation eines Arbeitsmanagers keine neue Instanz des WorkManager zurück. Alle JNDI-Lookup-Operationen von Arbeitsmanagern in einem Bereich haben dieselbe Instanz.
- Zeitgebermanager
- Zeitgebermanager implementieren die Schnittstelle "commonj.timers.TimerManager", mit dem Java EE-Anwendungen, einschließlich Servlets, EJB-Anwendungen und JCA-Ressourcenadapter spätere Zeitgeberbenachrichtigungen und Empfangszeitgeberbenachrichtigungen planen können. Die Spezifikation des Zeitgebermanagers für Application Server sieht eine von Application Server unterstützte Alternative für die Verwendung der J2SE-Klasse java.util.Timer vor, die sich für verwaltete Umgebungen nicht eignet.
- Ereignisquelle
- Eine Ereignisquelle implementiert die Schnittstelle "com.ibm.websphere.asynchbeans.EventSource". Bei einer Ereignisquelle handelt es sich um ein vom System bereitgestelltes Objekt, das einen generischen, typensicheren asynchronen Benachrichtigungsserver in einer JVM unterstützt. Mit Hilfe der Ereignisquelle können die Listenerobjekte, die eine beliebige Schnittstelle implementieren, registriert werden.
- EventSourceEvents
- EveryEventSource kann eigene Ereignisse, wie beispielsweise eine geänderte Listeneranzahl, generieren. Eine Anwendung kann ein EventListener-Objekt registrieren, das die Klasse com.ibm.websphere.asynchbeans.EventSourceEvents implementiert. Dadurch kann die Anwendung Ereignisse abfangen, z. B. das Hinzufügen oder Entfernen von Listener oder das Auslösen einer unerwarteten Ausnahme durch einen Listener.
Weitere Schnittstellen, einschließlich Alarmobjekten und Subsystemmonitoren, werden im Artikel "Asynchrone Bereiche entwickeln" behandelt, der einige der erweiterten Anwendungen von asynchronen Beans beschreibt.
Transaktionen
Jede Methode einer asynchronen Bean wird über ihre eigene Transaktion aufgerufen, ähnlich wie bei containergesteuerten Transaktionen in einer typischen Enterprise-Bean. Das ist vergleichbar mit einer Situation, in der eine EJB-Methode mit TX_NOT_SUPPORTED aufgerufen wird. Die Laufzeitumgebung startet einen lokalen Transaktionseinschluss, bevor sie die Methode aufruft. Die Methode der asynchronen Bean kann ihre eigene globale Transaktion starten, falls dies für die Java EE-Komponente, die den Aufruf ausführt, möglich ist. Falls beispielsweise eine Enterprise-Bean die Komponente erstellt, dann muss die asynchrone Bean mit der Methode TX_BEAN_MANAGED erstellt werden.
Wird eine Entity-Bean beispielsweise aus einer asynchronen Bean heraus aufgerufen, muss auf dem aktuellen Thread ein globaler Transaktionskontext verfügbar sein. Weil die Objekte asynchroner Beans lokale Transaktionskontexte starten, können Sie die gesamte Logik der Entity-Bean in eine Session-Bean einschließen, die über eine als TX_REQUIRES oder äquivalent gekennzeichnete Methode verfügt. Dadurch wird ein globaler Transaktionskontext aufgebaut, aus dem heraus auf eine oder mehrere Entity-Bean-Methoden zugegriffen werden kann.
Wird von der asynchronen Bean-Methode eine Ausnahme zurückgegeben, werden alle lokalen Transaktionen rückgängig gemacht. Falls die Methode normal zurückkehrt, werden unvollständige lokale Transaktionen gemäß der für die Bean konfigurierten Richtlinie für nicht aufgelöste Aktionen beendet. EJB-Methoden können diese Richtlinie mit ihrem Implementierungsdeskriptor konfigurieren. Falls die Methode mit asynchronen Beans ihre eigene globale Transaktion startet und diese globale Transaktion nicht festschreibt (Commit), dann wird die Transaktion rückgängig gemacht (Rollback), wenn die Methode zurückgegeben wird.
Zugriff auf die Metadaten einer Java EE-Komponente
Handelt es sich bei einer asynchronen Bean um eine Java EE-Komponente, z. B. um eine Session-Bean, sind beim Aufruf einer Methode deren eigene Metadaten aktiv. Handelt es sich bei der asynchronen Bean um ein einfaches Java-Objekt, dann stehen der Bean die Java EE-Komponentenmetadaten der erstellenden Komponente zur Verfügung. Wie ihr Ersteller kann auch die asynchrone Bean im Namespace java:comp suchen. Daher kann die Bean auf Verbindungsfactorys und Enterprise-Beans zugreifen, so als ob es sich um eine Java EE-Komponente handeln würde. Die Umgebungseigenschaften der erstellenden Komponente sind für die asynchrone Bean ebenfalls verfügbar.
Der Namespace java:comp ist identisch mit dem Namespace, der der erstellenden Komponente zur Verfügung steht, und es gelten dieselben Einschränkungen. Wenn die Enterprise-Bean oder das Servlet beispielsweise eine EJB-Referenz von java:comp/env/ejb/MyEJB enthält, steht diese EJB-Referenz der asynchronen Bean zur Verfügung. Außerdem verwenden alle Verbindungsfactorys denselben Bereich mit gemeinsamen Ressourcen wie die erstellende Komponente.
Verbindungsverwaltung
Die Methode mit asynchronen Beans kann die Verbindungen verwenden, die die erstellende Java EE-Komponente über die java:comp-Ressourcenreferenzen erhalten hat. (Weitere Informationen zu Ressourcenreferenzen finden Sie im Artikel "Referenzen".) Allerdings muss die Bean-Methode über das Muster "Abrufen, Verwenden und Schließen" auf diese Verbindungen zugreifen. Zwischen den Aufrufen von asynchronen Bean-Methoden werden keine Verbindungen im Cache gespeichert. Die Verbindungsfactorys und Datenquellen können zwischengespeichert werden, aber die Verbindungen müssen bei jedem Methodenaufruf abgerufen, verwendet und dann geschlossen werden. Obwohl die Methode mit asynchronen Beans Verbindungsfactorys über einen globalen JNDI-Namen suchen kann, wird dies aus folgenden Gründen nicht empfohlen:
- Der JNDI-Name ist fest in der Anwendung codiert (z. B. als Eigenschaft oder als Zeichenfolgeliteral).
- Die Verbindungsfactorys werden nicht gemeinsam benutzt, weil es nicht möglich ist, einen gemeinsamen Bereich zu definieren.
Im Artikel "Beispiel: Verbindungsverwaltung durch asynchrone Beans" finden Sie Codebeispiele, die sowohl den richtigen Zugriff auf Verbindungen von asynchronen Bean-Methoden zeigen als auch falsche Vorgehensweisen.
Verzögerter Start von asynchronen Beans
Asynchrone Beans unterstützen die verzögerte Ausführung, indem sie die Serialisierung von Java EE-Kontextinformationen zulassen. Die Methode WorkWithExecutionContext createWorkWithExecutionContext(Work r) in der Schnittstelle "WorkManager" erstellt eine Momentaufnahme der im Arbeitsmanager aktivierten Java EE-Servicekontexte. Das WorkWithExecutionContext-Ergebnisobjekt kann dann in einer Datenbank oder Datei serialisiert oder gespeichert werden. Dies ist nützlich, wenn es erforderlich ist, Java EE-Servicekontexte, z. B. die aktuelle Sicherheitsidentität oder Locale, zu speichern, entpacken und bearbeiten. Das Objekt WorkWithExecutionContext kann mit den Methoden startWork() und doWork() in der Schnittstelle "WorkManager" ausgeführt werden.Alle WorkWithExecutionContext-Objekte müssen von derselben Anwendung, von der sie serialisiert wurden, entserialisiert werden. Alle EJBs und Klassen müssen vorhanden sein, damit Java die enthaltenen Objekte entpacken kann.
Verzögerte Ausführung und Sicherheit
Der Sicherheitskontext für asynchrone Beans erfordert die CSIv2-Identitätszusicherung (Common Secure Interoperability Version 2) für die Aktivierung. Die Identitätszusicherung ist erforderlich, wenn ein WorkWithExecutionContext-Objekt entserialisiert und für die Zuordnung von JAAS-Subjekt-IDs (Java Authentication and Authorization Service) ausgeführt wird. Lesen Sie die folgenden Abschnitte, um besser zu verstehen, ob Sie die Identitätszusicherung aktivieren müssen, wenn Sie ein WorkWithExecutionContext-Objekt verwenden:- Protokolle CSIv2 und SAS konfigurieren
- Identitätszusicherung
Auch hinsichtlich der Interaktion mit WorkWithExecutionContext-Objekten anderer Produktversionen gibt es Besonderheiten zu beachten. Weitere Informationen finden Sie im Artikel "Interoperation mit asynchronen Beans".
JPA-bezogene Einschränkungen
Die Verwendung asynchroner Beans in einem erweiterten JPA-Persistenzkontext wird nicht unterstützt.
Ein erweiterter JPA-Persistenzkontext ist mit den Planungs- und Multithreading-Funktionen asynchroner Beans nicht kompatibel und über asynchrone Bean-Threads nicht zugänglich.
Eine asynchrone Bean sollte nicht mit der Klasse "javax.persistence.EntityManager" (oder einer Unterklasse) als Parameter erstellt werden, da EntityManager-Instanzen nicht threadsicher sind.