Gestionnaires de travaux

Un gestionnaire de travaux fournit des unités d'exécution pour les applications Java™ Platform, Enterprise Edition (Java EE).

A partir de la console d'administration, un administrateur peut configurer un certain nombre de gestionnaires de travaux. L'administrateur définit les propriétés du gestionnaire de travaux, y compris la règle d'héritage de contexte Java EE applicable aux tâches soumises à ce gestionnaire de travaux. Il lie chaque gestionnaire de travaux à un emplacement unique dans l'interface JNDI (Java Naming and Directory Interface). Vous pouvez utiliser les objets gestionnaires de travaux dans l'une des interfaces suivantes :
  • Programmes d'exécution gérés
    • javax.enterprise.concurrent.ManagedExecutorService
    • javax.enterprise.concurrent.ManagedScheduledExecutorService
    • java.util.concurrent.ExecutorService
    • java.util.concurrent.ScheduledExecutorService
  • Fabriques d'unités d'exécution
    • javax.enterprise.concurrent.ManagedThreadFactory
    • java.util.concurrent.ThreadFactory
  • Service de contexte d'unité d'exécution
    • javax.enterprise.concurrent.ContextService
  • Beans asynchrones
    • com.ibm.websphere.asynchbeans.WorkManager
  • Gestionnaire de travaux CommonJ
    • commonj.work.WorkManager
Le type d'interface choisi est résolu lors de la recherche JNDI basée sur la valeur que vous spécifiez dans la référence d'environnement de ressource.

Les gestionnaires de travaux fournissent un modèle de programmation pour les applications Java EE. Pour plus d'informations, voir la section Modèle de programmation.

Eviter les incidents Eviter les incidents: La classe javax.resource.spi.work.WorkManager est une interface Java que les adaptateurs de ressources JCA (Java EE Connector Architecture) doivent utiliser. Il ne s'agit pas d'une implémentation du gestionnaire de travaux (WorkManager) employé par les applications Java EE.gotcha

Lors de la conception d'un composant Web ou EJB (Enterprise JavaBeans) qui utilise Concurrency Utilities for Java EE ou des beans asynchrones, le développeur doit inclure une référence de ressource dans chaque composant devant accéder à un programme d'exécution géré, une fabrique d'unités d'exécution, un service contextuel ou un gestionnaire de travaux. Pour plus d'informations sur les références de ressources, voir la rubrique Références. Le composant interroge un programme d'exécution géré, une fabrique d'unités d'exécution, un service contextuel ou un gestionnaire de travaux qui utilise un nom logique résidant dans le composant, espace de noms java:comp, comme il le fait pour interroger une source de données, un bean enterprise ou une fabrique de connexions.

Le déployeur lie les gestionnaires de travaux physiques à des références d'environnement de ressource logiques (programmes d'exécution gérés, fabriques d'unités d'exécution, services contextuels ou gestionnaires de travaux) au moment du déploiement de l'application.

