import javax.ejb.Stateless;

@Stateless
public class Conversion {
   private final double TAUX = 6.55957;

   public double euroFranc(double euro) {
       return euro*TAUX;
   }

   public double francEuro(double franc) {
       return franc/TAUX;
   }
}  

Dans l'exemple ci-dessus est créé un EJB Conversion qui réalise la conversion entre les €uros et les Francs. Vous remarquez la mise en oeuvre d'une classe des plus basiques avec une simple annotation @Stateless. Ce composant doit être déployé dans le serveur d'application pour que le conteneur d'EJB le prenne en compte. A partir de là, ce composant reste côté serveur et peut rendre les services requis. Côté client il suffit de faire appel à distance aux méthodes euroFranc() et francEuro() qui délivrerons les calculs désirés.

Un conteneur EJB est un environnement d'exécution qui fournit des services comme la gestion des transactions, le contrôle de la concurrence, la gestion des pools et la sécurité, mais les serveurs d'applications lui ont ajouté d'autres fonctionnalités, comme la mise en cluster, la répartition de la charge et la reprise en cas de panne. Les développeurs d'EJB peuvent désormais se concentrer sur l'implémentation de la logique métier et laisser au conteneur le soin de s'occuper des détails techniques.

java:global[/<nom-application>]/<nom-module>/<nom-bean>!<nom-interface>

