TOC

Guide de configuration des EJB

Guide de configuration des EJB

1. Vue d'ensemble

Dans cet article, nous allons expliquer comment démarrer avec le développement Enterprise JavaBean (EJB).

Enterprise JavaBeans are used for developing scalable, distributed, server-side components et encapsule généralement la logique métier de l'application.

Nous utiliseronsWildFly 10.1.0 comme solution de serveur préférée, cependant, vous êtes libre d'utiliser n'importe quel serveur d'applications Java Enterprise de votre choix.

2. Installer

Commençons par discuter des dépendances Maven requises pour le développement EJB 3.2 et comment configurer le serveur d'applications WildFly à l'aide du plugin Maven Cargo ou manuellement.

2.1. Dépendance Maven

Pour utiliser EJB 3.2,, assurez-vous d'ajouter la dernière version à la sectiondependencies de votre fichierpom.xml: 


    javax
    javaee-api
    7.0
    provided

Vous trouverez la dernière dépendance dans lesMaven Repository. Cette dépendance garantit que toutes les API Java EE 7 sont disponibles pendant la compilation. L'étendue deprovided garantit qu'une fois déployée, la dépendance sera fournie par le conteneur où elle a été déployée.

2.2. Configuration WildFly avec Maven Cargo

Voyons comment utiliser le plug-in Maven Cargo pour configurer le serveur.

