Utilisation d'Enterprise JavaBeans avec interfaces distantes sur Liberty

Vous pouvez accéder à distance aux méthodes Enterprise Java Bean (EJB) à l'aide d'interfaces distantes lorsque EJB est hébergé par une autre machine virtuelle Java (JVM) ou une autre application au sein de cette même machine JVM. WebSphere® Application Server implémente des interfaces EJB distantes à l'aide de technologies RMI-IIOP. Vous pouvez activer une prise en charge EJB à distance avec la fonction ejbRemote-3.2.

Pourquoi et quand exécuter cette tâche

Pour configurer un serveur Liberty pour l'exécution d'une application avec la prise en charge EJB distante activée, vous devez définir le fonction ejbRemote-3.2.

Lorsque vous utilisez des interfaces EJB distantes, tenez compte des éléments suivants :

Nommage

Utilisation de l'espace de nom java:

La spécification EJB exige que les interfaces distantes soient liées à l'espace de nom java:, par exemple :
java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface    
java:app/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface    
java:module/ExampleBean!com.ibm.example.ExampleRemoteInterface

es composants EJB ne sont pas liés à l'espace de nom JNDI comme dans WebSphere Application Server Traditional ; par conséquent, les recherches et les liaisons @EJB dans les fichiers ibm-*-bnd.xml ne doivent pas utiliser cet espace de nom. Ces recherches doivent utiliser les noms java: pour les composants EJB qui sont hébergés au sein du même serveur et les URL corbaname: pour les composants EJB qui sont hébergés sur un autre serveur.

Utilisation d'URL corbaname:
Les interfaces sont aussi liées au service de nom ORB CosNaming dans des contextes similaires à ces interfaces dans l'espace de nom java:global. Ces interfaces sont accessibles via JNDI à l'aide des URL corbaname :, par exemple :
corbaname::test.ibm.com:2809#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome
corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome

Sur le serveur, la forme rir: de l'URL utilise le service de nom local. Sur le client, elle utilise le service par défaut ou le service de nom distant configuré.

Echappement des URL corbaname:

Selon la spécification du service de nommage de l'OMG, certains caractères dans les URL corbaname: doivent être échappés. Liberty essaie de déterminer si une URL corbaname: qui est dérivée de l'espace de nom java:global doit être échappée, puis elle l'échappe automatiquement. Cela n'est pas possible dans tous les cas. Par exemple, si un nom contient un point (.) mais pas de caractère non valide, il ne peut pas être échappé automatiquement. Pour forcer un nom à être interprété d'une façon particulière, il est nécessaire d'échapper manuellement l'URL, comme décrit dans la spécification Naming Service de l'OMG.

Utilisez le nom java:global suivant pour un bean enterprise :
java:global/TestApp/TestModule/TestBean!test.TestRemoteInterface
La forme simple de l'URL corbaname: ne peut pas être échappée automatiquement car elle représente un emplacement différent mais valide. Par conséquent, l'URL suivante ne fonctionne pas comme prévu :
corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test.TestRemoteInterface
Cette URL doit être échappée manuellement comme suit :
corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test%5c.TestRemoteInterface

La syntaxe d'échappement de l'URL corbaname: est décrite intégralement dans la spécification OMG Naming Service.