1. <nom-application> : est facultatif car cette partie ne s'applique que si le bean session fait partie d'une application d'entreprise. C'est le nom de l'application dans lequel le bean est packagé. Le type de fichier d'une application d'entreprise qui doit être déployé dans le serveur d'application porte l'extension "ear". En ce cas, <nom-application> est, par défaut, le nom du fichier "ear" sans son extension.
2. <nom-module> : est le nom du module dans lequel a été assemblé le bean session (nom du module dans lequel l'EJB est packagé). Ce module peut être un module EJB dans un fichier "jar" autonome ou un module web dans un fichier "war". Par défaut, <nom-module> est le nom du fichier archive, sans son extension.
3. <nom-bean> : est le nom du bean session. Par défaut, c'est le nom de la classe d'implémentation de l'EJB sauf si le nom est précisé via l'attribut name de l'annotation @Stateless, @Stateful et @Singleton.
4. <nom-inteface> : est le nom pleinement qualifié de l'interface métier sous laquelle l'EJB est exposé. Dans le cas des vues sans interface, ce nom est le nom pleinement qualifié de la classe du bean.

// Côté serveur
@Stateless
@LocalBean
public class ConversionBean implements ConversionRemote, ConversionLocal  {
...
}
// nom JNDI associé
java:global/ProjetConversion/ConversionsEJB/ConversionBean!ConversionBean
java:global/ProjetConversion/ConversionsEJB/ConversionBean!ConversionRemote
java:global/ProjetConversion/ConversionsEJB/ConversionBean!ConversionLocal

Le nom de l'interface n'est utile que si l'EJB implémente plusieurs interfaces (Local et Remote) : Nous pouvons parfaitement nous en passer si l'EJB n'implémente qu'une seule interface (ou n'a qu'une vue sans interface). Dans ce cas, le conteneur doit aussi proposer un nom JNDI court, associé à ce même EJB :

java:global[/<nom-application>]/<nom-module>/<nom-bean>

En imaginant la construction d'un projet de conversion, avec seulement une interface distante, sous la forme d'un simple module, sans la mise en oeuvre d'une application d'entreprise, voici par exemple ce que nous pouvons écrire :

// Côté serveur
@Stateless
public class Conversion implements  ConversionRemote  {
...
}
// nom JNDI associé
java:global/ConversionsEJB/Conversion

Regardons maintenant comment le client peut accéder au service proposé par le bean session. La première chose à faire, nous l'avons souligné en préambule, est de récupérer une instance de l'EJB au moyen de JNDI :

1. Pour cela vous devez mettre en oeuvre un contexte pour l'application cliente qui va permettre de faire la recherche du nom JNDI stocké dans l'annuaire. Il faut d'abord initialiser ce contexte avec tous les bons paramètres requis. Il est alors nécessaire de faire appel à la classe InitialContext dont le but est de récupérer les informations relatives au serveur d'applications (notamment la localisation du serveur dans le réseau local de l'entreprise, le type de protocole utilisé, le numéro de service en cours préconisé par le conteneur d'EJB, etc.).

   Dans le cas du serveur GlassFish, ces différentes informations sont précisées dans un certain nombre de fichiers d'archive contenus dans le sous répertoire <modules> du répertoire d'installation de GlassFish v3, que vous devez impérativement introduire dans votre projet.

   Bien évidemment, pour que la communication se fasse correctement, vous devez préciser l'adresse IP du serveur d'applications dans le réseau local de l'entreprise. Ceci se spécifie au travers d'une propriété nommée org.omg.CORBA.ORBInitialHost.

2. Une fois que le contexte est défini, vous devez maintenant localiser l'EJB qui va réaliser le traitement de la logique métier au sein du serveur d'applications. Cela se fait par l'intermédiaire de la méthode lookup() du contexte créé précédemment. Vous spécifiez alors en argument le nom JNDI de l'objet distant. Si tout se passe bien, la référence de l'objet (proxy) est alors récupérée par la méthode. Il faut, par contre transtyper cette référence pour qu'elle corresponde à l'interface représentant l'objet distant.

   // Côté serveur
   @Stateless
   @LocalBean
   public class Conversion implements ConversionRemote {
   ...
   }
   
   // Code client
   Properties propriétés = new Properties();
   propriétés.setProperty("org.omg.CORBA.ORBInitialHost", "192.168.1.14");  // localisation du serveur d'applications dans le réseau local de l'entreprise
   Context ctx = new InitialContext(propriétés);
   ConversionRemote convertirRemote = (ConversionRemote) ctx.lookup("java:global/ProjetConversion/ConversionsEJB/ConversionBean!ConversionRemote");

Nous connaissons déjà les interfaces. Vous avez juste à déclarer toutes les méthodes publiques qui doivent être accessibles par le client. Vous n'avez pas besoin de mettre systématiquement le qualificateur public puisque toutes les méthodes qui sont dans l'interface sont nécessairement publiques. Je prévois deux méthodes pour chacune des conversions prévues.

ConversionRemote.java

package session;

import javax.ejb.Remote;

@Remote
public interface ConversionRemote {
    double francEuro(double franc);
    double euroFranc(double euro);
}  

Lorsque vous devez mettre en oeuvre des interfaces pour être en relation avec des EJB, vous devez spécifier le type d'accès. Ici, nous désirons que cet EJB soit accessible à distance, vous devez donc rajouter l'annotation @Remote juste avant la déclaration de l'interface. Je rappelle que les annotations sont préfixées par le symbole @. Pour que cette annotation soit prise en compte, vous devez importer cette annotation depuis le paquetage javax.ejb (avec Netbeans, tous ces éléments sont automatiquement spécifiés).

Une fois que l'interface est construite, vous pouvez maintenant vous occuper de la classe du bean session sans état qui va implémenter cette interface et qui va donc redéfinir, au moins, toutes les méthodes désignées et ainsi réaliser tout le traitement de la logique métier. Dans notre cas, nous définissons juste les méthodes de l'interface. Il n'existe pas spécialement de méthodes privées supplémentaires.

Conversion.java

package session;

import javax.ejb.Stateless;

@Stateless
public class Conversion implements ConversionRemote {
    private final double TAUX = 6.55957;

    @Override
    public double francEuro(double franc) {
        return franc / TAUX;
    }

    @Override
    public double euroFranc(double euro) {
        return euro * TAUX;
    }
}

Encore une fois, nous avons besoin d'utiliser une annotation qui va spécifier quel est le type de bean session à construire. Je rappelle qu'il existe trois types de bean session, soit Stateless, soit Stateful ou soit Singleton. Juste avant la déclaration de la classe, vous précisez l'annotation correspondante au type de bean session, ici donc @Stateless. Encore une fois, il est nécessaire de faire l'importation correspondante (ici aussi, avec Netbeans, tous ces éléments sont automatiquement spécifiés).

Au niveau codage, tout est fini. Remarquez bien l'extrême simplicité d'écriture. C'est notamment beaucoup plus simple que RMI puisque vous n'avez pas besoin de vous occuper de créer l'objet distant. C'est le serveur d'applications qui gère tout cela.

Vous devez ensuite déployer votre EJB sur le serveur d'applications. Il faut alors construire une archive (extension .jar) qui comporte ces deux éléments : l'interface métier et la classe du bean. L'idéal est de disposer d'un outil de développement qui permet de réaliser tout cela automatiquement. Avec Netbeans, il suffit de cliquer sur le bouton Run pour que tout soit : compilé, archivé et déployé. Bien évidemment, il faut que votre serveur d'applications soit pris en compte par votre outil de développement comme nous l'avons fait lors de l'élaboration du projet.

Ainsi donc, pour que la communication puisse se faire avec l'objet distant, vous devez placer dans votre projet l'interface ConversionRemote qui représente le bean session Conversion qui va rendre le service désiré à distance.

Egalement dans ce projet, pour que l'application cliente autonome (standalone) puisse fonctionner correctement lors de la communication avec le serveur d'applications, vous devez intégrer un nombre conséquent d'archives (défaut de cette solution par appel JNDI) qui se situe dans le sous-répertoire <module> du répertoire d'installation de GlassFish. Ce sous-répertoire possède bien d'autres archives qui peuvent s'avérer nécessaires suivant le cas. Pour éviter de rechercher chacune de ces archives à chaque fois que vous faites une application cliente autonome, l'idéal est de fabriquer une bibliothèque définitive dans NetBeans, ici ClientEJB.

Le client doit localiser l'EJB qu'il souhaite récupérer via le service JNDI. Effectivement, les composants déployés sur le serveur d'applications sont enregistrés dans l'annuaire du serveur avec donc un nom JNDI associé à l'EJB.

Je rappelle que les appels de méthodes distantes se font par RMI (protocole réseau) alors que les appels de méthodes locales se font directement dans la JVM du serveur (sans protocole réseau).

Une fois que la localisation s'est bien déroulée, au moyen de l'interface, le client récupère une référence de l'EJB (proxy) qu'il souhaite utiliser. Celui-ci peut alors appeler les méthodes du proxy sans se soucier des contraintes de communication. En effet, l'appel d'une méthode est automatiquement transmis à l'instance de l'EJB dans le conteneur. Cette instance traite la méthode et retourne le résultat au client. La création du proxy est à la charge du conteneur et reste totalement transparente pour le client.

conversion.Client.java

package conversion;

import java.awt.*;
import java.awt.event.*;
import java.text.*;
import java.util.Properties;
import javax.naming.*;
import javax.swing.*;
import session.ConversionRemote;

public class Client extends JFrame implements ActionListener {
   private JFormattedTextField euro = new JFormattedTextField(NumberFormat.getCurrencyInstance());
   private JFormattedTextField franc = new JFormattedTextField(new DecimalFormat("#,##0.00 F"));
   private static ConversionRemote convertir;
   
   public Client() {
      super("Conversion à distance");
      euro.setColumns(25);
      euro.setHorizontalAlignment(JFormattedTextField.RIGHT);
      euro.setValue(0);      
      add(euro, BorderLayout.NORTH);
      franc.setHorizontalAlignment(JFormattedTextField.RIGHT);
      franc.setValue(0);
      add(franc, BorderLayout.SOUTH);
      euro.addActionListener(this);
      franc.addActionListener(this);
      getContentPane().setBackground(Color.orange);
      pack();
      setResizable(false);
      setDefaultCloseOperation(EXIT_ON_CLOSE);
      setVisible(true);
   }

   public void actionPerformed(ActionEvent evt) {
      if (evt.getSource()==franc)  {
          Number valeur = (Number) franc.getValue();
          euro.setValue(convertir.francEuro(valeur.doubleValue()));
      }
      if (evt.getSource()==euro) {
          Number valeur = (Number) euro.getValue();
          franc.setValue(convertir.euroFranc(valeur.doubleValue()));
      }
   }
   
   public static void main(String[] args)  {
        try {
            Properties propriétés = new Properties();
            propriétés.setProperty("org.omg.CORBA.ORBInitialHost", "192.168.1.14");
            Context ctx = new InitialContext(propriétés);
//            convertir = (ConversionRemote) ctx.lookup("java:global/ConversionEJB/Conversion!session.ConversionRemote");
            convertir = (ConversionRemote) ctx.lookup("java:global/ConversionEJB/Conversion");
            new Client();
        }
        catch (NamingException ex) {
            JOptionPane.showMessageDialog(null, "Impossible de dialoguer avec le serveur d'applications");
        }
   }   
}

La première chose à faire, nous l'avons souligné en préambule, est de récupérer une instance de l'EJB au moyen de JNDI. Pour cela vous devez mettre en oeuvre un contexte pour l'application cliente qui va permettre de faire la recherche du nom JNDI stocké dans l'annuaire. Il faut au préalable initialiser ce contexte avec la bonne localisation du serveur d'applications au travers d'une propriété adaptée.

Une fois que la référence du proxy est obtenue, tout devient très simple. Effectivement, il suffit de faire appel aux bonnes méthodes - euroFranc() et francEuro() - de l'objet distant qui réalisent le traitement désiré.

Vous pensez peut-être que nous avons beaucoup de chose à prendre en compte. Oui c'est vrai, mais vous allez aussi découvrir que la programmation devient extrêmement simple et surtout intuitive. En effet, lorsque vous demandez un service particulier, vous faites appel à une simple méthode d'un objet, et vous avez alors l'impression que cet objet est sur le poste client, alors qu'en réalité il est à distance sur le serveur d'applications. Vous n'avez plus besoin, dans la programmation, de stipuler tout ce qui concerne la problématique du réseau (les sockets, les flux, les threads, le protocole d'échange, etc.).

Il est possible d'avoir une autre approche et de proposer un conteneur spécifique côté client qui s'affranchit de tout ces fichiers annexes. Ce conteneur s'appelle Application Client Container que nous traiterons dans le chapitre suivant.

Attention, lorsque vous proposer une connexion distante, toutes les informations qui transitent sur le réseau doivent impérativement être sérialisables.
.

Nous devons écrire exactement les mêmes codes sources. Rien n'a fondamentalement changé, puisque nous devons faire un accès au service proposé à distance sous une autre machine virtuelle Java. Je rappelle ci-dessous les deux codes sources :

ConversionRemote.java

package session;

import javax.ejb.Remote;

@Remote
public interface ConversionRemote {
    double francEuro(double franc);
    double euroFranc(double euro);
}  

Conversion.java

package session;

import javax.ejb.Stateless;

@Stateless
public class Conversion implements ConversionRemote {
    private final double TAUX = 6.55957;

    @Override
    public double francEuro(double franc) {
        return franc / TAUX;
    }

    @Override
    public double euroFranc(double euro) {
        return euro * TAUX;
    }
}

Le codage côté serveur est toujours aussi simple. Dans ces conditions, réaliser un service multi-tâches sans préoccupation du protocole réseau ne pose plus aucun problème de fond. Nous avons juste à nous soucier de la logique métier à mettre en oeuvre.

conversion.Client.java

package conversion;

import java.awt.*;
import java.awt.event.*;
import java.text.*;
import javax.ejb.EJB;
import javax.swing.*;
import session.ConversionRemote;

public class Client extends JFrame implements ActionListener {
   private JFormattedTextField euro = new JFormattedTextField(NumberFormat.getCurrencyInstance());
   private JFormattedTextField franc = new JFormattedTextField(new DecimalFormat("#,##0.00 F"));
   @EJB
   private static ConversionRemote convertir;
   
   public Client() {
      super("Conversion à distance");
      euro.setColumns(25);
      euro.setHorizontalAlignment(JFormattedTextField.RIGHT);
      euro.setValue(0);      
      add(euro, BorderLayout.NORTH);
      franc.setHorizontalAlignment(JFormattedTextField.RIGHT);
      franc.setValue(0);
      add(franc, BorderLayout.SOUTH);
      euro.addActionListener(this);
      franc.addActionListener(this);
      getContentPane().setBackground(Color.orange);
      pack();
      setResizable(false);
      setDefaultCloseOperation(EXIT_ON_CLOSE);
      setVisible(true);
   }

   public void actionPerformed(ActionEvent evt) {
      if (evt.getSource()==franc)  {
          Number valeur = (Number) franc.getValue();
          euro.setValue(convertir.francEuro(valeur.doubleValue()));
      }
      if (evt.getSource()==euro) {
          Number valeur = (Number) euro.getValue();
          franc.setValue(convertir.euroFranc(valeur.doubleValue()));
      }
   }
   
   public static void main(String[] args)  {  new Client();  }   
}

La grande nouveauté, par rapport à une application standalone, c'est que nous n'avons plus besoin de mettre en place, à la fois le contexte de l'application et faire la recherche par le service JNDI. Tout se fait automatiquement, à la condition, bien entendu, de le spécifier au moyen de l'annotation @EJB.

Attention, l'annotation @EJB ne peut être utilisée qu'à l'intérieur même de la classe de démarrage et doit être positionnée avec le qualificateur static. Cela est du au fait que le conteneur exécute la méthode main() qui est elle-même statique.

L'application cliente s'exécute dans un conteneur. De ce fait, c'est ce dernier qui démarre l'application et non la machine virtuelle directement (comme pour les applications Java standalone). Le temps de démarrage est du coup sensiblement plus long.

Nous devons écrire le même code source que précédemment sans ce préoccuper cette fois-ci d'implémenter une quelconque interface. Il s'agit d'une simple classe qui possède l'annotation @Stateless. Par ailleurs, les méthodes métiers ne devront plus également posséder l'annotation @Override puisque nous n'avons plus à les redéfinir, mais simplement à les définir :

Conversion.java

package session;

import javax.ejb.Stateless;

@Stateless
public class Conversion  {
    private final double TAUX = 6.55957;

    public double francEuro(double franc) {
        return franc / TAUX;
    }

    public double euroFranc(double euro) {
        return euro * TAUX;
    }
}

Le codage côté serveur est encore plus simple que précédemment. Dans ces conditions, nous avons juste à nous soucier de la logique métier à mettre en oeuvre au travers de méthodes adaptées.

1. La partie contrôleur : dont l'action est assuré par la servlet FacesServlet. Cette servlet réceptionne l'ensemble des requêtes HTTP issues d'un navigateur et lance la visualisation de la bonne page Web, suivant les requêtes proposées. Cette page Web est en constante relation avec le JavaBean correspondant. Dans le projet que nous venons de mettre en place, la servlet FacesServlet est déjà automatiquement construire même si elle est totalement invisible. Vous n'avez aucun code à fournir. Par contre, des annotations sur le (ou les) JavaBean (partie modèle) permettront d'influencer le comportement de la servlet (configurations, réglages, créations, etc.).
2. La partie vue : dont l'affichage (la mise en page) est assurée par une simple page Web index.xhtml. Vous avez alors à votre disposition un certain nombre de balises propriétaires qui permettent d'afficher des éléments de haut niveau. Par ailleurs, à l'aide de ces balises spécifiques, vous pouvez réaliser des conversions automatiques, comme les valeurs monétaires par exemple. Il est également possible de contrôler la validité des valeurs saisies par l'opérateur. Cette partie, comme son nom l'indique ne s'occupe que de l'affichage. Le traitement proprement dit est réalisé par le modèle, c'est-à-dire par le JavaBean qui est en constante relation avec la page Web pour que la prise en compte des valeurs et la visualisation du résultat correspondant se fasse en parfaite adéquation.
3. La partie modèle : dont la gestion est assurée par le JavaBean Client qui est en relation directe avec la page Web précédente, qui mémorise donc toute les interventions de l'opérateur et qui finalement donne la réponse souhaitée en faisant toutefois appel au service proposé par l'EJB de conversions monétaires. La relation avec l'EJB se fait par le seul biais de l'injection de dépendance @EJB.

Dans la figure ci-dessus, la servlet contrôleur fabrique un objet (un bean) qui, sauf avis contraire, porte le même nom que la classe avec toutefois la première lettre en minuscule. Ainsi comme notre modèle s'appelle Client, le nom du bean sera donc client. Cet objet persiste jusqu'à ce que l'opérateur quitte l'application Web.

A partir de là, la page Web peut se connecter, si elle le désire, sur ce bean est être en interaction avec les différentes propriétés qu'il propose, à l'occurence ici euro et franc.

Je rappelle qu'une propriété en Java se reconnait par les méthodes dont les signatures sont les suivantes : getXxx() et setXxx() (lecture, écriture). Auquel cas, le nom de la propriété porte le même nom que la méthode sans le get ou le set, le tout en minuscule. Ainsi getEuro() est la méthode de lecture de la propriété euro.

Il est possible d'avoir un seul bean qui gère le traitement des informations pour plusieurs pages Web. Inversement une seule page Web peut réclamer les compétences de plusieurs beans. C'est vous qui décidez de l'architecture la plus adaptée à la situation.

Voilà ci-dessous la page Web qui représente la vue. Remarquez au passage la simplicité d'écriture et surtout la légéreté du code lorsque nous utilisons cette technologie JSF. Avec cette approche, nous séparons le rendu du traitement de fond. Deux experts peuvent alors concevoir une application Web, chacun ayant sa propre tâche ; le WebMaster d'un côté pour la partie visuelle, et le développeur Java pour le traitement des données.

conversion.Client.java

package bean;

import javax.ejb.EJB;
import javax.faces.bean.*;
import session.Conversion;

@ManagedBean
public class Client {
    private double franc;
    private double euro;
    @EJB
    private Conversion convertir;

    public double getEuro() { return euro; }
    public void setEuro(double euro) { this.euro = euro; }

    public double getFranc() { return franc; }
    public void setFranc(double franc) {  this.franc = franc;  }

    public void changeFranc() { franc = convertir.euroFranc(euro);  }
    public void changeEuro() { euro = convertir.francEuro(franc);  }
}

index.xhtml

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">

    <style type="text/css">
        body { background-color: green; }
        .saisie { text-align: right; font-weight: bold; padding-right: 5px; background-color: greenyellow;  color: green; }
    </style>
    
      <h:body>
         <h:form>
           <h:inputText value="#{client.euro}" styleClass="saisie">
               <f:convertNumber type="currency" currencySymbol="E"/>
           </h:inputText>
           <h:commandButton action="#{client.changeFranc}" value="-> Franc" />
           <br />
           <h:inputText value="#{client.franc}" styleClass="saisie">
               <f:convertNumber type="currency" currencySymbol="F" />
           </h:inputText>
           <h:commandButton action="#{client.changeEuro}" value="-> Euros" />
        </h:form>
      </h:body>
</html>  

Certainement le plus gros avantage d'un accès en mode local, c'est que vous n'avez pas besoin de sérialiser vos valeurs qui transitent entre l'EJB et l'application Web.

Par ailleurs, le fait d'avoir une application Web, vous n'avez plus besoin de vous soucier de déployer votre application puisque le client est un simple navigateur sans compétence particulière même sur la technologie Java. Aucun pluggin n'est à installer. En effet, votre application Web propose des pages Web dynamiques, c'est-à-dire que l'application Web va générer des pages web HTML à la volée suivant les requêtes soumises par l'opérateur (donc en finalité des pages HTML standard).

Cette toute dernière version Java EE 6 permet d'intégrer directement des beans sessions à l'intérieur d'un projet d'application web. Ce qui donne une grande souplesse. Cela nous permet d'éviter de faire systématiquement des projets d'entreprise, avec deux projets en interne, le module Web d'un côté, et le module EJB de l'autre.

Bien évidemment nous retrouvons pratiquement les mêmes codes sources. Nous devons penser toutefois à rajouter l'annotation @LocalBean afin que le modèle de l'application Web puisse accéder au service proposé par le bean session en local.

ConversionRemote.java

package session;

import javax.ejb.Remote;

@Remote
public interface ConversionRemote {
    double francEuro(double franc);
    double euroFranc(double euro);
}  

Conversion.java

package session;

import javax.ejb.Stateless;

@Stateless
@LocalBean
public class Conversion implements ConversionRemote {
    private final double TAUX = 6.55957;

    @Override
    public double francEuro(double franc) {
        return franc / TAUX;
    }

    @Override
    public double euroFranc(double euro) {
        return euro * TAUX;
    }
}

conversion.Client.java

package bean;

import javax.ejb.EJB;
import javax.faces.bean.*;
import session.Conversion;

@ManagedBean
public class Client {
    private double franc;
    private double euro;
    @EJB
    private Conversion convertir;

    public double getEuro() { return euro; }
    public void setEuro(double euro) { this.euro = euro; }

    public double getFranc() { return franc; }
    public void setFranc(double franc) {  this.franc = franc;  }

    public void changeFranc() { franc = convertir.euroFranc(euro);  }
    public void changeEuro() { euro = convertir.francEuro(franc);  }
}

index.xhtml

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">

    <style type="text/css">
        body { background-color: green; }
        .saisie { text-align: right; font-weight: bold; padding-right: 5px; background-color: greenyellow;  color: green; }
    </style>
    
      <h:body>
         <h:form>
           <h:inputText value="#{client.euro}" styleClass="saisie">
               <f:convertNumber type="currency" currencySymbol="E"/>
           </h:inputText>
           <h:commandButton action="#{client.changeFranc}" value="-> Franc" />
           <br />
           <h:inputText value="#{client.franc}" styleClass="saisie">
               <f:convertNumber type="currency" currencySymbol="F" />
           </h:inputText>
           <h:commandButton action="#{client.changeEuro}" value="-> Euros" />
        </h:form>
      </h:body>
</html>

conversion.Client.java

package conversion;

import java.awt.*;
import java.awt.event.*;
import java.text.*;
import javax.ejb.EJB;
import javax.swing.*;
import session.ConversionRemote;

public class Client extends JFrame implements ActionListener {
   private JFormattedTextField euro = new JFormattedTextField(NumberFormat.getCurrencyInstance());
   private JFormattedTextField franc = new JFormattedTextField(new DecimalFormat("#,##0.00 F"));
   @EJB
   private static ConversionRemote convertir;
   
   public Client() {
      super("Conversion à distance");
      euro.setColumns(25);
      euro.setHorizontalAlignment(JFormattedTextField.RIGHT);
      euro.setValue(0);      
      add(euro, BorderLayout.NORTH);
      franc.setHorizontalAlignment(JFormattedTextField.RIGHT);
      franc.setValue(0);
      add(franc, BorderLayout.SOUTH);
      euro.addActionListener(this);
      franc.addActionListener(this);
      getContentPane().setBackground(Color.orange);
      pack();
      setResizable(false);
      setDefaultCloseOperation(EXIT_ON_CLOSE);
      setVisible(true);
   }

   public void actionPerformed(ActionEvent evt) {
      if (evt.getSource()==franc)  {
          Number valeur = (Number) franc.getValue();
          euro.setValue(convertir.francEuro(valeur.doubleValue()));
      }
      if (evt.getSource()==euro) {
          Number valeur = (Number) euro.getValue();
          franc.setValue(convertir.euroFranc(valeur.doubleValue()));
      }
   }
   
   public static void main(String[] args)  {  new Client();  }   
}

ArchiveRemote.java

package session;

import java.io.IOException;
import javax.ejb.Remote;

@Remote
public interface ArchiveRemote {
    final int BUFFER = 4096;   
    
    String[] listeNomFichier();
    void suppression(String nomFichier);
    
    int sauvegarde(String nomFichier, int taille)  throws IOException;
    void envoiOctets(byte[] octets) throws IOException;

    int restituer(String nomFichier) throws IOException;   
    byte[] recupereOctets() throws IOException;   
}

Archive.java

package session;

import java.io.*;
import javax.ejb.*;

@Stateful
public class Archive implements ArchiveRemote {
   private final String répertoire = "F:/Archivage/";
   private String nomFichier;
   private BufferedOutputStream enregistrement;
   private BufferedInputStream lecture;
   private int taille;
   private int nombre;

   @Override
   public String[] listeNomFichier() { return new File(répertoire).list(); }

   @Override
   public void suppression(String nomFichier) {  new File(répertoire+nomFichier).delete();  }

   @Override
   public int sauvegarde(String nomFichier, int taille)  throws IOException {
       this.nomFichier = nomFichier;
       enregistrement = new BufferedOutputStream(new FileOutputStream(répertoire + nomFichier));
       this.taille = taille;
       return nombre = this.taille / BUFFER;
   }

   @Override
   public void envoiOctets(byte[] octets) throws IOException {
      enregistrement.write(octets);
      nombre--;
      if (nombre<0) enregistrement.close();
   }

   @Override
    public int restituer(String nomFichier) throws IOException {
        lecture = new BufferedInputStream(new FileInputStream(répertoire+nomFichier));
        return lecture.available();
   }

   @Override
   public byte[] recupereOctets() throws IOException {
      byte[] octets = lecture.available() >= BUFFER ? new byte[BUFFER] : new byte[lecture.available()];
      lecture.read(octets);
      if (lecture.available() <= 0) lecture.close();
      return octets;
   }
}

Ce bean session avec état propose quatre fonctionnalités de base :

1. Procure la liste des fichiers déjà archivés.
2. Supprime un fichier spécifique sur le serveur.
3. Stocke un fichier proposé par le client.
4. Récupère pour le client un fichier archivé dans le serveur.

Par ailleurs, nous remarquons deux différences fondamentales par rapport au bean session sans état.

1. Ce bean session avec état possède beaucoup plus d'attributs qui permettent de mémoriser un certain nombre de valeurs importantes afin de conserver les états intermédiaires.
2. Généralement, un bean session avec état propose plusieurs méthodes pour une même fonctionnalité donnée. Par exemple, pour sauvegarder un fichier du client sur le serveur, nous sommes obligé d'appeler deux méthodes ; d'une part la méthode sauvegarde() qui permet entre autre de mettre en place le flux côté serveur, et ensuite la méthode envoiOctets() qui stocke successivement les blocs d'octets constituant le fichier à archiver. Cette dernière méthode est appelée autant de fois que nécessaire jusqu'à ce que la totalité du fichier soit définitivement envoyé. Pour la récupération d'un fichier, nous adoptons la même procédure ; là aussi nous devons passer par deux méthodes, respectivement restituer() et recupereOctets().

Mise à part ces quelques remarques, nous pouvons souligner encore une fois que la mise en oeuvre d'une communication réseau, cette fois-ci d'ailleurs relativement sophistiqué, est d'une extrême simplicité. En aucun moment, nous faisons référence au réseau. Et pourtant, nous envoyons de très gros fichiers au travers de celui-ci. Il suffit juste d'appeler les bonnes méthodes avec les bons paramètres, comme lors de l'utilisation d'un simple objet local, alors qu'ici, il se trouve tout simplement à distance.

D'après ce que nous avons évoqué en introduction, il est possible de rajouter des annotations supplémentaires pour gérer explicitement l'expiration du bean session avec un délai spécifique ou par l'appel d'une méthode adaptée.

Archive.java

package session;

import java.io.*;
import javax.ejb.*;

@Stateful
@StatefulTimeout(20000) // délai d'expiration
public class Archive implements ArchiveRemote {
   private final String répertoire = "F:/Archivage/";
   private String nomFichier;
   private BufferedOutputStream enregistrement;
   private BufferedInputStream lecture;
   private int taille;
   private int nombre;

   @Override
   public String[] listeNomFichier() { return new File(répertoire).list(); }

   @Override
   public void suppression(String nomFichier) {  new File(répertoire+nomFichier).delete();  }

   @Override
   public int sauvegarde(String nomFichier, int taille)  throws IOException {
       this.nomFichier = nomFichier;
       enregistrement = new BufferedOutputStream(new FileOutputStream(répertoire + nomFichier));
       this.taille = taille;
       return nombre = this.taille / BUFFER;
   }

   @Override
   public void envoiOctets(byte[] octets) throws IOException {
      enregistrement.write(octets);
      nombre--;
      if (nombre<0) enregistrement.close();
   }

   @Override
    public int restituer(String nomFichier) throws IOException {
        lecture = new BufferedInputStream(new FileInputStream(répertoire+nomFichier));
        return lecture.available();
   }

   @Override
   public byte[] recupereOctets() throws IOException {
      byte[] octets = lecture.available() >= BUFFER ? new byte[BUFFER] : new byte[lecture.available()];
      lecture.read(octets);
      if (lecture.available() <= 0) lecture.close();
      return octets;
   }

   @Remove  // expiration du bean session à l'issu de l'exécution de cette méthode
   public void annuler() throws IOException {
      lecture.close();
      enregistrement.close();
   }
}

archivage.Client.java

package archivage;

import session.ArchiveRemote;
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import javax.ejb.EJB;
import javax.swing.*;
import java.util.List;

public class Client extends JFrame {
   private JToolBar barre = new JToolBar("Commandes de traitement avec le serveur");
   private JFileChooser sélecteur = new JFileChooser();
   private JComboBox liste = new JComboBox();
   private JProgressBar progression = new JProgressBar();
   private JTextField résultat = new JTextField("Faites votre choix ... ", 40);
   private enum ChoixTransfert {SAUVEGARDER, RESTITUER};
   @EJB
   private static ArchiveRemote archive;

   public Client() {
       super("Sauvegarde de fichiers à distance...");
       add(barre, BorderLayout.NORTH);
       add(résultat);
       add(liste, BorderLayout.SOUTH);
       barre.add(new AbstractAction("Sauvegarde") {
          @Override
          public void actionPerformed(ActionEvent e) {
             sélecteur.setFileSelectionMode(JFileChooser.FILES_ONLY);
             if (sélecteur.showDialog(null, "Envoi du fichier sélectionné")==JFileChooser.APPROVE_OPTION)
                new TransfertFichier(sélecteur.getSelectedFile(), ChoixTransfert.SAUVEGARDER).execute();
          }
       });
       barre.add(new AbstractAction("Restitution") {
          @Override
          public void actionPerformed(ActionEvent e) {
             sélecteur.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
             if (sélecteur.showDialog(null, "Répertoire de restitution")==JFileChooser.APPROVE_OPTION)
                new TransfertFichier(sélecteur.getSelectedFile(), ChoixTransfert.RESTITUER).execute();
          }
       });
       barre.add(new AbstractAction("Suppression") {
          @Override
          public void actionPerformed(ActionEvent e) {
             String nomFichier = (String) liste.getSelectedItem();
             archive.suppression(nomFichier);
             listeDesFichiers();
             résultat.setText("Le fichier ( "+nomFichier+" ) est définitevement supprimé ...");
         }
       });
       barre.addSeparator();
       barre.add(progression);
       progression.setStringPainted(true);
       progression.setVisible(false);
       résultat.setEditable(false);
       résultat.setMargin(new Insets(3, 3, 3, 3));
       résultat.setBackground(Color.BLUE);
       résultat.setForeground(Color.YELLOW);
       listeDesFichiers();
       pack();
       setLocationRelativeTo(null);
       setDefaultCloseOperation(EXIT_ON_CLOSE);
       setVisible(true);
   }

   private void listeDesFichiers() {
      liste.removeAllItems();
      for (String nomFichier : archive.listeNomFichier()) liste.addItem(nomFichier);
   }

   public static void main(String[] args) { new Client(); }

   private class TransfertFichier extends SwingWorker<String, Integer> {
      private File fichier;
      private int octetsLus, maximum, nombre;
      private ChoixTransfert transfert;
      private final int BUFFER;
      private String nomFichier;

      public TransfertFichier(File fichier, ChoixTransfert transfert) {
         this.fichier = fichier;
         this.transfert = transfert;
         BUFFER = archive.BUFFER;
      }

      @Override
      protected String doInBackground() throws Exception {
         try {
            progression.setVisible(true);
            progression.setValue(0);
            octetsLus = 0;
            byte[] octets = new byte[BUFFER];
            switch (transfert) {
               case SAUVEGARDER :
                   nomFichier = fichier.getName();
                   résultat.setText("Le fichier ( "+nomFichier+" ) est en cours de transfert ...");
                   BufferedInputStream lecture = new BufferedInputStream(new FileInputStream(fichier));
                   progression.setMaximum(maximum = lecture.available());
                   nombre = archive.sauvegarde(fichier.getName(), maximum);
                   for (int i=0; i < nombre; i++) {
                       lecture.read(octets);
                       archive.envoiOctets(octets);
                       publish(octetsLus += BUFFER);
                   }
                   octets = new byte[lecture.available()];
                   lecture.read(octets);
                   archive.envoiOctets(octets);
                   lecture.close();
                   break;
               case RESTITUER :
                   nomFichier = (String) liste.getSelectedItem();
                   résultat.setText("Le fichier ( "+nomFichier+" ) est en cours de transfert ...");
                   BufferedOutputStream écriture = new BufferedOutputStream(new FileOutputStream(fichier+ "/"+ nomFichier));
                   nombre = (maximum = archive.restituer(nomFichier)) / BUFFER;
                   progression.setMaximum(maximum);
                   for (int i=0; i <= nombre; i++) {
                       octets = archive.recupereOctets();
                       écriture.write(octets);
                       publish(octetsLus += BUFFER);
                   }
                  écriture.close();
                  break;
            }
            listeDesFichiers();
            return "Le fichier ( "+nomFichier+" ) est entièrement transféré ...";
         }
         catch (FileNotFoundException ex) {
            return "ATTENTION : Le fichier n'existe pas";
         }
         catch (IOException ex) {
            return "ATTENTION : Impossible de transférer le fichier";
         }
      }

      @Override
      protected void process(List<Integer> nombres) {
         progression.setValue(nombres.get(nombres.size()-1));
      }

      @Override
      protected void done() {
         try {
            résultat.setText(get());
            progression.setVisible(false);
         }
         catch (Exception ex) { }
      }
   }
}

Dans cette application cliente, nous désirons faire en sorte de connaître en temps réel la progression du transfert de fichier. Pour cela, nous devons mettre en oeuvre un système multi-tâches afin que la visualisation de la progression ne soit pas bloquée par la commande de transfert.

Utilisation du travailleur Swing

Lorsqu'un utilisateur émet une commande pour laquelle le traitement est long, vous devez déclencher un nouveau thread pour qu'il effectue le travail. Il existe maintenant, depuis Java SE 6.0, une classe intéressante qui simplifie le travail, et qui permet surtout de suivre une progression. Il s'agit de la classe SwingWorker.

Mise en oeuvre de la classe SwingWorker

Vous devez construire une nouvelle classe qui hérite de cette classe SwingWorker qui va permettre les fonctionnalités globales suivantes :

1. Après chaque unité de travail, actualise l'interface utilisateur pour afficher une progression.
2. Une fois le travail terminé, apporte une dernière modification à l'interface utilisateur.

La classe SwingWorker simplifie l'implémentation de cette tâche. Voici la procédure exacte à suivre :

1. Vous redifinissez la méthode doInBackground() pour effectuer le travail de longue haleine et vous appelez parfois la méthode publish() pour communiquer la progression du travail. Cette méthode est exécutée dans un thread travailleur.
2. La méthode publish() amène une méthode progress() à s'exécuter dans le thread de répartition des événements pour traiter les données de la progression.
3. A la fin du travail, la méthode done() est appelée dans le thread de répartition des événements pour que vous finissiez la mise à jour de l'interface utilisateur.
4. Dès que vous souhaitez travailler dans le thread travailleur, construisez un nouveau travailleur (chaque objet travailleur a pour but d'être utilisé une seule fois). Appelez ensuite la méthode execute(). Vous appelerez généralement la méthode execute() sur le thread de répartition des événements, mais ce n'est pas une obligation.
5. Nous pouvons supposer qu'un travailleur produise un résultat d'un certain type (SwingWorker<Type, Value> implémente Future<Type>). Ce résultat peut être obtenu par la méthode get() de l'interface Future.
6. Puisque la méthode get() se bloque jusqu'à ce que le résultat soit disponible, vous ne devez pas l'appeler immédiatement après execute(). Généralement, vous l'appelez depuis la méthode done() (il n'y a aucune obligation d'appeler get(), parfois, le traitement des données de progression suffit).
7. Les données de progression intermédiaire et le résultat final peuvent avoir des types arbitraires. La classe SwingWorker possède ces types comme paramètres de type. Ainsi, un SwingWorker<Type, Value> produit un résultat de type Type et des données de type Value.
8. Pour annuler l'opération en cours, utilisez la méthode cancel() de l'interface Future. Lorsque le travail est annulé, la méthode get() déclenche une CancellationException.
9. Nous l'avons indiqué, l'appel du thread travailleur à publish() entraîne des appels à process() sur le thread de répartition des événements. Pour des raisons d'efficacité, les résultats de plusieurs appels à publish() peuvent être regroupés en un seul appel à process(). La méthode process() reçoit un List<Value> contenant tous les résultats intermédiaires.

Pour en savoir plus avec SwingBuilder.
.

import javax.ejb.Singleton;

@Singleton
public class Cache {
    private Map<Element> stockage = new HashMap<String, Element>();
   
    public void ajouterAuCache(String id, Element élément) {
        if (!stockage.containsKey(id)) stockage.put(id, élément);
    }

    public void enleverDuCache(String id) {
        if (stockage.containsKey(id)) stockage.remove(id);
    }

    public Element récupérerDuCache(String id) {
        if (stockage.containsKey(id)) return stockage.get(id);
        else return null;
    }
} 

L'avantage des EJBs Singletons, c'est qu'ils offrent tous les services d'un EJB : sécurité, transaction, injection de dépendances, gestion du cycle de vie et intercepteurs, ...
.

Comme vous pouvez le constater, les beans session sans état (Stateless), avec état (Stateful) et singletons (Singleton) sont très simples à écrire puisqu'il suffit d'une seule annotation. Les singletons, toutefois, offrent plus de possibilités : ils peuvent être initialisés au lancement de l'application, chaînés ensemble, et il est possible de personnaliser finement leur accès concurrents : en proposant des verrous, en interdisant l'accès, en synchronisant, etc.

Par contre, les singletons ne sont pas compatibles avec les clusters. Un cluster est un groupe de conteneurs fonctionnant de concert (ils partagent les mêmes ressources, les mêmes EJB, etc.). Lorsqu'il y a plusieurs conteneurs répartis en cluster sur des machines différentes, chaque conteneur aura donc sa propre instance du singleton.

1. Exécution du code au lancement du code ou à l'arrêt de l'application.
2. Partage des données avec gestion des accès concurrents.

L'état de l'EJB est maintenu par le conteneur durant toute la durée de vie de l'application : cet état n'est pas persistant à l'arrêt de l'application ou de la JVM.
.

import javax.ejb.Singleton;

@Singleton
@Startup
public class Cache {
...
} 

@Singleton
public class CodePays {
...
} 

@Singleton
@DependsOn("CodePays")
public class Cache {
...
} 

@DependsOn prend en paramètre une ou plusieurs chaînes désignant chacune le nom d'un bean singleton dont dépend le singleton annoté. Le code suivant, par exemple, montre que Cache dépend de l'initialisation de CodePays et de CodePostal :

@Singleton
public class CodePostal {
...
} 

@Singleton
public class CodePays {
...
} 

@DependsOn("CodePays", "CodePostal")
@Startup
@Singleton
public class Cache {
...
} 

Comme vous pouvez le constater dans le code précédent, il vous est même possible de combiner ces dépendance avec une initialisation lors du démarrage de l'application : Cache étant initialisé dès le lancement (car il est annoté par @Startup), du coup CodePays et CodePostal le seront également, mais avant lui.

@Startup
@Singleton
@DependsOn("CodePays")
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Lock(LockType.READ)
@AccessTimeout(15000)
public class Cache {
...
} 

import javax.ejb.Singleton;

@Singleton
@Lock(LockType.READ )
public class Cache {
    private Map<Element> stockage = new HashMap<String, Element>();
   
    public void ajouterAuCache(String id, Element élément) {
        if (!stockage.containsKey(id)) stockage.put(id, élément);
    }

    public void enleverDuCache(String id) {
        if (stockage.containsKey(id)) stockage.remove(id);
    }

    @AccessTimeout(2000)
    @Lock(LockType.WRITE)
    public Element récupérerDuCache(String id) {
        if (stockage.containsKey(id)) return stockage.get(id);
        else return null;
    }
} 

Dans ce code, le bean Cache utilise un verrou READ, ce qui implique que toutes ses méthodes auront un verrou partagé, sauf pour récupérerDuCache() qui a été redéfinie à WRITE (exclusif). Vous remarquez également la présence de l'annotation @AccessTimeout sur cette méthode qui permet de limiter le temps pendant lequel un accès concurrent sera bloqué : si le verrou n'a pas pu être obtenu dans ce délai, la requête sera rejetée avec la levée de l'exception correspondante.

import javax.ejb.Singleton;

@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class Cache {
    private Map<Element> stockage = new HashMap<String, Element>();
   
    public synchronized void ajouterAuCache(String id, Element élément) {
        if (!stockage.containsKey(id)) stockage.put(id, élément);
    }

    public void enleverDuCache(String id) {
        if (stockage.containsKey(id)) stockage.remove(id);
    }

    public synchronized  Element récupérerDuCache(String id) {
        if (stockage.containsKey(id)) return stockage.get(id);
        else return null;
    }
}

import javax.ejb.Singleton;

@Singleton
@Lock(LockType.READ )
public class Cache {
    private Map<Element> stockage = new HashMap<String, Element>();
   
    @ConcurrencyManagement(ConcurrencyManagementType.CONCURRENCY_NOT_ALLOWED )
    public void ajouterAuCache(String id, Element élément) {
        if (!stockage.containsKey(id)) stockage.put(id, élément);
    }

    public void enleverDuCache(String id) {
        if (stockage.containsKey(id)) stockage.remove(id);
    }

    @AccessTimeout(2000 )
    @Lock(LockType.WRITE )
    public Element récupérerDuCache(String id) {
        if (stockage.containsKey(id)) return stockage.get(id);
        else return null;
    }
}

Calcul.java

package session;

import java.util.Date;

public class Calcul {
    private Date instant;
    private double euro;
    private double franc;

    public Calcul(double euro, double franc) {
        instant = new Date();
        this.euro = euro;
        this.franc = franc;
    }

    public double getEuro() { return euro;  }
    public double getFranc() { return franc;  }
    public Date getInstant() { return instant;  }
}  

Historique.java

package session;

import java.util.*;
import javax.ejb.*;

@Singleton
@Lock(LockType.READ)
public class Historique {
    private List<Calcul> stockage = new ArrayList<Calcul>();

    @Lock(LockType.WRITE)
    public void ajouterCalcul(Calcul calcul) {  stockage.add(calcul); }

    public List<Calcul> lire() { return stockage; }
    public void effacer() { stockage.clear(); }
    public boolean vide() { return stockage.isEmpty(); }
}

Conversion.java

package session;

import javax.ejb.*;

@Stateless
public class Conversion  {
    private final double TAUX = 6.55957;
    @EJB
    private Historique historique;

    public double francEuro(double franc) {
        double euro = franc / TAUX;
        historique.ajouterCalcul(new Calcul(euro, franc));
        return euro;
    }

    public double euroFranc(double euro) {
        double franc = euro * TAUX;
        historique.ajouterCalcul(new Calcul(euro, franc));
        return franc;
    }
} 

conversion.Client.java

package bean;

import java.util.List;
import javax.ejb.EJB;
import javax.faces.bean.*;
import session.*;

@ManagedBean
public class Client {
    private double franc;
    private double euro;
    @EJB
    private Conversion convertir;
    @EJB
    private Historique historique;

    public double getEuro() { return euro; }
    public void setEuro(double euro) { this.euro = euro; }

    public double getFranc() { return franc; }
    public void setFranc(double franc) {  this.franc = franc;  }

    public void changeFranc() { franc = convertir.euroFranc(euro);  }
    public void changeEuro() { euro = convertir.francEuro(franc);  }

    public List<Calcul> getHistorique() { return historique.lire(); }
    public boolean isVide() { return historique.vide(); }
    public void effacer() { historique.effacer(); }
}

index.xhtml

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">

    <style type="text/css">
        body { background-color: green; }
        .saisie { text-align: right; font-weight: bold; padding-right: 5px; background-color: greenyellow;  color: green; }
        .titre { background-color: chartreuse; color: darkgreen; }
        .lignes { background-color: darkgreen; color: chartreuse; text-align: right; }
    </style>

    <h:body>
       <h:form>
           <h:inputText value="#{client.euro}" styleClass="saisie">
               <f:convertNumber type="currency"/>
           </h:inputText>
           <h:commandButton action="#{client.changeFranc}" value="-> Franc" />
           <br />
           <h:inputText value="#{client.franc}" styleClass="saisie">
               <f:convertNumber type="currency" currencySymbol="F" />
           </h:inputText>
           <h:commandButton action="#{client.changeEuro}" value="-> Euros" />
           <h:panelGroup rendered="#{not client.vide}">
               <hr />
               <h:dataTable var="calcul" value="#{client.historique}" rowClasses="lignes" headerClass="titre" cellpadding="3" cellspacing="2">
                   <h:column>
                       <f:facet name="header"><h:outputText value="Heure" /></f:facet>
                       <h:outputFormat value="{0, date, full} - {0, time, medium}">
                           <f:param value="#{calcul.instant}"/>
                       </h:outputFormat>
                   </h:column>
                   <h:column>
                       <f:facet name="header"><h:outputText value="€uro" /></f:facet>
                       <h:outputFormat value="{0, number, currency}">
                           <f:param value="#{calcul.euro}"/>
                       </h:outputFormat>
                   </h:column>
                   <h:column>
                       <f:facet name="header"><h:outputText value="Franc" /></f:facet>
                       <h:outputFormat value="{0, number, #,##0.00 F}">
                           <f:param value="#{calcul.franc}"/>
                       </h:outputFormat>
                   </h:column>
               </h:dataTable>
               <hr  />
               <h:commandButton value="Tout effacer..." action="#{client.effacer}" />
           </h:panelGroup>
        </h:form>
    </h:body>
</html>

1. @EJB : injecte dans l'attribut annoté une référence de la vue locale, distante ou sans interface d'un EJB session.
2. @PersistenceContext et @PersistenceUnit : expriment, respectivement, une dépendance sur un EntityManager et sur une EntityManagerFactory, unités de persistances pour les entités et donc pour les bases de données objets.
3. @WebServiceRef : injecte une référence à un service Web.
4. @Resource : injecte plusieurs ressources comme les sources de données JDBC, les contextes de session, les transactions, les entrées d'environnement, le service timer, etc.

1. getCallerPrincipal() : renvoie le java.security.Principal associé à l'appel.
2. getRollbackOnly() : teste si la transaction courante a été marquée pour annulation.
3. getTimerService() : renvoie l'interface javax.ejb.TimerService. Cette méthode ne peut être utilisée que par les beans sessions sans état et singleton.
4. getUserTransaction() : renvoie l'interface javax.transaction.UserTransaction permettant de délimiter les transactions. Cette méthode ne peut être utilisée que par des beans sessions avec les transactions gérées par les beans (BMT).
5. isCallerInRole() : teste si l'appelant a fourni un rôle de sécurité précis.
6. setRollbackOnly() : autorise le bean à marquer la transaction pour annulation. Cette méthode ne peut être utilisée que par des beans session avec BMT.
7. wasCancelCalled() : teste si le client a appelé la méthode cancel() sur un objet Future client correspondant à la méthode métier asynchrone en cours d'exécution.

Un bean session peut avoir accès à son contexte d'environnement en injectant une référence SessionContext à l'aide d'une annotation @Resource.

import javax.ejb.*;

@Stateless
public class CommandeLivre {
    @Resource
    private SessionContext session;

    public void commande(Livre commande) {
        ...
        if (rechercheNonAboutie())  session.setRollBackOnly(); 
    }
   ...
}

<ejb-jar>
    <enterprise-beans>
       <session>
           <ejb-name>Conversion</ejb-name>
           <ejb-class>session.Conversion</ejb-class>
           <remote>session.ConversionRemote</remote>
           <session-type>Stateless</session-type>
           <transaction-type>Container</transaction-type>
           <env-entry>
               <env-entry-name>TAUX</env-entry-name>
               <env-entry-type>java.lang.Double</env-entry-type>
               <env-entry-value>6.55957</env-entry-value>
           </env-entry>
        </session>
    </enterprise-beans>
</ejb-jar>

1. Archive jar : Si le bean session est déployé dans un fichier jar, le descripteur de déploiement doit être stocké dans le fichier META-INF/ejb-jar.xml.
2. Archive war : S'il est déployé dans un fichier war, il doit être stocké dans le fichier WEB-INF/web.xml.

@Stateful
@SatefulTimeout(20000)
public class Archive implements ArchiveRemote {
   private final String répertoire = "F:/Archivage/";  // nom du répertoire de stockage codé en dur
   ...
   @Override
   public String[] listeNomFichier() { return new File(répertoire).list(); }
   ...
}

Comme vous l'aurez compris, coder en dur ce paramètre implique de modifier le code, de le recompiler et de redéployer le composant pour chaque changement de système de fichiers. Une autre possibilité consisterait à utiliser une base de données, mais cela gaspillerait des ressources pour pas grand chose. En réalité, nous désirons simplement stocker ce paramètre à un endroit où il pourra être modifié lors du déploiement : le descripteur de déploiement est donc un emplacement de choix.

Avec EJB 3.1, le descripteur de déploiement (ejb-jar.xml) est facultatif, mais son utilisation est justifiée lorsque nous avons des paramètres liés à l'environnement. Ces entrées peuvent en effet être placées dans le fichier et être accessibles via l'injection de dépendances (ou par JNDI). Elles peuvent être de type String, Character, Byte, Short, Integer, Long, Boolean, Double et Float.

<ejb-jar>
    <enterprise-beans>
       <session>
           <ejb-name>Archive</ejb-name>
           <env-entry>
               <env-entry-name>repertoire</env-entry-name>
               <env-entry-type>java.lang.String</env-entry-type>
               <env-entry-value>F:/Archivage/</env-entry-value>
           </env-entry>
        </session>
    </enterprise-beans>
</ejb-jar>

Maintenant que les paramètres de l'application ont été externalisés dans le descripteur de déploiement, Archive peut utiliser l'injection de dépendances pour obtenir la valeur souhaitée pour la localisation du répertoire dans le système de fichiers en cours. Ainsi, l'annotation @Resource(name="repertoire") injecte la valeur de l'entrée repertoire dans l'attribut répertoire ; si les types de l'entrée et de l'attribut ne sont pas compatibles, le conteneur lève une exception.

@Stateful
@SatefulTimeout(20000)
public class Archive implements ArchiveRemote {
   @Resource(name = "repertoire")
   private final String répertoire;  // nom du répertoire de stockage codé en dur
   ...
   @Override
   public String[] listeNomFichier() { return new File(répertoire).list(); }
   ...
}

Toutes ces différentes rubriques nous seront bien utiles dans les sujets qui suivent, notamment les appels asynchrones.

1. void : Dans ce cas, il n'y aura aucun retour à la fin de l'exécution des traitements et la méthode ne doit lever aucune exception puisque celles-ci ne pourraient pas être traitées.
2. Future<T> : Dans ce cas, le client pourra avoir un contrôle sur l'état de l'exécution et obtenir la valeur de retour ou une exception levée par des traitements.

L'invocation asynchrone peut être utilisée sur tous les types d'EJB session. Par ailleurs, l'annotation @Asynchronous peut aussi bien être utilisées sur une méthode de l'EJB ou sur la classe elle-même.

1. Si l'annotation @Asynchronous est utilisée sur des méthodes alors seules ces méthodes sont invocables de façon asynchrone.
2. Si l'annotation @Asynchronous est utilisée sur la classe, toutes les méthodes sont invocables de façon asynchrone.

Le code ci-dessous montre le bean ValiderCommande qui dispose d'une méthode pour envoyer un e-mail à un client et d'une autre pour imprimer la commande. Ces deux méthodes durant longtemps, elles ont toutes les deux besoins d'être asynchrones. Si ce sont les deux seules méthodes de la classe, il est alors judicieux que ce soit la classe elle-même qui porte l'annotation @Asynchronous.

import javax.ejb.*;

@Stateless
@Asynchronous
public class ValiderCommande {
   
    public void envoyerMail(Commande commande, Client client) {
        // envoi un e-mail
    }

    public void imprimerCommande(Commande commande) {
        // imprime la commande
    }
}

Si par contre le bean ValiderCommande dispose d'autres méthodes qui doivent être appelées de façon synchrone, vous placez l'annotation @Asynchronous uniquement sur celles qui en ont besoin, comme envoyerMail() et imprimerCommande().

import javax.ejb.*;

@Stateless
public class ValiderCommande {
  
    @Asynchronous
    public void envoyerMail(Commande commande, Client client) {
        // envoi un e-mail
    }
    @Asynchronous
    public void imprimerCommande(Commande commande) {
        // imprime la commande
    }
    ... // Autres méthodes (synchrones)
} 

1. Lorsqu'un client appelle imprimerCommande(), ou envoyerMail(), le conteneur lui redonne immédiatement le contrôle et continue le traitement de cet appel dans un thread séparé.
2. Comme vous pouvez le constater, le type de résultat de ces deux méthodes est void, mais une méthode asynchrone peut également renvoyer un objet de type java.util.concurrent.Future<V>, où V représente la valeur du résultat.
3. Je rappelle que les objets Future permettent d'obtenir le résultat d'une méthode qui s'exécute dans un thread distinct : le client peut alors utiliser l'API de Future pour obtenir ce résultat ou annuler l'appel.

public interface Future<Value> {
   Value get() throws ...;
   Value get(long durée, TimeUnit unitéDeTemps) throws ...;
   boolean cancel(Boolean peutÊtreInterrompu);
   boolean isCancelled();
   boolean isDone();
}

1. get(...) : Un appel à la première méthode get() bloque jusqu'à ce que le calcul soit terminé. La deuxième méthode déclenche une TimeoutException si l'appel est arrivé à expiration avant la fin du calcul. Si le thread exécutant le calcul est interrompu, les deux méthodes déclenchent une InterruptedException. Si le calcul est terminé, get() prend fin immédiatement.
2. isDone() : Cette méthode renvoie false si le calcul se poursuit, true s'il est terminé.
3. cancel() : Vous pouvez annuler le calcul avec cette méthode. Si le calcul n'a pas commencé, il est annulé et ne commencera jamais. Si le calcul est en cours, il est interrompu lorsque le paramètre peutÊtreInterrompu vaut true.

La classe javax.ejb.AsyncResult<V> est une implémentation fournie en standard de l'interface Future<V> qui propose notamment un constructeur qui attend la valeur de type V en paramètre.

La méthode wasCancelCancelled() de l'interface SessionContext renvoie true si le client a invoqué la méthode Future.cancel() avec la valeur true en paramètre.
.

L'exemple ci-dessous, côté serveur, effectue un traitement qui peut être interrompu par le client. La méthode historique() renvoie un String qui donne la liste des calculs effectués. Elle renvoie la liste complète si tout s'est déroulé correctement ou une partie de liste si une annulation est évoquée entre temps :

@Singleton
@Lock(LockType.READ)
public class Conversion implements ConversionRemote {
    private final double TAUX = 6.55957;
    private List<Calcul> stockage = new ArrayList<Calcul>();
    
    @Resource(name = "nomFichier")
    private String nomFichier;
    @Resource 
    SessionContext ctx;
...
    @Override
    @Asynchronous
    public Future<String> historique() {
        String motif = "{0, date, full} : {1, number, currency} <=> {2, number, #,##0.00 F}\n";
        StringBuilder résultat = new StringBuilder();
        for (int i=0; i<stockage.size() && !ctx.wasCancelCalled(); i++) {
            Calcul calcul = stockage.get(i);
            résultat.append(MessageFormat.format(motif, calcul.getInstant(), calcul.getEuro(), calcul.getFranc()));
        } 
        return new AsyncResult<String>(résultat.toString());
    }
...
}

Le client peut alors faire appel à cette méthode asynchrone historique(). Ensuite, dans un thread séparé, et à l'aide de la méthode blocante get() de Future, nous attendons le résultat de cet appel. Entre temps, il est possible d'écourter le traitement proposée par la méthode asynchrone historique() au moyen de la méthode cancel() de Future :

public class Client extends JFrame {
   private JTextArea historique = new JTextArea(10, 30);
   private JButton appel = new JButton("Historique");
   private JButton annuler = new JButton("Annuler");
...
   @EJB
   private static ConversionRemote convertir;
   private Future<String> calculs;

   public Client() {
      super("Conversion à distance");
...
      appel.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                calculs = convertir.historique();  // lance la méthode asynchrone 
                new Thread(new Runnable() {
                    @Override
                    public void run() {
                        try { historique.setText(calculs.get()); } catch (Exception ex) {}  // récupère la valeur de la méthode asynchrone dans un thread séparé
                    }
                }).start();
            }
        });
      annuler.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                calculs.cancel(true);  // Il est possible côté client de proposer une annulation qui est pris en compte par la méthode asynchrone
            }
        });