Par exemple, si un développeur requiert trois pools d'unités d'exécution afin de partitionner le travail entre les niveaux bronze, argent et or, il fera en sorte que le composant sélectionne un pool logique en fonction du profil de l'application client. Le déployeur décide de la façon dont la requête sera adressée à l'un des trois pools d'exécution. Il peut également opter pour un seul pool d'exécution si l'application s'exécute sur un système de petite taille. Dans ce cas, il liera les trois références de ressources à la même instance du gestionnaire de travaux (c'est-à-dire au même nom JNDI). Sur une système de plus grande taille, il sera possible d'utiliser trois pools d'unités d'exécution, de sorte que le déployeur liera chaque référence de ressources à un gestionnaire de travaux distinct. Les gestionnaires de travaux peuvent être partagés entre plusieurs applications Java EE résidant sur le même serveur.

Les développeurs d'applications peuvent utiliser autant de références d'environnement de ressource logiques que nécessaire. Le déployeur choisit s'il convient de mapper un ou plusieurs gestionnaires de travaux physiques à un programme d'exécution géré, une fabrique d'unités d'exécution, un service contextuel ou un gestionnaire de travaux logique défini dans l'application.

Tous les composants Java EE contraints de partager des objets de portée asynchrones doivent utiliser le même gestionnaire de travaux. Ces objets de portée possèdent une affinité avec un seul gestionnaire de travaux. Une application qui utilise des portées asynchrones doit vérifier que tous les composants utilisant des objets de portée utilisent également le même gestionnaire de travaux.

Quand plusieurs gestionnaires de travaux sont définis, le programme crée les pools d'unités d'exécution sous-jacents dans une machine virtuelle Java uniquement si une application de cette machine interroge le gestionnaire de travaux. Par exemple, dix pools d'unités d'exécution (gestionnaires de travaux) peuvent être définis, mais aucun n'est créé tant qu'ils n'ont pas été interrogés par une application.

Important : Les gestionnaires de travaux ne prennent pas en charge l'envoi de travaux à des machines virtuelles Java distantes.

Gestionnaire de travaux CommonJ

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, l'interface ne renvoie pas de nouvelle instance pour chaque recherche de nom JNDI, car cette spécification n'est pas incluse dans la spécification Java EE.

La fonction facultative de spécification des travaux CommonJ pour les travaux exécutés à distance n'est pas prise en charge. Même si elle implémente l'interface java.io.Serializable, l'unité de travail n'est pas exécutée à distance.

Mécanisme de recherche d'un programme d'exécution géré

Une application peut rechercher un programme d'exécution géré comme suit. Supposons que le composant contienne une référence d'environnement de ressource nommée concurrent/myExecutor et qui était liée à un gestionnaire de travaux physique lors du déploiement du composant :
InitialContext ic =  new InitialContext();
ManagedExecutorService executor = (ManagedExecutorService) ic.lookup("java:comp/env/concurrent/myExecutor");

Contextes d'héritage Java EE

Les tâches soumises aux programmes d'exécution gérés et aux gestionnaires de travaux peuvent hériter des contextes Java EE suivants de l'unité d'exécution de soumission : Un proxy contextuel peut hériter de ces types de contexte à partir de l'unité d'exécution qui appelle le service contextuel pour créer le proxy contextuel. Une fabrique d'unités d'exécution gérée peut hériter de ces types de contexte à partir de l'unité d'exécution qui recherche ou injecte la fabrique d'unités d'exécution gérée.
Un contexte d'internationalisation
Lorsque cette option est sélectionnée, que le service d'internationalisation est activé et que le contexte d'internationalisation présent dans l'unité d'exécution de planification est disponible dans l'unité d'exécution cible.
Espace de travail
Lorsque cette option est sélectionnée, le contexte de zone de travail correspondant à chaque partition de zone de travail figurant dans l'unité d'exécution de planification est disponible sur l'unité d'exécution cible.
Profil d'application (déconseillé)
Le contexte du profil d'application n'est pas pris en charge et n'est pas disponible pour la plupart des applications. Dans les applications Java EE 1.3, lorsque cette option est sélectionnée, le service de profil d'application est activé et la propriété correspondante, Mode de compatibilité 5.x, est sélectionnée. La tâche de profil d'application associée à l'unité d'exécution de planification est disponible sur l'unité d'exécution cible pour les applications Java EE 1.3. Pour les applications Java EE 1.4 ou de niveau ultérieur, la tâche de profil d'application n'est pas une unité d'exécution mais une propriété de l'unité de travail associée. Cette option n'influence pas le comportement de la tâche dans les applications Java EE 1.4 ou de niveau ultérieur. Le travail planifié exécuté dans une application Java EE 1.4 ne reçoit pas la tâche de profilage de l'unité d'exécution de planification.
Sécurité
La tâche peut s'exécuter de façon anonyme ou sous le nom du client authentifié auprès de l'unité d'exécution qui l'a créée et soumise. Ce comportement est pratique car la tâche peut obéir totalement aux ordres de l'appelant. En cela, cette fonctionnalité est plus performante que le mécanisme RUN_AS, par exemple, qui ne permet pas un tel comportement. Lorsque vous sélectionnez l'option Sécurité, l'objet JAAS qui figure dans l'unité d'exécution de planification est disponible dans l'unité d'exécution cible. Si cette option n'est pas sélectionnée, l'unité d'exécution fonctionne de manière anonyme.
Métadonnées du composant
Les métadonnées du composant n'ont lieu d'être que lorsque la tâche est un objet Java simple. Si la tâche est un composant Java EE, tel qu'un bean enterprise, les métadonnées du composant sont actives.

Les contextes qui peuvent être hérités dépendent du gestionnaire de travaux, qui est utilisé par l'application qui crée et soumet la tâche. A partir de la console d'administration, l'administrateur définit la règle d'héritage de contexte d'un gestionnaire de travaux, en sélectionnant les services pour lesquels le gestionnaire sera disponible.

Modèle de programmation

Les gestionnaires de travaux prennent en charge les modèles de programmation suivants :
  • Concurrency Utilities for Java EE. La spécification Java EE normalise ce modèle de programmation, qui inclut des programmes d'exécution gérés, des programmes d'exécution planifiés gérés et des fabriques d'unités d'exécution gérées qui héritent de l'API Java SE java.util.concurrent bien connue. Elle inclut également le service contextuel, sans équivalent dans l'API java.util.concurrent.
  • Beans asynchrones. Les interfaces actuelles Work Manager, EventSource de beans asynchrones, de portées asynchrones, de moniteurs de sous-systèmes et de contexte Java EE appartiennent au modèle de programmation beans asynchrones.
  • Spécification CommonJ. Le modèle de programmation CommonJ utilise les objets WorkManager et TimerManager pour gérer les unités d'exécution et les compteurs en mode asynchrone dans l'environnement Java EE.

Pour plus d'informations sur les API des programmes d'exécution gérés, des fabriques d'unités d'exécution, du service contextuel et du gestionnaire de travaux, voir la documentation Javadoc.

Exemples d'accès concurrents

Tableau 1. Recherche d'un programme d'exécution géré ou d'un gestionnaire de travaux
Programme d'exécution géré Beans asynchrones CommonJ
InitialContext ctx = new InitialContext();
ManagedExecutorService executor =
(ManagedExecutorService)
   ctx.lookup("java:comp/env/wm/myWorkMgr");
InitialContext ctx = new InitialContext();
com.ibm.websphere.asynchbeans.WorkManager wm  =
(com.ibm.websphere.asynchbeans.WorkManager)
   ctx.lookup(“java:comp/env/wm/MyWorkMgr”);
InitialContext ctx = new InitialContext();
commonj.work.WorkManager wm =
 (commonj.work.WorkManager)
   ctx.lookup(“java:comp/env/wm/MyWorkMgr”);
Tableau 2. Création de votre tâche
Programme d'exécution géré Beans asynchrones CommonJ
 public class MyWork implements Callable<Integer> {
     public Integer call() {
       System.out.println(“Running.....”);
       return 1;
     }
   }
La classe publique MyWork implémente   
com.ibm.websphere.asynchbeans.Work {
   public void release() {
            ......
   }
   public void run() {
    System.out.println(“Running.....”);
}
La classe publique MyWork implémente 
commonj.work.Work{
   public boolean isDaemon() {
       return false;
   }
   public void release () {
        .....
   }
    public void run () {
     System.out.println(“Running.....”);
  }
Tableau 3. Soumission de la tâche
Programme d'exécution géré Beans asynchrones CommonJ
MyWork work1 = new MyWork();
MyWork work2 = new MyWork();

// cas 1 : blocage jusqu'à réalisation de toutes les tâches
Collection<MyWork> tasks =
    Arrays.asList(work1, work2);
List<Future<Integer>> futures =
    executor.invokeAll(tasks);
for (Future<Integer> future : futures)
    System.out.println("work data=" + future.get());

//cas 2 : attendez 1000 millisecondes, que toutes les tâches aient été effectuées.
Integer result = executor.invokeAny(
    tasks, 1, TimeUnit.SECONDS);
System.out.println("work data=" + result);
MyWork work1 = new MyWork();
MyWork work2 = new MyWork();

WorkItem item1;
WorkItem item2;
Item1=wm.startWork(work1);
Item2=wm.startWork(work2);
	
// cas 1 : blocage jusqu'à réalisation de toutes les tâches
ArrayList col1 = new ArrayList();
Col1.add(item1);
Col1.add(item2);
wm.join(col1, WorkManager.JOIN_AND, WorkManager.INDEFINITE);
// une fois les travaux terminés
System.out.println(“work1 data=”+work1.getData());
System.out.println(“work2 data=”+work2.getData());
	
// terminez le cas 1 avant le cas 2
//cas 2 : attendez 1000 millisecondes, que toutes les tâches aient été effectuées.
Boolean ret = wm.join(col1,                           WorkManager.JOIN_OR, 1000);
MyWork work1 = new MyWork();
MyWork work2 = new MyWork();
	
WorkItem item1;
WorkItem item2;
Item1=wm.schedule(work1 );
Item2=wm.schedule(work2);
	
// cas 1 : blocage jusqu'à réalisation de toutes les tâches
Collection col1 = new ArrayList();
col1.add(item1);
col1.add(item2);
wm.waitForAll(col1, WorkManager.INDEFINITE);
// une fois les travaux terminés
System.out.println(“work1 data=”+work1.getData());
System.out.println(“work2 data=”+work2.getData());
	
// terminez le cas 1 avant le cas 2
//cas 2 : attendez 1000 millisecondes, que toutes les tâches aient été effectuées.
Collection finished = wm.waitForAny(col1,1000);
// vérifiez l'état des tâches
if (finished != null) {
Iterator I = finished.iterator();
	  if (i.hasNext()) {
	     WorkItem wi = (WorkItem) i.next();
	      if (wi.equals(item1)) {
	        System.out.println(“work1 = 
 					“+ work1.getData());
	      } else if (wi.equals(item2)) {
	        System.out.println(“work1 =
					 “+ work1.getData());
	      }
	  }
}
Tableau 4. Création d'un programme d'exécution planifié géré, d'un gestionnaire d'alarme ou d'un gestionnaire de minuteur
Programme d'exécution planifié géré Beans asynchrones CommonJ
InitialContext ctx = new InitialContext();
ManagedScheduledExecutorService executor =
  (ManagedScheduledExecutorService)
    ctx.lookup("java:comp/env/wm/MyWorkMgr");
InitialContext ctx = new InitialContext();
com.ibm.websphere.asynchbeans.WorkManager wm  =
    (com.ibm.websphere.asynchbeans.WorkManager)
      ctx.lookup(“java:comp/env/wm/MyWorkMgr”);
	
AsynchScope ascope;
Try {
  Ascope = wm.createAsynchScope(“ABScope”);
} Catch (DuplicateKeyException ex)
{
   Ascope = wm.findAsynchScope(“ABScope”);
   ex.printStackTrace();
}

// Extraire un objet AlarmManager 
AlarmManager  aMgr= ascope.getAlarmManager();
InitialContext ctx = new InitialContext();
Commonj.timers.TimerManager tm = (commonj.timers.TimerManager) ctx.lookup(“java:comp/env/tm/MyTimerManager”);
Tableau 5. Planification d'une tâche, d'une alarme ou d'un minuteur
Programme d'exécution planifié géré Beans asynchrones CommonJ
// créez une tâche
Runnable task = new StockQuoteTask(
    “qqq”, “johndoe@example.com”);
ScheduledFuture<?> future =
     executor.schedule(task, 1, TimeUnit.MINUTES);

// Délai fixe : programmez l'exécution de la tâche
// dans 1 minute à partir de maintenant et répétez cette opération
// toutes les heures.
ScheduledFuture<?> future =
    executor.scheduleWithFixedDelay(
        task, 1, 60, TimeUnit.MINUTES);

// Délai fixe : Programmez l'expiration du minuteur
// dans 1 minute à partir de maintenant et répétez cette opération
// toutes les heures.
ScheduledFuture<?> future =
    executor.scheduleAtFixedRate(
        task, 1, 60, TimeUnit.MINUTES);
// créer une alarme
ABAlarmListener listener = new ABAlarmListener();
Alarm am = aMgr.create(listener, “SomeContext”, 1000*60);
// créez un minuteur
TimerListener listener =
 new StockQuoteTimerListener(“qqq”,
 “johndoe@example.com”);
Timer timer = tm.schedule(listener, 1000*60);
	
// délai-fixe : programmez l'expiration du compteur à
// 60 secondes à partir de maintenant et répétez cette opération
// toutes les heures.  
Timer timer = tm.schedule(listener, 1000*60, 1000*30);
	
// fréquence fixe : programmez l'expiration du compteur à
// 60 secondes à partir de maintenant et répétez cette opération
// toutes les heures.
Timer timer = tm.scheduleAtFixedRate(listener, 1000*60, 1000*30);

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=casb_workmgr
Nom du fichier : casb_workmgr.html