Tutoriel pour la mise en place de traitements concurrentiels en JEE

Foo-CommonJ est une implémentation Open Source de la JSR 237 : Work Manager for Application Server. Le but de cette implémentation est de permettre aux serveurs d'applications Open Source (Tomcat, JBoss, WASCE…) de faire du Work Manager avec aussi une capacité de Timer (exécution à des périodes de temps spécifiées). Tomcat n'est pas un serveur JEE, mais comme l'API Foo-CommonJ ne dépend d'aucune capacité JEE, elle peut être mise en place sur le serveur de Conteneur JSP/Servlet.

Pour notre exemple de mise en place, nous allons utiliser la version de l'API Foo-CommonJ compatible Java 1.5 et supérieure, ce qui nous oblige à utiliser une version de Tomcat niveau 6 minimum.

La mise en pratique du mécanisme de Work Manager dans un Serveur Open Source compatible Java 1.5 se fait en trois étapes :

1. Déclaration d'une ressource JNDI pour le work WorkManager
   Dans mon cas, j'ai utilisé le serveur Tomcat, la déclaration du contexte JNDI se fait dans le fichier context.xml, il faut rajouter les lignes suivantes :

    

   Sélectionnez

   <Resource name="wm/CompteurWM"
   auth="Container"
   type="commonj.work.WorkManager"
   factory="de.myfoo.commonj.work.FooWorkManagerFactory"
   maxThreads="5" />

2. Déclaration de la ressource référencée dans web.xml (resource-ref) : pour les applications utilisant une version inférieure à l'API Servlet 3.0
   Dans le fichier de description web.xml, il faut rajouter la référence à la ressource configurée dans le contexte Tomcat.

    

   Sélectionnez

   <resource-ref>
       <res-ref-name>wm/CompteurWM</res-ref-name>
       <res-type>commonj.work.WorkManager</res-type>
       <res-auth>Container</res-auth>
       <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>

3. Initialisation du WorkManager

L'initialisation du workmanager se fait par recherche dans le contexte JNDI, en faisant un lookup sur le nom JNDI déclaré dans le contexte du serveur Tomcat pour les versions inférieures à la Servlet 3.0 (sinon une injection du type @Resource (name=« wm/CompteurWM » permet d'initialiser la ressource).

InitialContext ctx = new InitialContext();
WorkManager wkMgr = (WorkManager) ctx.lookup("java:comp/env/wm/CompteurWM");

Diagramme de classes : qui représente une conception des classes de notre cas d'étude selon l'approche J2ee. Les impacts sont les suivants :

• IServiceTraitementWeb : interface qui réalise le traitement métier. Elle étend l'interface commonj.work.Work . Elle remplace l'interface (du cas Java SE) : IServiceTraitement ;
• ServiceTraimentWeb : cette classe implémente l'interface IServiceTraitementWeb. Agrège la couche Business (IBusinessTraiement) et implémente la méthode run() contenant le code à paralléliser et synchroniser (si besoin selon les exigences métiers). Deux méthodes doivent être implémentées isDeamon() et release() ;
• ManagerServiceTraimentWeb : classe qui utilise l'interface IServiceTraitementWeb et instancie le commonj.work.WorkManager, cette dernière a la responsabilité de lancer les traitements des Work(s) dans la méthode startTraiement() : méthode d'entrée d'exécution de ce cas d'exemple ;
• ContextListenerWorkManager : classe JEE qui implémente l'interface javax.servlet.ServletContextListener. Elle utilise la classe ManagerServiceTraitementWeb, pour lancer le traitement au déploiement de l'application ;
• ServletWorkManager : classe JEE qui implémente la classe abstraite javax.servlet.HttpServlet. Elle utilise la classe ManagerServiceTraitementWeb, pour lancer le traitement à travers la requête HTTP :

[host :port/wkm-web-simple/workManager]

Le 20 avril 2009, Oracle Corporation rachète Sun Microsystems propriétaire de Java et devient à cette occasion propriétaire de Java et du serveur JEE Open Source GlassFish.