...
   }  
   public static void main(String[] args)  {  new Client();  }
}

Calcul.java

package session;

import java.io.Serializable;
import java.util.Date;

public class Calcul implements Serializable {
    private Date instant;
    private double euro;
    private double franc;

    public Calcul(double euro, double franc) {
        instant = new Date();
        this.euro = euro;
        this.franc = franc;
    }

    public double getEuro() { return euro;  }
    public double getFranc() { return franc;  }
    public Date getInstant() { return instant;  }
}

Nous retrouvons notre classe qui sert d'élément unitaire de stockage pour l'historique, avec une petite nouveauté toutefois par rapport au projet précédent, c'est que cette classe peut être enregistrée directement dans un fichier grâce à l'implémentation de la sérialisation.

ConversionRemote.java

package session;

import java.util.concurrent.Future;
import javax.ejb.Remote;

@Remote
public interface ConversionRemote {
    double francEuro(double franc);
    double euroFranc(double euro);
    void effacer();
    Future<String> historique();
}

Puisque notre accès se fait à distance dans le réseau local de l'entreprise, nous devons implémenter une interface métier qui va nous préciser les méthodes accessibles depuis l'application cliente fenêtrée. Mise à part les types de retour, nous retrouvons les mêmes fonctionnalités que le projet précédent.

ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar>
    <enterprise-beans>
       <session>
           <ejb-name>Conversion</ejb-name>
           <env-entry>
               <env-entry-name>nomFichier</env-entry-name>
               <env-entry-type>java.lang.String</env-entry-type>
               <env-entry-value>F:/Archivage/Historique.sto</env-entry-value>
           </env-entry>
        </session>
    </enterprise-beans>