Utilisation programmatique de noms JNDI
Toutes les URL et tous les noms JNDI dans ces exemples peuvent être recherchés programmatiquement à partir d'un InitialContext. Lorsque vous recherchez un nom java:, l'objet résultant peut être transtypé directement dans le type attendu, par exemple :
Object found = new InitialContext().lookup("java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface");
ExampleRemoteInterface bean = (ExampleRemoteInterface) found;
Toutefois, lorsque vous récupérez des objets à l'aide d'URL corbaname:, le style RMI du transtypage, appelé narrowing, doit être utilisé, par exemple :
Object found = new InitialContext().lookup("corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface");
ExampleRemoteInterface bean = (ExampleRemoteInterface)PortableRemoteObject.narrow(found, ExampleRemoteInterface.class);
Interopérabilité
Tout produit qui prend en charge le protocole IIOP peut appeler des beans d'entreprise qui utilisent le modèle de programmation à distance EJB 2.x avec EJBHome et EJBObject lorsqu'il est packagé dans un module JAR RJB avec descripteur de déploiement version 2.0. Le fichier WLP_INSTALL_DIR/clients/ejbRemotePortable.jar doit être inclus dans le chemin d'accès aux classes du client distant. Ce fichier contient les classes de valeur système qui sont obligatoires pour la communication avec un serveur Liberty. Ce fichier n'est pas obligatoire si vous accédez à distance aux composants EJB depuis WebSphere Application Server Liberty ou WebSphere Application Server Traditional. Les composants EJB qui utilisent le modèle de programmation à distance EJB 3 sur Liberty peuvent être utilisés à distance par des processus WebSphere Application Server. Liberty ne fournit pas de client léger pour démarrer les composants EJB depuis un processus Java autonome. Il ne fournit pas non plus de capacités de gestion de charge de travail ou de reprise/basculement pour les composants EJB distants, y compris ceux-ci sont hébergés sur un serveur WebSphere Application Server Traditional.
Classes de raccord
Un client doit inclure des classes de raccord lorsque vous démarrez un composant EJB distant qui est hébergé sur un serveur WebSphere Application Server. Dans certains cas, si le client est WebSphere Application Server, le produit génère automatiquement les classes de raccord correctes :
  • Si une application client démarre un EJB distant qui est contenu dans la même application, Liberty Liberty génère automatiquement des classes de raccord.
  • Si le composant EJB cible s'exécute dans une application distincte et s'il utilise le modèle de programmation distant EJB 2.x avec EJBHome et EJBObject, le client doit inclure des classes de raccord dans son chemin d'accès aux classes. Si le composant EJB est hébergé sous Liberty or WebSphere Application Server Traditional, vous pouvez copier le fichier JAR du client EJB depuis l'application dans le fichier EAR une fois qu'il a été traité par la commande ejbdeploy. Si l'EJB est hébergé sur Liberty, vous devez utiliser le programme rmic qui est fourni avec votre kit SDK Java afin de générer les classes de raccord pour l'EJB cible, puis vous devez inclure ces classes de raccord avec le client.
  • Si l'EJB cible s'exécute dans une application distincte et s'il utilise le modèle de programmation distant EJB 3, le processus Liberty ou WebSphere Application Server Traditional du client génère automatiquement des classes de raccord. Les EJB qui utilisent le modèle de programmation à distance EJB 3 sur Liberty sont uniquement accessibles à distance par des processus WebSphere Application Server ou WebSphere Application Client.
Propagation de transaction
Liberty ne prend pas en charge la propagation de transactions sortantes ou entrantes. De plus, la spécification EJB, même lorsqu'un produit prend en charge la propagation de transaction sortante, doit encore envoyer un contexte de transaction null. Celui-ci doit être rejeté par les composants EJB qui utilisent les attributs de transaction Required (default), Mandatory ou Supports. Un client comportant une transaction globale active ne peut pas démarrer un composant EJB avec des attributs de transaction par défaut si le client ou le serveur se trouve dans Liberty. Le client peut démarrer le composant EJB si celui-ci est modifié afin d'utiliser les attributs de transaction RequiresNew ou NotSupported. Toutefois, le travail transactionnel effectué par le composant EJB n'est pas validé dans le cadre des transactions du client.
Méthodes asynchrones
Une interface distante EJB peut comporter une méthode asynchrone avec une valeur de retour de type Future. Le serveur renvoie un objet Future au client, qui est utilisé pour extraire la valeur. Les méthodes asynchrones distantes ne sont pas recommandées car l'accumulation de résultats non réclamés peut épuiser la mémoire. Pour atténuer ce problème, les résultats du serveur expirent si le client n'extrait pas le résultat dans les 24 heures ou si le nombre maximum de résultats non réclamés est supérieur à 1000. Ces valeurs peuvent ensuite être ajustées dans le fichier server.xml, par exemple :
<ejbContainer>        
     <async maxUnclaimedRemoteResults="10"unclaimedRemoteResultTimeout="10m"/>    
</ejbContainer>

Procédure

  1. Pour activer cette fonction, mettez à jour le fichier server.xml pour ajouter la fonction ejbRemote-3.2, par exemple :
    <featureManager>
         <feature>ejbRemote-3.2</feature>
    </featureManager>
  2. Configurez les fichiers de liaison de votre application, les fichiers ibm-*-bnd.xml, pour les références EJB distantes qui ont été définies dans le descripteur de déploiement <ejb-ref> ou avec des annotations de code source, @EJB. Aucune liaison n'est requise pour les références EJB qui fournissent un nom de consultation, sur l'annotation ou dans le descripteur de déploiement. Dans le fichier de liaison, la référence EJB peut être liée à l'aide de l'un des noms java: pour un EJB ou avec l'un des noms corbaname:, par exemple :
    Pour une référence EJB :
    @EJB(name="TestBean")
       TestRemoteInterface testBean;
    La liaison est définie :
     <ejb-ref name="TestBean" binding-name="corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test%5c.TestRemoteInterface"/>
  3. Configurez votre client d'application afin d'inclure des classes de raccord.
  4. (Facultatif) Configurez l'interopérabilité pour les applications qui prennent en charge le protocole IIOP pour l'utilisation d'interfaces distantes EJB par l'ajout du fichier WLP_INSTALL_DIR/clients/ejbRemotePortable.jar dans le chemin d'accès aux classes du client distant.

Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : twlp_ejb_remote.html