Nous allons utiliser la version 3.1 du serveur OGS, pour mettre en œuvre notre cas d'étude, faire du Concurrency et de l'asynchrone sur une application JEE 6. Le serveur OGS 3.1 est certifié JEE 6.

La mise en place sur le serveur OGS 3.1 se fait en trois étapes :

• Déclaration d'une ressource JNDI pour le WorkManager : dans mon cas, j'ai utilisé l'interface IHM (Common Task/Domain/JNDI/Custom resources/).
• Déclaration de la ressource référencée dans web.xml (resource-ref) : idem à Tomcat (obligatoire seulement pour les applications avec une version JEE inférieure à 6).
• Initialisation du WorkManager : idem à Tomcat (par injection pour les applications JEE 6 et supérieure).

Diagramme de classe : qui représente une conception des classes de notre cas d'étude selon l'approche J2EE 6. Les impacts sont les suivants.

Nous n'allons énumérer que les mises à jour du diagramme de classe en partant de celui du chapitre (2.2 avec Tomcat), modifications générées par le passage en structure EAR du projet.

• ServiceMgrTraiment: interface qui représente EJB local qui expose le service ;
• ServiceMgrTraimentBean : classe EJB Stateless qui implémente l'interface IServiceMgrTraiment et qui utilise l'interface IServiceTraitementWeb pour réaliser le traitement. Ce bean remplace la classe ManagerServiceTraimentWeb ;
• ContextListenerWorkManager : utilise l'EJB local (IServiceMgrTraiment) pour initier les traitements ;
• ServletWorkManager : utilise l'EJB local (IServiceMgrTraiment) pour initier les traitements.

IBM et BEA sont les auteurs de la JSR 237, IBM utilise une implémentation plus spécifique à Websphère (version RAD 7).

La mise en pratique du mécanisme de WorkManager dans RAD se fait en trois étapes.

• La déclaration de la ressource WorkManager sur nœud serveur actif (Ressources > Beans asynchrones > Gestionnaire des travaux).
• La déclaration de la ressource référencée dans web.xml (resource-ref) : idem à Tomcat.
• L'initialisation du WorkManager : idem à Tomcat (pour les applications JEE 6 initialisation par injection de la ressource par son nom JNDI).

Il faut noter que cette implémentation est bien gérée au niveau du serveur RAD (version Java EE 6 et inférieure). La documentation de l'éditeur est plus adéquate pour implémenter cette solution non standard JEE (avant la version 7).

IV-A-3-a. LE CAS JEE 7▲

Nous allons utiliser la version 4.0 du serveur OGS, pour mettre en œuvre notre cas d'étude, faire du Concurrency et l'asynchrone sur une application JEE 7. Le serveur OGS 4.0 est certifié Jee 7.

La mise en place sur le serveur OGS 4.0, se fait en deux étapes :

1. Déclaration d'une Ressource Concurrency JNDI, dans notre cas d'exemple nous allons choisir la ressource de type ManagedSexecutorServices

Dans mon cas j'ai utilisé l'interface IHM

(Common Task/Resources/Concurrent Ressources/Managed Executor Services), puis renseigné les valeurs suivantes :

JNDI name : xxxxx
Thread Priority: 10 (valeur conseillée)
Core Size: 2 (valeur conseillée)
Maximum Pool Size: 5 (valeur conseillée)
Task Queue Capacity: 2 (valeur conseillée)

1. Initialisation du ManagedExecutorService dans le code applicatif par injection :

-@Resource(name=ConstantesWeb.JNDI_NAME_WKM)ManagedExecutorService managedExecutorService;

—Diagramme de classes : qui représente une conception des classes de notre cas d'étude selon l'approche J2EE 7. Les impacts sont les suivants. Nous n'allons énumérer que les mises à jour du diagramme de classes en partant de celui du chapitre (2.3 OGS 3.1), modification générée par le passage de JEE 6 à JEE 7.

• IServiceMgrTraitement: interface qui représente EJB local qui expose le service.
• ServiceMgrTraitementBean : classe EJB Stateless qui implémente l'interface IServiceMgrTraitement et qui utilise l'interface IServiceTraitement pour réaliser le traitement. Ce bean utilise l'interface ManagedExcecutorService pour exécuter les traitements thread.