</ejb-jar>

Plutôt que de coder en dur le nom du fichier dans le bean Singleton avec son emplacement dans le système de fichiers, il est souhaitable de proposer un fichier de configuration qui nous permettra par la suite de changer plus facilement le nom de ce fichier, sans avoir besoin de recompiler l'ensemble du module EJB. Il suffira d'effectuer un simple redéploiement.

Conversion.java

package session;

import java.io.*;
import java.text.MessageFormat;
import java.util.*;
import java.util.concurrent.Future;
import javax.annotation.Resource;
import javax.ejb.*;

@Singleton
@Lock(LockType.READ)
public class Conversion implements ConversionRemote {
    private final double TAUX = 6.55957;
    private List<Calcul> stockage = new ArrayList<Calcul>();
    
    @Resource(name = "nomFichier")
    private String nomFichier;
    @Resource 
    SessionContext ctx;

    @Override
    public double francEuro(double franc) {
        double euro = franc / TAUX;
        enregistrer(euro, franc);
        return euro;
    }

    @Override
    public double euroFranc(double euro) {
        double franc = euro * TAUX;
        enregistrer(euro, franc);
        return franc;
    }

    @Override
    @Asynchronous
    public void effacer() { 
        stockage.clear(); 
        enregistrer();
    }
    