Voici le code du profil Maven qui fournit le serveur WildFly: 


    wildfly-standalone
    
        
            
                org.codehaus.cargo
                cargo-maven2-plugin
                ${cargo-maven2-plugin.version
                
                    
                        wildfly10x
                        
                            
                                http://download.jboss.org/
                                  wildfly/10.1.0.Final/
                                    wildfly-10.1.0.Final.zip
                            
                        
                    
                    
                        
                            127.0.0.0
                            
                                9990
                            
                            
                                testUser:admin1234!

Nous utilisons le plugin pour télécharger le zip deWildFly 10.1 directement depuis le site Web de WildFly. Qui est ensuite configuré, en s'assurant que lehostname est127.0.0.1 et en définissant le port sur 9990.

Ensuite, nous créons un utilisateur test, en utilisant la propriétécargo.servlet.users, avec l'ID utilisateurtestUser et le mot de passeadmin1234!.

Maintenant que la configuration du plugin est terminée, nous devrions pouvoir appeler une cible Maven et faire en sorte que le serveur soit téléchargé, installé, lancé et que l'application soit déployée.

Pour ce faire, accédez au répertoireejb-remote et exécutez la commande suivante: 

mvn clean package cargo:run

Lorsque vous exécutez cette commande pour la première fois, il télécharge le fichier zip de WildFly 10.1, l'extrait, exécute l'installation, puis le lance. Il ajoutera également l'utilisateur test discuté ci-dessus. Toute exécution ultérieure ne téléchargera pas le fichier zip à nouveau.

2.3. Configuration manuelle de WildFly

Pour configurer WildFly manuellement, vous devez télécharger vous-même le fichier zip d'installation à partir du site Web dewildfly.org. Les étapes suivantes constituent une vue de haut niveau du processus de configuration du serveur WildFly:

Après avoir téléchargé et décompressé le contenu du fichier vers l'emplacement où vous souhaitez installer le serveur, configurez les variables d'environnement suivantes: 

JBOSS_HOME=/Users/$USER/../wildfly.x.x.Final
JAVA_HOME=`/usr/libexec/java_home -v 1.8`

Ensuite, dans le répertoirebin, exécutez./standalone.sh pour les systèmes d'exploitation Linux ou./standalone.bat pour Windows.

Après cela, vous devrez ajouter un utilisateur. Cet utilisateur sera utilisé pour se connecter au bean EJB distant. Pour savoir comment ajouter un utilisateur, vous devez jeter un œil aux‘add a user' documentation.

Pour obtenir des instructions de configuration détaillées, veuillez visiter lesGetting Started documentation de WildFly.

Le projet POM a été configuré pour fonctionner avec le plug-in Cargo et la configuration manuelle du serveur en définissant deux profils. Par défaut, le plugin Cargo est sélectionné. Cependant, pour déployer l'application sur un serveur Wildfly déjà installé, configuré et en cours d'exécution, exécutez la commande suivante dans le répertoireejb-remote: 

mvn clean install wildfly:deploy -Pwildfly-runtime

3. Remote contreLocal

Une interface métier pour un bean peut êtrelocal ouremote.

Un bean annoté@Local n'est accessible que s'il se trouve dans la même application que le bean qui fait l'appel, c'est-à-dire s'ils résident dans les mêmes.ear ou.war.

Un bean annoté@Remote est accessible depuis une autre application, i.e. une application résidant dans un serveur d'applications ouJVMdifférent.

Il y a quelques points importants à garder à l'esprit lors de la conception d'une solution qui inclut des EJB:

  • Lesjava.io.Serializable,java.io.Externalizable et les interfaces définies par le packagejavax.ejb sont toujours exclus lorsqu'un bean est déclaré avec@Local ou@Remote

  • Si une classe de bean est distante, toutes les interfaces implémentées doivent être distantes.

  • Si une classe de bean ne contient aucune annotation ou si l'annotation@Local est spécifiée, alors toutes les interfaces implémentées sont supposées être locales

  • Toute interface explicitement définie pour un bean qui ne contient aucune interface doit être déclarée comme@Local

  • La version EJB 3.2 tend à fournir plus de précision dans les situations où les interfaces locales et distantes doivent être définies explicitement.

4. Création de l'EJBRemote

Créons d'abord l'interface du bean et appelons-laHelloWorld: 

@Remote
public interface HelloWorld {
    String getHelloWorld();
}

Nous allons maintenant implémenter l'interface ci-dessus et nommer l'implémentation concrèteHelloWorldBean: 

@Stateless(name = "HelloWorld")
public class HelloWorldBean implements HelloWorld {

    @Resource
    private SessionContext context;

    @Override
    public String getHelloWorld() {
        return "Welcome to EJB Tutorial!";
    }
}

Notez l'annotation@Stateless sur la déclaration de classe. Cela indique que ce haricot est un haricot de session sans état. This kind of bean does not have any associated client state, mais il peut conserver son état d'instance et est normalement utilisé pour effectuer des opérations indépendantes.

L'annotation@Resource injecte le contexte de session dans le bean distant.

The SessionContext interface provides access to the runtime session context that the container provides for a session bean instance. Le conteneur passe ensuite l'interfaceSessionContext à une instance une fois l'instance créée. Le contexte de session reste associé à cette instance pendant toute sa durée de vie.

Le conteneur EJB crée normalement un pool d’objets de bean sans état et utilise ces objets pour traiter les demandes des clients. En raison de ce mécanisme de regroupement, il n'est pas garanti que les valeurs de variable d'instance soient maintenues pour tous les appels de méthodes de recherche.

5. Configuration à distance

Dans cette section, nous verrons comment configurer Maven pour générer et exécuter l’application sur le serveur.

Examinons les plugins un par un.

5.1. Le plugin EJB

Le plugin EJB qui est donné ci-dessous est utilisé pour empaqueter un module EJB. Nous avons spécifié la version de l'EJB en 3.2.

La configuration de plug-in suivante est utilisée pour configurer le fichier JAR cible pour le bean: 


    maven-ejb-plugin
    2.4
    
        3.2

5.2. Déployer l'EJB distant

Pour déployer le bean dans un serveur WildFly, assurez-vous que le serveur est opérationnel.

Ensuite, pour exécuter la configuration à distance, nous devrons exécuter les commandes Maven suivantes sur le fichier pom dans le projetejb-remote: 

mvn clean install

Ensuite, nous devrions lancer: 

mvn wildfly:deploy

Alternativement, nous pouvons le déployer manuellement en tant qu'utilisateuradmin depuis la console d'administration du serveur d'applications.

6. Configuration du client

Après avoir créé le bean distant, nous devrions tester le bean déployé en créant un client.

Commençons par discuter de la configuration Maven pour le projet client.

6.1. Configuration de Maven côté client

Pour lancer le client EJB3, nous devons ajouter les dépendances suivantes: 


    org.wildfly
    wildfly-ejb-client-bom
    pom
    import

Nous dépendons des interfaces métier distantes EJB de cette application pour exécuter le client. Nous devons donc spécifier la dépendance JAR du client EJB. Nous ajoutons ce qui suit dans le pom parent: 


    com.example.ejb
    ejb-remote
    ejb

Le<type> est spécifié commeejb.

6.2. Accéder au Bean distant

Nous devons créer un fichier soussrc/main/resources et le nommerjboss-ejb-client.properties qui contiendra toutes les propriétés nécessaires pour accéder au bean déployé: 

remote.connections=default
remote.connection.default.host=127.0.0.1
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options
  .SASL_POLICY_NOANONYMOUS = false
remote.connection.default.connect.options.org.xnio.Options
  .SASL_POLICY_NOPLAINTEXT = false
remote.connection.default.connect.options.org.xnio.Options
  .SASL_DISALLOWED_MECHANISMS = ${host.auth:JBOSS-LOCAL-USER}
remote.connection.default.username=testUser
remote.connection.default.password=admin1234!

7. Création du client

La classe qui accédera et utilisera le beanHelloWorld distant a été créée dansEJBClient.java qui se trouve dans le packagecom.example.ejb.client.

7.1 Remote Bean URL

Le bean distant est localisé via une URL conforme au format suivant: 

ejb:${appName}/${moduleName}/${distinctName}/${beanName}!${viewClassName}

  • Le${appName} est le nom d'application du déploiement. Ici, nous n’avons utilisé aucun fichier EAR mais un simple déploiement JAR ou WAR, le nom de l’application sera donc vide.

  • The[.crayon-pre .crayon-code] ${moduleName}## est le nom que nous avons défini pour notre déploiement plus tôt, donc c'estejb-remote

  • Le${distinctName} est un nom spécifique qui peut éventuellement être attribué aux déploiements déployés sur le serveur. Si un déploiement n'utilise pasdistinct-name, nous pouvons utiliser une chaîne vide dans le nom JNDI, pour lesdistinct-name, comme nous l'avons fait dans notre exemple

  • La variable[.crayon-pre .crayon-code]${beanName}## est le nom simple de la classe d'implémentation de l'EJB, donc dans notre exemple c'estHelloWorld

  • [.crayon-pre .crayon-code]${viewClassName}## désigne le nom d'interface complet de l'interface distante

7.2 Look-up Logic

Voyons ensuite notre logique de recherche simple: 

public HelloWorld lookup() throws NamingException {
    String appName = "";
    String moduleName = "remote";
    String distinctName = "";
    String beanName = "HelloWorld";
    String viewClassName = HelloWorld.class.getName();
    String toLookup = String.format("ejb:%s/%s/%s/%s!%s",
      appName, moduleName, distinctName, beanName, viewClassName);
    return (HelloWorld) context.lookup(toLookup);
}

Afin de nous connecter auxbean que nous venons de créer, nous aurons besoin d'une URL que nous pouvons alimenter dans le contexte.

7.3 The Initial Context

Nous allons maintenant créer / initialiser le contexte de session: 

public void createInitialContext() throws NamingException {
    Properties prop = new Properties();
    prop.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
    prop.put(Context.INITIAL_CONTEXT_FACTORY,
      "org.jboss.naming.remote.client.InitialContextFacto[ERROR]
    prop.put(Context.PROVIDER_URL, "http-remoting://127.0.0.1:8080");
    prop.put(Context.SECURITY_PRINCIPAL, "testUser");
    prop.put(Context.SECURITY_CREDENTIALS, "admin1234!");
    prop.put("jboss.naming.client.ejb.context", false);
    context = new InitialContext(prop);
}

Pour se connecter au bean distant, nous avons besoin d’un contexte JNDI. La fabrique de contexte est fournie par l'artefact Mavenorg.jboss:jboss-remote-naming et cela crée un contexte JNDI, qui résoudra l'URL construite dans la méthodelookup, en proxies vers le processus du serveur d'applications distant.

7.4 Define Lookup Parameters

On définit la classe d'usine avec le paramètreContext.INITIAL_CONTEXT_FACTORY.

LeContext.URL_PKG_PREFIXES est utilisé pour définir un package pour rechercher un contexte de dénomination supplémentaire.

Le paramètreorg.jboss.ejb.client.scoped.context = false indique au contexte de lire les paramètres de connexion (tels que l'hôte et le port de connexion) à partir de la carte fournie plutôt qu'à partir d'un fichier de configuration de chemin de classe. Cela est particulièrement utile si vous souhaitez créer un ensemble de fichiers JAR qui devrait pouvoir se connecter à différents hôtes.

Le paramètreContext.PROVIDER_URL définit le schéma de connexion et doit commencer parhttp-remoting://.

8. Essai

Pour tester le déploiement et vérifier la configuration, nous pouvons exécuter le test suivant pour nous assurer que tout fonctionne correctement: 

@Test
public void testEJBClient() {
    EJBClient ejbClient = new EJBClient();
    HelloWorldBean bean = new HelloWorldBean();

    assertEquals(bean.getHelloWorld(), ejbClient.getEJBRemoteMessage());
}

Avec le test réussi, nous pouvons maintenant être sûrs que tout fonctionne comme prévu.

9. Conclusion

Nous avons donc créé un serveur EJB et un client qui invoquent une méthode sur un EJB distant. Le projet peut être exécuté sur n’importe quel serveur d’application en ajoutant correctement les dépendances de ce serveur.

L'ensemble du projet peut être trouvéover on GitHub.

Related