Utilisation d'Enterprise JavaBeans avec interfaces distantes sous 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 de service de dénomination Object Management Group (OMG), certains caractères dans les URL corbaname: doivent être mises en échappement. Liberty essaie de déterminer si une URL corbaname: qui est dérivée de l'espace de nom java:global doit être mise en échappement, puis elle la met automatiquement en échappement. Cela n'est pas possible dans tous les cas. Par exemple, si un nom contient un point (.), et aucun caractère incorrect, il ne peut pas être mis automatiquement en échappement. Pour forcer un nom à être interprété d'une façon particulière, il est nécessaire de mettre manuellement en échappement l'URL, comme décrit dans la spécification OMG Naming Service specification.
Utilisez le nom java:global suivant pour un bean enterprise :
La forme simple de l'URL corbaname: ne peut pas être mise en échappement automatiquement car il représente un emplacement différent mais valide. Par conséquent, l'URL suivant ne fonctionne pas comme prévu :java:global/TestApp/TestModule/TestBean!test.TestRemoteInterface
Cette URL doit être mise en échappement manuellement comme suit :corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test.TestRemoteInterface
corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test%5c.TestRemoteInterface
La syntaxe de mise en échappement de l'URL corbaname: est décrite intégralement dans la spécification OMG Naming Service.
- Utilisation des noms JNDI à l'aide d'un programmeToutes les URL et tous les noms JNDI dans ces exemples peuvent être recherchés à l'aide d'un programme à partir d'un élément InitialContext. Lorsque vous recherchez un nom java:, l'objet résultant peut être transtypé directement dans le type attendu, par exemple :
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("java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface"); ExampleRemoteInterface bean = (ExampleRemoteInterface) found;
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 depuis WebSphere Application Server Traditional. Les composants EJB qui utilisent le modèle de programmation à distance EJB 3 sous 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 des fonctions de gestion de charge de travail ou de reprise pour les composants EJB distants, y compris lorsque vous démarrez les composants EJB hébergés depuis Liberty or 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 composant EJB distant qui est contenu dans la même application, 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 le composant EJB est hébergé sous WebSphere Application Server 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 le composant EJB cible, puis vous devez inclure ces classes de raccord avec le client.
- Si le composant EJB cible s'exécute dans une application distincte et s'il utilise le modèle de programmation distant EJB 3, le processus WebSphere Application Server Liberty ou WebSphere Application Server Traditional du client génère automatiquement des classes de remplacement. Les composants EJB qui utilisent le modèle de programmation à distance EJB 3 sous 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 figure se trouve sur 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>