    @Override
    @Asynchronous
    public Future<String> historique() {
        String motif = "{0, date, full} : {1, number, currency} <=> {2, number, #,##0.00 F}\n";
        StringBuilder résultat = new StringBuilder();
        lire();
        for (int i=0; i<stockage.size() && !ctx.wasCancelCalled(); i++) {
            Calcul calcul = stockage.get(i);
            résultat.append(MessageFormat.format(motif, calcul.getInstant(), calcul.getEuro(), calcul.getFranc()));
            try  { Thread.sleep(1000); } catch (InterruptedException ex) {}  // ligne inutile mais qui permet de valider les concepts sur l'asynchronisme
        } 
        return new AsyncResult<String>(résultat.toString());
    }

    @Asynchronous
    private void enregistrer(double euro, double franc) {
        stockage.add(new Calcul(euro, franc));
        enregistrer();
    }  
    
    private void enregistrer() {
         try {
            ObjectOutputStream fichier = new ObjectOutputStream(new FileOutputStream(nomFichier));
            fichier.writeObject(stockage);
            fichier.close();
        }
        catch (IOException ex) {  }       
    }
   
    private void lire() {
         try {
            ObjectInputStream fichier = new ObjectInputStream(new FileInputStream(nomFichier));
            stockage = (List<Calcul>) fichier.readObject();
            fichier.close();
        }
        catch (Exception ex) {  }
    }
}

