Beans asynchrones
Un bean asynchrone est un objet Java ou un bean enterprise exécutable en mode asynchrone par une application Java Platform, Enterprise Edition (Java EE), à l'aide du contexte Java EE de son créateur.

Les beans asynchrones améliorent les performances en permettant à un programme Java EE de décomposer ses opérations en tâches parallèles. Ils prennent en charge la construction d'applications Java EE actives avec état. Ces applications pointent vers un segment de l'espace d'applications qui nécessitent un traitement par unités d'exécution, les agents actifs à l'intérieur d'une application serveur ou les fonctions de contrôle distribuées.
- Un contexte d'internationalisation
- Profils d'applications non pris en charge pour les applications Java EE 1.4 et obsolètes pour les applications Java EE 1.3
- Zones de travail
Interfaces des beans asynchrones
- Objet de travail
- Deux interfaces de travail ont essentiellement le même but. L'interface de travail des beans asynchrones existante est com.ibm.websphere.asynchbeans.Work et l'interface de travail CommonJ est commonj.work.Work. Un objet de travail s'exécute en parallèle par rapport à son appelant en utilisant la méthode startWork ou schedule du gestionnaire de travaux (startWork pour les beans asynchrones existant et schedule pour CommonJ). Les applications implémentent des objets de travail pour exécuter des blocs de code de manière asynchrone.
- Programme d'écoute de compteurs
- Cette interface est un objet qui implémente l'interface commonj\timers\TimerListener. Les programmes d'écoute de compteurs sont appelés quand un compteur transitoire à haute vitesse expire.
- Programme d'écoute des alarmes
- Un programme d'écoute des alarmes est un objet qui implémente l'interface com.ibm.websphere.asynchbeans.AlarmListener. Les programmes d'écoute des alarmes sont appelés lorsqu'une alarme transitoire à haute vitesse expire.
- Programme d'écoute des événements
- Un programme d'écoute des événements peut implémenter n'importe quelle interface. Il s'agit d'un mécanisme de notification asynchrone léger utilisable par des événements asynchrones à l'intérieur d'une même machine virtuelle Java. En général, les programmes d'écoute d'événement permettent aux composants Java EE d'une application unique de s'informer mutuellement sur divers événements asynchrones.
Interfaces de prise en charge
- le gestionnaire de travaux
- Les gestionnaires de travaux sont des pools d'unités d'exécution créés par les administrateurs pour les applications Java EE. L'administrateur spécifie les propriétés du pool d'unités d'exécution ainsi qu'une règle qui détermine les contextes Java EE dont hérite le bean asynchrone.
- Gestionnaire de travaux CommonJ
- Le gestionnaire de travaux CommonJ est semblable au gestionnaire de travaux. La seule différence qui les distingue est que le gestionnaire de travaux CommonJ contient un sous-ensemble des méthodes du gestionnaire de travaux des beans asynchrones. Bien que le gestionnaire de travaux CommonJ fonctionne dans un environnement Java EE 1.4, chaque recherche JNDI d'un gestionnaire de travaux ne renvoie pas de nouvelle instance de l'objet WorkManager. Toutes les recherches JNDI de gestionnaires de travaux dans une portée renvoient la même instance.
- Gestionnaire de compteurs
- Les gestionnaires de compteurs implémentent l'interface commonj.timers.TimerManager, qui active les applications Java EE, notamment les servlets, les applications EJB et les adaptateurs de ressources JCA, pour planifier les notifications de compteur ultérieures et recevoir des notifications de compteur. Le gestionnaire de compteurs correspondant à la spécification des serveurs d'applications sert d'alternative, acceptée par les serveurs d'applications, à l'utilisation de la classe J2SE java.util.Timer, qui ne convient pas aux environnements gérés.
- Source d'événements
- Une source d'événements implémente l'interface com.ibm.websphere.asynchbeans.EventSource. Il s'agit d'un objet système prenant en charge un serveur de notification asynchrone générique sécurisé à l'intérieur d'une simple machine virtuelle Java. La source d'événements autorise l'enregistrement des objets du module d'écoute qui permettent d'implémenter n'importe quelle interface.
- Evénements d'une source d'événements
- Chaque source d'événements peut générer ses propres événements, tels que la modification du nombre de modules d'écoute. Une application peut enregistrer un objet module d'écoute d'événements implémentant la classe com.ibm.websphere.asynchbeans.EventSourceEvents. Cette action lui permet d'intercepter des événements, tels que l'ajout ou le déplacement de modules d'écoute ou la génération d'une exception inattendue par un module d'écoute.
La rubrique Développement de portées asynchrones, qui traite de certaines applications avancées des beans asynchrones, présente des interfaces supplémentaires, telles que les alarmes et les moniteurs de sous-système.
Transactions
Chaque méthode de bean asynchrone est appelée à l'aide de sa propre transaction, comme c'est le cas pour les beans enterprise avec des transactions gérées par conteneur. Ce cas est comparable à la situation où une méthode EJB (Enterprise JavaBeans) est appelée avec TX_NOT_SUPPORTED. L'environnement d'exécution lance un confinement de transaction locale avant d'appeler la méthode. La méthode de bean asynchrone est libre de lancer sa propre transaction globale si celle-ci est possible pour le composant Java EE appelant. Par exemple, si un bean enterprise crée le composant, la méthode créant le bean asynchrone doit être TX_BEAN_MANAGED.
Lorsque vous appelez un bean entity à partir d'un bean asynchrone par exemple, un contexte transactionnel global doit être disponible dans l'unité d'exécution en cours. Etant donné que les objets de bean asynchrones lancent des contextes transactionnels locaux, vous devez encapsuler la logique de bean entity dans un bean session comportant une méthode marquée comme TX_REQUIRES ou équivalent. Ce processus établit un contexte transactionnel global à partir duquel vous pouvez accéder à une ou plusieurs méthodes de bean entity.
Si la méthode de bean asynchrone génère une exception, toutes les transactions locales sont annulées. Si la méthode se termine normalement, toutes les transactions locales en cours se terminent suivant la règle d'action non résolue configurée pour le bean. Les méthodes EJB peuvent configurer cette stratégie à l'aide de leur descripteur de déploiement. Si la méthode de bean asynchrone lance sa propre transaction globale sans parvenir à la valider, celle-ci est annulée quand la méthode rend la main.
Accès aux métadonnées des composants Java EE
Si le bean asynchrone est un composant Java EE, tel qu'un bean session, ses métadonnées sont actives lors de l'appel d'une méthode. Si le bean asynchrone est un simple objet Java, les métadonnées du composant Java EE du composant créateur sont disponibles pour le bean. Comme son créateur, le bean asynchrone peut interroger l'espace de nom java:comp. Comme n'importe quel autre composant Java EE, le bean a ainsi la possibilité d'accéder à des fabriques de connexion et à des beans enterprise. Les propriétés d'environnement du composant créateur sont également accessibles par le bean asynchrone.
L'espace de nom java:comp est identique à celui disponible pour le composant créateur et les mêmes restrictions s'appliquent. Par exemple, si un servlet ou un bean enterprise possède une référence EJB de java:comp/env/ejb/MyEJB, celle-ci est disponible pour le bean asynchrone. Par ailleurs, toutes les fabriques de connexions utilisent la même portée de partage de ressources que le composant créateur.
Gestion des connexions
Une méthode de bean asynchrone peut utiliser les connexions obtenues par le composant Java EE créateur à l'aide de références de ressources java:comp. (Pour plus d'informations sur les références de ressources, reportez-vous à la rubrique Références). Cependant, la méthode de bean doit accéder à ces connexions à l'aide d'un modèle get-use-close (extraction-utilisation-fermeture). Il n'existe pas de mise en cache des connexions entre les appels de méthode sur un bean asynchrone. Les fabriques de connexions ou les sources de données elles-même peuvent être placées en cache, mais les connexions doivent être récupérées à chaque appel de méthode, puis utilisées et fermées. Bien que la méthode de beans asynchrone puisse rechercher des fabriques de connexion à l'aide d'un nom JNDI (Java Naming and Directory Interface) global, ceci n'est pas recommandé pour les raisons suivantes :
- Le nom JNDI figure "en dur" dans l'application (sous la forme d'une propriété ou d'un littéral, par exemple).
- Les fabriques de connexions ne sont pas partagées car il n'existe aucun moyen de spécifier une portée de partage.
La rubrique Exemple : gestion de connexions de bean asynchrone décrit les mécanismes à utiliser et les mécanismes à proscrire pour établir des connexions d'accès à partir de méthodes de bean asynchrone.
Lancement différé des beans asynchrones
Les beans asynchrones prennent en charge le lancement différé en autorisant la sérialisation des informations du contexte de service Java EE. La méthode WorkWithExecutionContext createWorkWithExecutionContext(Work r) de l'interface WorkManager crée un instantané des contextes de service Java EE activés sur WorkManager. L'objet WorkWithExecutionContext obtenu peut ensuite être sérialisé et stocké dans une base de données ou un fichier. Cette procédure est utile lorsqu'il est nécessaire de stocker des contextes de service Java EE, tels que l'identité de sécurité en cours ou la variable locale, puis de les décompresser et d'exécuter des tâches au sein de ce contexte. L'objet WorkWithExecutionContext peut être exécuté à l'aide des méthodes startWork() et doWork() de l'interface WorkManager.Tous les objets WorkWithExecutionContext doivent être désérialisés par l'application qui a effectué la sérialisation. Tous les EJB et les classes doivent être présents pour décompresser les objets qu'ils contiennent.
Lancement différé et sécurité
Le contexte du service de sécurité des beans asynchrones peut requérir l'activation de la fonction Vérification d'identité CSIV2 (Common Secure Interoperability Version 2). La déclaration d'identité est requise lorsque l'objet WorkWithExecutionContext est désérialisé et exécuté par rapport à l'affectation du justificatif d'identité de l'objet JAAS. Pour déterminer si vous devez activer la déclaration d'identité lors de l'utilisation de l'objet WorkWithExecutionContext, consultez les rubriques ci-après :- Configuration du protocole d'authentification CSIV2 (Common Secure Interoperability version 2) et SAS (Security Authentication Service)
- Vérification d'identité
Des problèmes peuvent apparaître si vous utilisez des objets WorkWithExecutionContext provenant de différentes versions du produit. Reportez-vous à la rubrique Interopérabilité avec des beans asynchrones.
Limitations associées à JPA
L'utilisation de beans asynchrones dans un contexte de persistance étendu JPA n'est pas prise en charge.
Les contextes de persistance JPA étendus ne sont pas cohérents par rapport aux fonctions de planification et de traitement multitâche des beans asynchrones. Ils sont en outre inaccessibles à partir des unités d'exécution de beans asynchrones.
De même, un bean asynchrone ne doit pas être créé s'il doit prendre un paramètre javax.persistence.EntityManager (ou une sous-classe) car les instances EntityManager ne sont pas destinées à autoriser les unités d'exécution multiples.