TOC

Java EE Session Beans

Java EE Session Beans

1. introduction

Enterprise Session Beans peut être classé dans les catégories suivantes:

  1. Beans Session sans état

  2. Beans Stateful Session

Dans cet article rapide, nous allons discuter de ces deux principaux types de beans de session.

2. Installer

Pour utiliser Enterprise Beans 3.2,, assurez-vous d'ajouter la dernière version à la sectiondependencies du fichierpom.xml: 


    javax
    javaee-api
    7.0
    provided

La dernière dépendance peut être trouvée dans lesMaven Repository. Cette dépendance garantit que toutes les API Java EE 7 sont disponibles pendant la compilation. La portée deprovided garantit qu'une fois déployée; la dépendance sera fournie par le conteneur où elle a été déployée.

3. Haricots apatrides

Un bean session sans état est un type de bean entreprise qui est couramment utilisé pour effectuer des opérations indépendantes. Il n'a pas d'état client associé, mais il peut conserver son état d'instance.

Jetons un coup d'œil à un exemple pour montrer comment fonctionne un bean sans état.

3.1 Creating the Stateless Bean

Commençons par créer le beanStatelessEJB. Nous utilisons l'annotation@Stateless pour marquer le bean comme sans état: 

@Stateless
public class StatelessEJB {

    public String name;

}

Ensuite, nous créons le premier client du bean sans état ci-dessus, appeléEJBClient1: 

public class EJBClient1 {

    @EJB
    public StatelessEJB statelessEJB;

}

Nous déclarons ensuite un autre client, nomméEJBClient2, qui accède au même bean sans état: 

public class EJBClient2 {

    @EJB
    public StatelessEJB statelessEJB;

}

3.2 Testing the Stateless Bean

Pour tester l’apatridie de l’EJB, nous pouvons utiliser les deux clients déclarés ci-dessus de la manière suivante: 

@RunWith(Arquillian.class)
public class StatelessEJBTest {

    @Inject
    private EJBClient1 ejbClient1;

    @Inject
    private EJBClient2 ejbClient2;

    @Test
    public void givenOneStatelessBean_whenStateIsSetInOneBean
      _secondBeanShouldHaveSameState() {

        ejbClient1.statelessEJB.name = "Client 1";
        assertEquals("Client 1", ejbClient1.statelessEJB.name);
        assertEquals("Client 1", ejbClient2.statelessEJB.name);
    }

    @Test
    public void givenOneStatelessBean_whenStateIsSetInBothBeans
      _secondBeanShouldHaveSecondBeanState() {

        ejbClient1.statelessEJB.name = "Client 1";
        ejbClient2.statelessEJB.name = "Client 2";
        assertEquals("Client 2", ejbClient2.statelessEJB.name);
    }

    // Arquillian setup code removed for brevity

}

Nous commençons par injecter les deux clients EBJ dans le test unitaire.

Ensuite, dans la première méthode de test, nous définissons la variablename dans l'EJB qui a été injectée dansEJBClient1 à la valeurClient 1. Maintenant, lorsque nous comparons la valeur dename variable dans les deux clients, nous devrions voir que la valeur est égale. This shows that state is not preserved in stateless beans.

Montrons que c’est vrai d’une manière différente. Dans la deuxième méthode de test, nous voyons qu'une fois que nous avons défini la variablename dans le deuxième client, elle «écrase» la valeur qui lui a été donnée viaejbClient1.

4. Stateful Beans

Les beans de session avec état maintiennent l’état dans et entre les transactions. C'est pourquoi chaque bean session avec état est associé à un client spécifique. Les conteneurs peuvent enregistrer et récupérer automatiquement l'état d'un bean lors de la gestion de pools d'instances de beans de session avec état.

4.1 Creating the Stateful Bean

Un bean session avec état est marqué de l'annotation@Stateful. Le code pour le bean stateful est le suivant: 

@Stateful
public class StatefulEJB {

    public String name;

}

Le premier client local pour notre bean stateful s’écrit comme suit: 

public class EJBClient1 {

    @EJB
    public StatefulEJB statefulEJB;

}

Un deuxième client appeléEJBClient2 est également créé tout comme leEJBClient1: 

public class EJBClient2 {

    @EJB
    public StatefulEJB statefulEJB;

}

4.2 Testing the Stateful Bean

La fonctionnalité du bean avec état est testée dans le test unitaireEJBStatefulBeanTest de la manière suivante: 

@RunWith(Arquillian.class)
public class StatefulEJBTest {

    @Inject
    private EJBClient1 ejbClient1;

    @Inject
    private EJBClient2 ejbClient2;

    @Test
    public void givenOneStatefulBean_whenTwoClientsSetValueOnBean
      _thenClientStateIsMaintained() {

        ejbClient1.statefulEJB.name = "Client 1";
        ejbClient2.statefulEJB.name = "Client 2";
        assertNotEquals(ejbClient1.statefulEJB.name, ejbClient2.statefulEJB.name);
        assertEquals("Client 1", ejbClient1.statefulEJB.name);
        assertEquals("Client 2", ejbClient2.statefulEJB.name);
    }

    // Arquillian setup code removed for brevity

}

Comme auparavant, les deux clients EJB sont injectés dans le test unitaire. Dans la méthode de test, nous pouvons voir que la valeur de la variablename est définie via le clientejbClient1 et est maintenue même si la valeur dename est définie via leejbClient2 est différent. This demonstrates that the state of the EJB is maintained.

5. Apatride vs. Bean session avec état

Voyons maintenant la différence majeure entre les deux types de session beans.

5.1 Stateless Beans

  • Les beans session sans état ne conservent aucun état avec le client. Pour cette raison, ils peuvent être utilisés pour créer un pool d'objets qui interagissent avec plusieurs clients.

  • Étant donné que les beans sans état n'ont aucun état par client, ils sont meilleurs en termes de performances

  • Ils peuvent traiter plusieurs demandes de plusieurs clients en parallèle et

  • Peut être utilisé pour récupérer des objets à partir de bases de données

5.2 Stateful Beans

  • Les beans session avec état peuvent conserver l'état avec plusieurs clients et la tâche n'est pas partagée entre les clients

  • L'état dure pour la durée de la session. Après la destruction de la session, l'état n'est pas conservé

  • Le conteneur peut sérialiser et stocker l'état en tant qu'état obsolète pour une utilisation ultérieure. Ceci est fait pour économiser les ressources du serveur d'applications et pour supporter les échecs de bean.

  • Peut être utilisé pour résoudre des problèmes de type producteur-consommateur

6. Conclusion

Nous avons donc créé deux types de beans de session et les clients correspondants pour appeler les méthodes à partir des beans. Le projet montre le comportement des deux principaux types de beans de session.

Comme toujours, le codesource de l'article est disponible sur GitHub.

Related