Passons maintenant dans le vif du sujet et analysons plus particulièrement ce code source :

1. Ce bean Singleton dispose d'un certain nombre d'attributs, de méthodes publiques et de méthodes privées. Toutes les méthodes sont accessibles immédiatement, sans blocage, pour tous les clients désirant obtenir la requête souhaitée. Elle sont toutes proposées dans des threads séparés grâce à l'annotation @Lock(LockType.READ).
2. Nous avons d'abord des attributs classiques avec la constante qui nous donne le taux de conversion et la liste qui mémorise l'ensemble des calculs réalisés.
3. Les deux attributs suivants utilisent l'injection de dépendance sur des ressources internes au serveur. D'une part le point d'entrée désigné nomFichier qui est décrit dans le fichier de configuration ejb-jar.xml. D'autre part, le contexte de l'environnement, plus particulièrement le conteneur d'EJB précisé par l'interface SessionContext, qui sera utile pour contrôler si l'utilisateur a fait une demande d'annulation lors de l'appel asynchrone sur la diffusion de la liste complète des calculs de conversion.
4. Nous avons également des méthodes privées qui seront utilisées par les méthodes publiques du même bean session Singleton. La première méthode privée est asynchrone et se nomme enregistrer(). Elle est systématiquement appelée par les méthodes euroFranc() et francEuro() qui elles sont synchrones. Cette approche est intéressante puisque lorsque l'utilisateur propose une demande de conversion, le bean Singleton lui donne le résultat le plus rapidement possible et par contre prend le temps d'enregistrer le nouveau calcul dans l'historique, et surtout prend le temps de stocker cette nouvelle liste dans le fichier correspondant, ce qui effectivement peut prendre un certain temps.
5. Deux autres méthodes sont asynchrones. Elles sont également publiques et donc accessibles directement par l'utilisateur. La première méthode effacer() permet de remettre à zéro l'historique avec son fichier correspondant. Vu qu'il n'y a pas de retour et grâce à l'appel asynchrone, nous avons le temps de réaliser ces opérations qui réclament tout de même un peu de temps machine.
6. La méthode historique() renvoie un résultat, qui vu qu'elle est asynchrone, est de type Future<String>. Du coup, le client dès qu'il fait appel à cette méthode reprend tout de suite la main, et il peut, au moyen de cette interface Futrure demander le résultat quand il le désire. Nous avons ainsi une deconnexion des traitements entre le serveur d'un côté et le client de l'autre. Chacun peut faire ses propres opérations sans se préoccuper de l'autre. C'est le rôle fondamental de l'appel asynchrone.
7. Le résultat envoyé par le serveur au moyen de cette méthode historique() est délivrée par la création d'un objet de type AsyncResult dont la classe a été spécialement créée dans le cadre de la technologie Java EE 6. En fait, AsyncResult est utilisée pour passer la valeur du résultat au conteneur au lieu de la passer directement à l'appelant.
8. Pour terminer sur cette méthode historique(), vous remarquez durant le parcours de l'itérative un test systématique pour savoir si le client a demandé ou non l'annulation de l'appel. Ce test se traduit par l'évocation de la méthode wasCancelCalled() de l'interface SessionContext. Je rappelle que c'est le conteneur qui garde en mémoire la demande d'annulation. C'est bien pour cela que nous devons interroger le conteneur au travers justement de cette interface SessionContext.

   J'ai rajouté une ligne totalement inutile qui met une pause de une seconde à chaque calcul élémentaire de l'itérative pour que nous ayons le temps, côté client, de demander la liste de l'historique et de pouvoir ensuite l'interrompre à tout moment. C'est juste un cas d'école vu que tout le traitement de cette méthode ne prend finalement que très peu de temps.

Client.java

package conversion;

import java.awt.*;
import java.awt.event.*;
import java.text.*;
import java.util.concurrent.*;
import javax.ejb.EJB;
import javax.swing.*;
import session.ConversionRemote;

public class Client extends JFrame {
   private JFormattedTextField euro = new JFormattedTextField(NumberFormat.getCurrencyInstance());
   private JFormattedTextField franc = new JFormattedTextField(new DecimalFormat("#,##0.00 F"));
   private JTextArea historique = new JTextArea(10, 30);
   private JPanel panneau = new JPanel();
   private JButton appel = new JButton("Historique");
   private JButton annuler = new JButton("Annuler");
   private JButton effacer = new JButton("Effacer");
   @EJB
   private static ConversionRemote convertir;
   private Future<String> calculs;

   public Client() {
      super("Conversion à distance");
      setLayout(new FlowLayout());
      euro.setColumns(30);
      euro.setHorizontalAlignment(JFormattedTextField.RIGHT);
      euro.setValue(0);
      add(euro);
      franc.setColumns(30);
      franc.setHorizontalAlignment(JFormattedTextField.RIGHT);
      franc.setValue(0);
      add(franc);
      add(new JScrollPane(historique));
      getContentPane().setBackground(Color.ORANGE);
      panneau.add(appel);
      panneau.add(annuler);
      panneau.add(effacer);
      add(panneau);
      euro.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                  Number valeur = (Number) euro.getValue();
                  franc.setValue(convertir.euroFranc(valeur.doubleValue()));          
            }
        });
      franc.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                  Number valeur = (Number) franc.getValue();
                  euro.setValue(convertir.francEuro(valeur.doubleValue()));                
            }
        });
      appel.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                calculs = convertir.historique();
                new Thread(new Runnable() {
                    @Override
                    public void run() {
                        try { historique.setText(calculs.get()); } catch (Exception ex) {}
                    }
                }).start();
            }
        });
      annuler.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                calculs.cancel(true);
            }
        });
      effacer.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                convertir.effacer();
                historique.setText("");
            }
        });
      getContentPane().setBackground(Color.orange);
      setSize(350, 300);
      setResizable(false);
      setDefaultCloseOperation(EXIT_ON_CLOSE);
      setVisible(true);
   }
   
   public static void main(String[] args)  {  new Client();  }
}

Bien qu'ils partagent le même cycle de vie, les beans sans état et singletons ne sont pas créés et détruits de la même façon :

1. Lorsqu'un bean session sans état est déployé, le conteneur en crée plusieurs instances et les place dans un pool. Quand un client appelle une méthode de ce bean, le conteneur choisit une instance dans le pool, lui délègue l'appel de méthode et la replace dans le pool. Lorsque le conteneur n'a plus besoin de l'instance (parce que, par exemple, il veut réduire le nombre d'instances du pool), il la supprime.

   GlassFish permet de paramétrer le pool des EJB. Vous pouvez ainsi fixer une taille (nombre initial, minimal et maximal de beans dans le pool), le nombre de beans à supprimer du pool lorsque son temps d'inactivité a expiré et le nombre de millisecondes du délai d'expiration du pool.

2. La création des beans singletons varie selon qu'ils ont été instanciés dès le démarrage (@Startup) ou non, ou qu'ils dépendent (@DependsOn) d'un autre singleton déjà créé : dans ce cas, uns instance sera créée au moment du déploiement ; sinon le conteneur créera l'instance lorsqu'un client appelera une méthode métier. Comme les singletons durent tout le temps de l'application, leur instance n'est détruite que lorsque le conteneur se termine.

1. La passivation consiste à sérialiser l'instance du bean sur un support de stockage permanent (fichier sur disque, base de données, etc.) au lieu de la maintenir en mémoire.
2. L'activation, qui est l'opération oposée, a lieu lorsque l'instance est redemandée par le client. Le conteneur désérialise alors le bean et le replace en mémoire.

Ceci signifie donc que les attributs du bean doivent être sérialisables (donc être d'un type primitif ou qui implémente l'interface java.io.Serializable).
.

Dans certains cas, un bean contient des ressources ouvertes comme des sockets ou des connexions de base de données. Un conteneur ne pouvant garder ces ressources ouvertes pour chaque bean, vous devez fermer et rouvrir ces ressources avant et après la passivation : c'est là que les méthodes de rappel interviennent.

void <nom-méthode>();

et respecter les règles suivantes :

1. Elle ne doit pas prendre de paramètres et doit renvoyer void.
2. Elle ne doit pas lancer d'exception contrôlée, mais elle peut déclencher une exception runtime : dans ce cas, si une transaction est en cours, celle-ci sera annulée.
3. Elle peut avoir un accès public, private, protected ou de niveau paquetage, mais ne peut être ni static ni final.
4. Elle peut être annotée par plusieurs annotations. Cependant, il ne peut y avoir qu'une seule annotation du même type dans le bean.
5. Elle peut accéder aux entrées d'environnement du bean (revoir la section sur le Contexte de nommage de l'environnement).

Conversion.java

package session;

import java.io.*;
import java.text.MessageFormat;
import java.util.*;
import java.util.concurrent.Future;
import javax.annotation.Resource;
import javax.ejb.*;

@Singleton
@Startup
@Lock(LockType.READ)
public class Conversion implements ConversionRemote {
    private final double TAUX = 6.55957;
    private List<Calcul> stockage = new ArrayList<Calcul>();
    
    @Resource(name = "nomFichier")
    private String nomFichier;
    @Resource 
    SessionContext ctx;

    @Override
    public double francEuro(double franc) {
        double euro = franc / TAUX;
        enregistrer(euro, franc);
        return euro;
    }

    @Override
    public double euroFranc(double euro) {
        double franc = euro * TAUX;
        enregistrer(euro, franc);
        return franc;
    }

    @Override
    @Asynchronous
    public void effacer() { 
        stockage.clear(); 
    }
    
    @Override
    @Asynchronous
    public Future<String> historique() {
        String motif = "{0, date, full} : {1, number, currency} <=> {2, number, #,##0.00 F}\n";
        StringBuilder résultat = new StringBuilder();
        for (int i=0; i<stockage.size() && !ctx.wasCancelCalled(); i++) {
            Calcul calcul = stockage.get(i);
            résultat.append(MessageFormat.format(motif, calcul.getInstant(), calcul.getEuro(), calcul.getFranc()));
        } 
        return new AsyncResult<String>(résultat.toString());
    }

    @Asynchronous
    private void enregistrer(double euro, double franc) {
        stockage.add(new Calcul(euro, franc));
    }  
    
    @PreDestroy
    private void enregistrer() {
         try {
            ObjectOutputStream fichier = new ObjectOutputStream(new FileOutputStream(nomFichier));
            fichier.writeObject(stockage);
            fichier.close();
        }
        catch (IOException ex) {  }       
    }
   
    @PostConstruct
    private void lire() {
         try {
            ObjectInputStream fichier = new ObjectInputStream(new FileInputStream(nomFichier));
            stockage = (List<Calcul>) fichier.readObject();
            fichier.close();
        }
        catch (Exception ex) {  }
    }
}

Il faut également penser à rajouter l'annotation @Startup sur le bean lui-même pour que ce dernier soit opérationnel dès le départ et qu'il récupère les enregistrements de tous les calculs déjà effectués.

Conversion.java

package session;

import java.io.*;
import java.text.MessageFormat;
import java.util.*;
import java.util.concurrent.Future;
import javax.annotation.Resource;
import javax.ejb.*;

@Stateful
public class Conversion implements ConversionRemote {
    private List<Calcul> stockage = new ArrayList<Calcul>();
...
    @PreDestroy
    @PrePassivate
    private void enregistrer() {
         try {
            ObjectOutputStream fichier = new ObjectOutputStream(new FileOutputStream(nomFichier));
            fichier.writeObject(stockage);
            fichier.close();
        }
        catch (IOException ex) {  }       
    }
   
    @PostConstruct
    @PostActivate
    private void lire() {
         try {
            ObjectInputStream fichier = new ObjectInputStream(new FileInputStream(nomFichier));
            stockage = (List<Calcul>) fichier.readObject();
            fichier.close();
        }
        catch (Exception ex) {  }
    }

    @Remove
    public void interrompre() {  }
}

Nous rajoutons simplement les annotations @PostActivate et @PrePassivate sur les mêmes méthodes lire() et enregistrer() et nous rajontons une méthode vide interrompre() précédée cette fois-ci de l'annotation @Remove. Cette dernière doit alors être explicitement appelée par le client pour bien spécifier que le bean session ne lui est plus utile. Auquel cas, le conteneur détruira cet objet attitré au client, en passant au préalable par la phase de @PreDestroy qui correspond à l'enregistrement du fichier.

En toute rigueur, ce code n'est pas du tout adapté à ce genre de situation. Il s'agit juste d'un cas d'école. Il faudrait plutôt mettre en place un système de consignation pour chaque client avec donc un fichier journal séparé pour chaque client, ce qui, vous vous en doutez, provoquerez une saturation rapide des ressources matérielles.

Remarquez, par contre, que l'application cliente ne gère absolument pas les appels de méthodes automatiques @PostConstruct et @PreDestroy. C'est le conteneur d'EJB qui le gère tout seul, sans avoir besoin de nous en préoccuper par la suite.

En fait, vous pouvez considérer qu'un conteneur d'EJB est lui-même une chaînes d'intercepteurs : lorsque vous développez un bean session, vous vous concentrez sur le code métier mais, en coulisse, le conteneur intercepte les appels de méthodes effectués par le client et applique différents services (gestion du cycle de vie, transactions, sécurités, etc.). Grâce aux intercepteurs, vous pouvez ajouter vos propres traitements transverses et les appliquer au code métier de façon transparente.

Il existe trois types d'intercepteurs :

1. intercepteurs autour des appels ;
2. intercepteurs des méthodes métiers ;
3. intercepteurs des méthodes de rappel du cycle de vie.

@AroundInvoke
public Object nomDeMéthode(InvocationContext ctx) throw Exception {
...
}

Une méthode intercepteur autour des appels doit respecter également les règles suivantes :

1. Elle peut être publique, privée, protégée ou avoir un accès paquetage, mais ne peut pas être statique ou définitive (final).
2. Elle doit avoir un paramètre javax.interceptor.InvocationContext et renvoyer un Object, qui est le résultat de l'appel de la méthode cible (si cette méthode renvoie void, cet objet vaudra null).
3. Elle peut lever une exception contrôlée.

L'objet représentant InvocationContext permet aux intercepteurs de contrôler le comportement de la chaîne des appels. Lorsque plusieurs intercepteurs sont chaînés, c'est la même instance d'InvocationContext qui est passé à chacun d'eux, ce qui peut impliquer un traitement de ces données contextuelles par les autres intercepteurs.

InvocationContext est en réalité une interface dont voici la signature :

package javax.ejb;

public interface InvocationContext {
    public Object getTarget();
    public java.lang.reflect.Method getMethod();
    public Object[] getParameters();
    public void setParameters(Object[] params);
    public EJBContext getEJBContext();
    public java.util.Map<String, Object> getContextData();
    public Object proceed() throw Exception;
}
    

1. getContextData() : Permet de passer des valeurs entre les méthodes intercepteurs dans la même instance d'InvocationContext à l'aide d'une Map.
2. getMethod() : Retourne la méthode qui est appelée par le client, pour laquelle l'intercepteur a été invoqué.
3. getParameters() : Retourne les paramètres qui seront utilisées pour invoquer la méthode métier appelée par le client.
4. getEJBContext() : Retourne les méthodes d'interception du bean (callback interceptor).
5. getTarget() : Retourne l'objet correspondant au bean qui lance la méthode sollicitée par le client.
6. getTimer() : Renvoie le timer associé à une méthode @Timeout.
7. proceed() : Lance l'intercepteur suivant s'il existe ou lance tout simplement la méthode d'appel souhaitée par le client. Cette méthode doit systématiquement être utilisée si nous désirons que la méthode appelée par le client soit effectivement lancée. Elle renvoie également le résultat de la méthode suivante. Si une méthode est de type void, proceed() renvoie null.
8. setParameters() : Modifie la valeur des paramètres utilisés pour l'appel de la méthode cible. Si les types et le nombre de paramètres ne correspondent pas à la siganture de la méthode, l'exception IllegalArgumentException est levée.

A titre d'exemple, reprenons le projet sur l'archivage :

Sur le bean session stateful Archive nous rajoutons une méthode gestionDesAppelsDeMéthode() qui va contrôler l'ordre des appels des différentes méthodes utilisées pour le transfert des blocs d'octets. Il faut effectivement vérifier que la méthode sauvegarde() est bien appelée avant de faire référence à la méthode envoiOctets(). De la même façon, nous vérifions l'ordre entre la méthode restituer() et la méthode recupereOctets(). Si l'ordre d'appels n'est pas respecté une exception est alors lancée pour que le client soit bien prévenu que l'utilisation du bean session est mal exploité.

session.Archive.java

package session;

import java.io.*;
import javax.annotation.Resource;
import javax.ejb.*;
import javax.interceptor.*;

@Stateful
@StatefulTimeout(20000)  // délai d'expiration
public class Archive implements ArchiveRemote {
   @Resource(name="repertoire")
   private String répertoire;
   @Resource(name="buffer")
   private int BUFFER;
   private String nomFichier;
   private BufferedOutputStream enregistrement;
   private BufferedInputStream lecture;
   private int taille;
   private int nombre;
   private boolean sauvegarder, récupérer;

   @Override
   public int getBuffer() { return BUFFER; }

   @Override
   public String[] listeNomFichier() { return new File(répertoire).list(); }

   @Override
   public void suppression(String nomFichier) {  new File(répertoire+nomFichier).delete();  }

   @Override
   public int sauvegarde(String nomFichier, int taille)  throws IOException {
       this.nomFichier = nomFichier;
       enregistrement = new BufferedOutputStream(new FileOutputStream(répertoire + nomFichier));
       this.taille = taille;
       return nombre = this.taille / BUFFER;
   }

   @Override
   public void envoiOctets(byte[] octets) throws IOException {
      enregistrement.write(octets);
      nombre--;
      if (nombre<0) { enregistrement.close(); sauvegarder = false; }
   }

   @Override
    public int restituer(String nomFichier) throws IOException {
        lecture = new BufferedInputStream(new FileInputStream(répertoire+nomFichier));
        return lecture.available();
   }

   @Override
   public byte[] recupereOctets() throws IOException {
      byte[] octets = lecture.available() >= BUFFER ? new byte[BUFFER] : new byte[lecture.available()];
      lecture.read(octets);
      if (lecture.available() <= 0) { lecture.close(); récupérer = false; }
      return octets;
   }

   @Remove   // expiration du bean session à l'issu de l'exécution de cette méthode
   public void annuler() throws IOException {
      lecture.close();
      enregistrement.close();
   }

   @AroundInvoke  // Intercepteur autour des appels de méthode
   public Object gestionDesAppelsDeMéthode(InvocationContext ctx) throws Exception {
      String nomMéthode = ctx.getMethod().getName();
      if (nomMéthode.equals("sauvegarde")) sauvegarder = true;
      if (nomMéthode.equals("envoiOctets") && !sauvegarder) 
          throw new Exception("Il faut d'abord faire une demande de sauvegarde avant d'envoyer la suite d'octets");
      if (nomMéthode.equals("restituer")) récupérer = true;
      if (nomMéthode.equals("recupereOctets") && !récupérer)
          throw new Exception("Il faut d'abord faire une demande de restitution avant de récupérer la suite d'octets");
      return ctx.proceed();
   }
}    

ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee" 
         version = "3.1"
         xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
    <enterprise-beans>
       <session>
           <ejb-name>Archive</ejb-name>
           <env-entry>
               <env-entry-name>repertoire</env-entry-name>
               <env-entry-type>java.lang.String</env-entry-type>
               <env-entry-value>F:/Archivage/</env-entry-value>
           </env-entry>
           <env-entry>
               <env-entry-name>buffer</env-entry-name>
               <env-entry-type>java.lang.Integer</env-entry-type>
               <env-entry-value>4096</env-entry-value>
           </env-entry>         
        </session>
    </enterprise-beans>
</ejb-jar>    

Maintenant, lorsque le client effectue un appel sur la méthode qu'il désire, c'est d'abord la méthode gestionDesAppelsDeMéthode() qui est appelée. Ensuite, grâce à la méthode proceed(), la méthode souhaitée par le client est effectivement exécutée, à moins qu'une exception soit lancée, bien entendu.

Décrivons plus précisément l'ordre des différentes exécutions pour examiner ce qui se passe lorsqu'un client invoque la méthode sauvegarde() par exemple :

1. Tout d'abord, le conteneur intercepte cet appel et, au lieu d'exécuter directement sauvegarde(), appelle la méthode gestionDesAppelsDeMéthode().
2. Celle-ci utilise l'interface InvocationContext pour obtenir le nom de la méthode appelée.
3. Après reconnaissance de la méthode, la variable sauvegarder passe à true.
4. A la fin de la méthode gestionDesAppelsDeMéthode(), nous devons impérativement appeler la méthode InvocationContext.proceed() pour passer à l'intercepteur suivant ou appeler la méthode métier du bean, savoir sauvegarde().

   Cet appel est très important car, sans lui, la chaîne des intercepteurs serait rompue et la méthode métier ne serait plus du tout appelée.
   .
   

5. Ensuite, la méthode sauvegarde() est finalement exécutée.
6. Lorsqu'elle se termine, l'intercepteur termine également son exécution sans rien faire de spécial.

   Nous aurions pu rajouté quelques fonctionnalités supplémentaires.
   .

Le code suivant isole la méthode appels() dans une classe à part, Journal, qui est un simple POJO disposant d'une méthode annotée par @AroundInvoke
.

session.Journal.java

package session;

import java.util.logging.*;
import javax.interceptor.*;

public class Journal {
    private Logger consignation = Logger.getLogger("appels");

    public Journal() {
        consignation.setLevel(Level.FINER);
        consignation.setUseParentHandlers(false);
        Handler console = new ConsoleHandler();
        console.setLevel(Level.FINER);
        consignation.addHandler(console);
    }

    @AroundInvoke
    public Object appels(InvocationContext ctx) throws Exception {
        consignation.entering(ctx.getTarget().toString(),  ctx.getMethod().toString());
        try {
            return ctx.proceed();
        }
        finally {
            consignation.exiting(ctx.getTarget().toString(), ctx.getMethod().toString());
        }
    }
}

Journal peut maintenant être utilisée de façon transparente par n'importe quel EJB souhaitant disposer d'un intercepteur. Pour ce faire, le bean doit informer le conteneur avec l'annotation @javax.interceptor.Interceptors :

session.Conversion.java

package session;

import java.io.*;
import java.text.MessageFormat;
import java.util.*;
import java.util.concurrent.Future;
import javax.annotation.Resource;
import javax.ejb.*;

@Singleton
@Startup
@Lock(LockType.READ)
public class Conversion implements ConversionRemote {
    private final double TAUX = 6.55957;
    private List<Calcul> stockage = new ArrayList<Calcul>();
    
    @Resource(name = "nomFichier")
    private String nomFichier;
    @Resource 
    SessionContext ctx;

    @Override
    @Interceptors(Journal.class)
    public double francEuro(double franc) {
        double euro = franc / TAUX;
        enregistrer(euro, franc);
        return euro;
    }

    @Override
    @Interceptors(Journal.class)
    public double euroFranc(double euro) {
        double franc = euro * TAUX;
        enregistrer(euro, franc);
        return franc;
    }

    @Override
    @Asynchronous
    public void effacer() { 
        stockage.clear(); 
    }
    
    @Override
    @Asynchronous
    public Future<String> historique() {
        String motif = "{0, date, full} : {1, number, currency} <=> {2, number, #,##0.00 F}\n";
        StringBuilder résultat = new StringBuilder();
        for (int i=0; i<stockage.size() && !ctx.wasCancelCalled(); i++) {
            Calcul calcul = stockage.get(i);
            résultat.append(MessageFormat.format(motif, calcul.getInstant(), calcul.getEuro(), calcul.getFranc()));
        } 
        return new AsyncResult<String>(résultat.toString());
    }

    @Asynchronous
    private void enregistrer(double euro, double franc) {
        stockage.add(new Calcul(euro, franc));
    }  
    
    @PreDestroy
    private void enregistrer() {
         try {
            ObjectOutputStream fichier = new ObjectOutputStream(new FileOutputStream(nomFichier));
            fichier.writeObject(stockage);
            fichier.close();
        }
        catch (IOException ex) {  }       
    }
   
    @PostConstruct
    private void lire() {
         try {
            ObjectInputStream fichier = new ObjectInputStream(new FileInputStream(nomFichier));
            stockage = (List<Calcul>) fichier.readObject();
            fichier.close();
        }
        catch (Exception ex) {  }
    }
}

Maintenant, dans ce bean Conversion, cette annoation est placée sur les méthodes francEuro() et euroFranc(), ce qui signifie que tous les appels sur ces méthodes spécifiques seront interceptées par le conteneur qui invoquera la classe Journal pour consigner les entrées et les sorties.

Si vous désirez que toutes les méthodes soient interceptées, vous placez l'annotation sur le bean lui-même :

session.Conversion.java

@Singleton
@Startup
@Lock(LockType.READ)
@Interceptors(Journal.class)
public class Conversion implements ConversionRemote {
...
    public double francEuro(double franc) { ... }
    public double euroFranc(double euro) { ... }
    public void effacer() { ...  }
    public Future<String> historique() { ...  }
    private void enregistrer(double euro, double franc) { ... }  
    private void enregistrer() { ... }
    private void lire() { ... }
}

Si vous désirez que toutes les méthodes, sauf quelques unes, soient interceptées, utilisez l'annotation javax.interceptor.ExcludeClassInterceptors pour exclure les méthodes concernées :

session.Conversion.java

@Singleton
@Startup
@Lock(LockType.READ)
@Interceptors(Journal.class)
public class Conversion implements ConversionRemote {
...
    public double francEuro(double franc) { ... }
    public double euroFranc(double euro) { ... }
    @ExcludeClassInterceptors
    public void effacer() { ...  }
    public Future<String> historique() { ...  }
    private void enregistrer(double euro, double franc) { ... }  
    private void enregistrer() { ... }
    private void lire() { ... }
}

Dans ce code, l'appel à effacer() ne sera pas intercepté alors que les appels à toutes les autres méthodes publiques le seront.
.

Par exemple, la classe CycleVie proposent deux méthodes : début(), qui sera appelée après la construction d'une instance et fin(), qui sera invoquée avant la destruction de la classe.

session.CycleVie.java

package session;

import java.util.logging.*;
import javax.annotation.*;
import javax.interceptor.InvocationContext;

public class CycleVie {
    private Logger consignation = Logger.getLogger("appels");

    public CycleVie() {
        consignation.setLevel(Level.FINER);
        consignation.setUseParentHandlers(false);
        Handler console = new ConsoleHandler();
        console.setLevel(Level.FINER);
        consignation.addHandler(console);
    }

    @PostConstruct
    public void début(InvocationContext ctx) {  
        try {
            consignation.info("Création de "+ctx.getTarget().getClass().getName());
            ctx.proceed();
        }
        catch(Exception ex) { Logger.global.info("Problème avec CycleVie.class"); }
    }

    @PreDestroy
    public void fin(InvocationContext ctx) {
        try {
            ctx.proceed();
            consignation.info("Demande de destruction de "+ctx.getTarget().getClass().getName()+" par le conteneur");
        }
        catch(Exception ex) { Logger.global.info("Problème avec CycleVie.class"); }
    }
}

Comme vous pouvez le constater dans ce code, les méthodes intercepteurs du cycle de vie prennent en paramètre un objet InvocationContext, renvoient un void au lieu d'Object (car, comme nous l'avons expliqué antérieurement, les méthodes de rappel du cycle de vie renvoient systématiquement un void) et ne peuvent pas lancer d'exception contrôlées.

Pour appliquer l'intercepteur précédent, le bean session doit utiliser l'annotation @Interceptors. Dans le code source suivant, Conversion précise qu'il s'agit de la classe CycleVie.

session.Conversion.java

...
@Singleton
@Lock(LockType.READ)
@Interceptors(CycleVie.class)
public class Conversion implements ConversionRemote {
...
    @Override
    public double francEuro(double franc) {
        double euro = franc / TAUX;
        enregistrer(euro, franc);
        return euro;
    }

    @Override
    public double euroFranc(double euro) {
        double franc = euro * TAUX;
        enregistrer(euro, franc);
        return franc;
    }
    
    @PreDestroy
    private void enregistrer() {
         try {
            ObjectOutputStream fichier = new ObjectOutputStream(new FileOutputStream(nomFichier));
            fichier.writeObject(stockage);
            fichier.close();
        }
        catch (IOException ex) {  }       
    }
   
    @PostConstruct
    private void lire() {
         try {
            ObjectInputStream fichier = new ObjectInputStream(new FileInputStream(nomFichier));
            stockage = (List<Calcul>) fichier.readObject();
            fichier.close();
        }
        catch (Exception ex) {  }
    }
}

Dès lors, quand l'EJB sera instancié par le conteneur, la méthode début() de l'intercepteur sera invoquée avant la méthode lire(). Les appels aux méthodes francEuro() et euroFranc() ne seront en revanche pas interceptés, mais la méthode enregistrer() de l'intercepteur sera appelée avant que l'instance de Conversion ne soit détruite par le conteneur.

Les méthodes de rappel de cycle de vie et les méthodes @AroundInvoke peuvent être définies dans la même classe.
.

session.Conversion.java

@Singleton
@Lock(LockType.READ)
@Interceptors({Intercepteur1.class, Intercepteur2.class})
public class Conversion implements ConversionRemote {
...
    @Interceptors({Intercepteur3.class, Intercepteur4.class})
    public double francEuro(double franc) { ... }
    public double euroFranc(double euro) { ... }
    @ExcludeClassInterceptors
    public void effacer() { ...  }
    public Future<String> historique() { ...  }
    private void enregistrer(double euro, double franc) { ... }  
    private void enregistrer() { ... }
    private void lire() { ... }
}

1. Aucun intercepteur ne sera invoqué lorsqu'un client appelle la méthode effacer() (car elle est annotée par @ExcludeClassInterceptors).
2. Lorsque historique() est appelée, l'intercepteur Intercepteur1 s'exécutera suivi de l'intercepteur Intercepteur2.
3. Lorsque euroFranc() est appelée, les intercepteurs Intercepteur1, Intercepteur2, Intercepteur3 et Intercepteur4 seront exécutés dans cet ordre.

A titre d'exemple, nous pouvons reprendre l'étude sur le bean Conversion en proposant les deux intercepteurs mise en oeuvre précédemments, savoir Journal et CycleVie :

session.Conversion.java

@Singleton
@Lock(LockType.READ)
@Interceptors({CycleVie.class, Journal.class})
public class Conversion implements ConversionRemote {
...
}

ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee" 
         version = "3.1"
         xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
    <assembly-descriptor>
       <interceptor-binding>
           <ejb-name>*</ejb-name>
           <interceptor-class>session.Journal</interceptor-class>      
        </interceptor-binding>
    </assembly-descriptor>
</ejb-jar>    

Le caractère joker * dans l'élément <ejb-name> signifie que tous les EJB appliqueront l'intercepteur défini dans l'élément <interceptor-class>. Si vous déployez le bean Conversion avec cet intercepteur par défaut, le Journal sera invoqué avant tous les autres intercepteurs.

Si plusieurs types d'intercepteurs sont définis pour un même bean session, le conteneur les applique dans l'ordre décroissant des portées : le premier sera donc l'intercepteur par défaut et le dernier l'intercepteur de méthode.

Pour désactiver les intercepteurs par défaut pour un EJB spécifique, il suffit d'appliquer l'annotation @javax.interceptor.ExcludeDefaultInterceptors sur la classe ou sur les méthodes :

session.Conversion.java

@Singleton
@Lock(LockType.READ)
@ExcludeDefaultInterceptors @Interceptors(CycleVie.class)
public class Conversion implements ConversionRemote {
...
    public double francEuro(double franc) { ... }
    public double euroFranc(double euro) { ... }
    @ExcludeClassInterceptors
    public void effacer() { ...  }
    public Future<String> historique() { ...  }
    private void enregistrer(double euro, double franc) { ... }  
    private void enregistrer() { ... }
    private void lire() { ... }
}