Liaisons d'application

Pour qu'une application installée sur un serveur d'applications puisse démarrer, toutes les références de beans enterprise (EJB) et de ressource définies dans l'application doivent être liées aux artefacts réels (beans enterprise ou ressources) définis dans le serveur d'applications.

Lors de la définition des liaisons, vous devez spécifier les noms JNDI (Java™ Naming and Directory Interface) des artefacts référencés ou pouvant être référencés dans une application. Les valeurs jndiName spécifiées pour les artefacts doivent être des noms de recherche qualifiés. Un EJB défini dans une application est un artefact pouvant être référencé. Ce type d'artefact est par exemple une référence d'EJB ou de ressource utilisée par l'application.

Les définitions de liaisons sont stockées dans les fichiers ibm-xxx-bnd.xml ou ibm-xxx-bnd.xmi d'une application. Les définitions des liaisons de la version 7.0 ou des versions ultérieures prennent en charge les fichiers dont le suffixe est XML pour les modules EJB 3.x et Web 2.5 et éditions ultérieures. Les modules antérieurs à Java EE 5 utilisent toujours les fichiers de définitions de liaisons avec le suffixe XMI comme dans les versions antérieures de WebSphere Application Server. La valeur d'xxx peut être jar-ejb, web, application ou client-application.

Reportez-vous aux informations suivantes sur les liaisons :

Moments durant lesquels des liaisons peuvent être définies

Vous pouvez définir des liaisons aux moments suivants :

  • Au cours du développement de l'application

    Un développeur d'applications peut créer des définitions de liaison dans des fichiers ibm-xxx-bnd.xml pour les modules EJB 3.x et Web 2.5 et éditions ultérieures, et dans des fichiers ibm-xxx-bnd.xmi pour des modules antérieurs à Java EE 5. Il peut créer les fichiers à l'aide d'outils comme IBM® Rational Developer ou, pour les modules EJB 3.x ou Web 2.5 et éditions ultérieures, à l'aide d'un éditeur XML ou d'un éditeur de texte. Le développeur remet alors une application d'entreprise (fichier .ear) complète avec des liaisons à un assembleur ou à un déployeur d'applications. Lors de l'assemblage de l'application, l'assembleur ne modifie pas les liaisons. De même, lors de l'installation de l'application sur un serveur pris en charge par WebSphere Application Server, le déployeur ne modifie, ne remplace les liaisons, ni ne génère de liaisons par défaut, à moins que les modifications ne soient nécessaires pour la réussite du déploiement de l'application.

  • Au cours de l'assemblage de l'application

    Un assembleur d'applications peut définir des liaisons dans des descripteurs d'annotation ou de déploiement d'une application. Le code source des modules Java EE 5 ou de version ultérieure peut contenir des annotations. Pour déclarer une annotation, un assembleur d'applications insère un mot clé devant accompagné d'un @ (symbole "at"). Les liaisons des modules pré-Java EE 5 sont spécifiées dans la section Liaisons WebSphere d'un éditeur de descripteur de déploiement. La modification des descripteurs de déploiement peut changer les définitions de liaisons dans les fichiers ibm-xxx-bnd.xmi créés lors de la création d'une application. Suite à la définition des liaisons, l'assembleur donne l'application à un déployeur. Lors de l'installation de l'application sur un serveur pris en charge par WebSphere Application Server, le déployeur ne modifie, ne remplace les liaisons, ni ne génère de liaisons par défaut, à moins que les modifications ne soient nécessaires pour déployer l'application.

  • Au cours de l'installation de l'application

    Un déployeur d'applications ou un administrateur de serveur peut modifier les liaisons lors de l'installation de l'application sur un serveur pris en charge par WebSphere Application Server à l'aide de la console d'administration. De nouvelles définitions de liaisons peuvent être spécifiées dans les pages de l'assistant d'installation.

    Un déployeur ou administrateur peut choisir de générer des liaisons par défaut lors de l'installation de l'application. La sélection de l'option Générer des liaisons par défaut lors de l'installation de l'application permet de renseigner les liaisons incomplètes de l'application avec des valeurs par défaut. Les liaisons existantes ne seront pas modifiées.

    Restriction : Vous ne pouvez pas définir ou remplacer des liaisons lors de l'installation d'application pour les clients d'application. Vous devez définir les liaisons des modules de client d'application lors de l'assemblage et les stocker dans le fichier ibm-application-client-bnd.xmi.
  • Au cours de la configuration d'une application installée

    Après l'installation d'une application sur un serveur pris en charge par WebSphere Application Server, un déployeur d'applications ou un administrateur de serveur peut modifier les liaisons en modifiant des valeurs dans les pages de la console d'administration, telles que celles accessibles à partir de la page des paramètres de l'application d'entreprise.

Liaisons requises

Pour qu'une application puisse être déployée avec succès, les liaisons doivent être définies pour les références aux artefacts suivants :

Noms JNDI d'EJB
Pour chaque bean enterprise EJB 2.1 ou antérieur, vous devez spécifier un nom JNDI. Ce nom est utilisé pour lier une entrée dans l'espace de nom JNDI global pour l'objet home de l'EJB. Un exemple de nom JNDI pour une EJB Product dans une application Store peut être store/ejb/Product. La définition de liaison est stockée dans le fichier META-INF/ibm-ejb-jar-bnd.xmi.

Si un déployeur choisit de générer des liaisons par défaut lors de l'installation de l'application, l'assistant d'installation affecte des noms JNDI d'EJB de la forme préfixe/nom_EJB aux liaisons incomplètes. Le préfixe par défaut est ejb, mais peut être remplacé. Le nom EJB est celui spécifié dans la balise <ejb-name> du descripteur de déploiement.

Pendant et après l'installation de l'application, des noms JNDI d'EJB peuvent être spécifiés sur la page Fournir des noms JNDI pour les beans. Après l'installation, cliquez sur Applications > Types d'application > Applications d'entreprise WebSphere > nom_application > Noms JNDI d'EJB dans la console d'administration.

Vous n'avez pas besoin de spécifier des noms de liaisons JNDI pour chacune des interfaces home ou métier de vos EJB 3.x, car le conteneur EJB leur affecte des liaisons par défaut.

Sources de données pour les beans entity
Des beans entity tels que des beans CMP (à persistance gérée par conteneur) stockent des données persistantes dans des magasins de données. Avec les beans CMP, un conteneur EJB gère l'état persistant des beans. Vous devez spécifier quel magasin de données un bean utilise un module EJB ou un bean enterprise individuel en le liant à une source de données. La liaison d'un module EJB à une source de données entraîne l'utilisation de la même source de données pour la persistance pour tous les beans entity.

Un exemple de nom JNDI pour une source de données Store dans une application Store peut être store/jdbc/store. Pour les modules antérieurs à Java EE 5, la définition de liaison est stockée dans des fichiers de liaison IBM, tel que ibm-ejb-jar-bnd.xmi. Un déployeur peut également spécifier si l'authentification est gérée au niveau du conteneur ou de l'application.

WebSphere Application Server version 8.x prend en charge les beans CMP dans les modules EJB 2.x ou 1.x. Elle ne prend pas en charge les beans CMP dans les modules EJB 3.0.

Si un déployeur choisit de générer des liaisons par défaut lors de l'installation de l'application, l'assistant d'installation génère ce qui suit pour les liaisons incomplètes :

  • pour les fichiers .jar EJB 2.x, des liaisons de fabrique de connexions basées sur le nom JNDI et les informations d'autorisation spécifiées.
  • pour les fichiers .jar EJB 1.1, des liaisons de source de données basées sur le nom JNDI, un nom d'utilisateur et son mot de passe pour une source de données spécifiée.

Les liaisons générées fournissent des paramètres de fabrique de connexions par défaut pour chaque fichier .jar EJB 2.x et des paramètres de source de données par défaut pour chaque fichier .jar EJB 1.1 dans l'application en cours d'installation. Aucune liaison de fabrique de connexions, ni de source de données n'est générée au niveau du bean sauf si elle est spécifiée dans la règle de stratégie personnalisée lors de la génération de liaisons par défaut.

Pendant et après l'installation de l'application, des sources de données peuvent être mappées à des beans entity 2.x dans la page Sources de données des beans CMP 2.x CMP, et dans la page Sources de données des beans entity 2.x. Après l'installation, cliquez sur Applications > Types d'application > Applications d'entreprise WebSphere > nom_application dans la console d'administration, puis sélectionnez 2.x CMP bean data sources ou 2.x entity bean data sources. Vous pouvez mapper des sources de données vers des beans entity 1.x dans la page Mapper les sources de données pour tous les beans CMP 1.x et dans la page Fournir la source de données par défaut pour les modules contenant les beans entity 1.x. Après l'installation, accédez aux pages de la console similaires à celles des beans CMP 2.x, mais cliquez sur les liens pour les beans CMP 1.x.

ID de système dorsal pour modules EJB
Si un fichier .jar EJB définissant des beans CMP contient des mappages pour plusieurs bases de données du système dorsal, spécifiez l'ID de système dorsal approprié qui détermine les classes du persisteur à charger au cours de la phase d'exécution.

Indiquez l'ID du système dorsal au cours de l'installation de l'application. Il n'est pas possible de sélectionner un ID de système dorsal une fois l'application installée sur un serveur.

Pour activer des ID de systèmes dorsaux pour des modules EJB individuel :

  1. Lors de l'installation de l'application, sélectionnez Déploiement de beans enterprise dans la page Sélection des options d'installation. Si vous sélectionnez Déploiement de beans enterprise, vous pouvez accéder à la page Fournir des options pour effectuer le déploiement d'EJB.
  2. Dans la page Fournir des options pour effectuer le déploiement d'EJB, choisissez "" (null) comme type de base de données.

Lors de l'installation de l'application, si vous sélectionnez Déploiement de beans enterprise dans la page Sélection des options d'installation et que vous indiquez un type de base de données pour l'outil de déploiement d'EJB dans la page Fournir des options pour effectuer le déploiement d'EJB, les ID de système d'arrière-plan définis auparavant pour tous les modules EJB sont remplacés par le type de base de données choisi.

Le type de base de données par défaut est DB2UDB_V81.

L'outil de déploiement d'EJB ne fonctionne pas lors de l'installation des modules EJB 3.0 ou de version ultérieure.

Pour plus d'informations sur les bases de données d'arrière-plan, voir la documentation V8.5.5 sur l'outil de déploiement EJB et la commande ejbdeploy.

Références d'EJB
Une référence de bean enterprise (EJB) est un nom logique utilisé pour localiser l'interface home d'un bean enterprise. Les références d'EJB sont spécifiées au cours du déploiement. Pendant la phase d'exécution, des références d'EJB sont liées à l'emplacement physique (nom JNDI global) des beans enterprise dans l'environnement d'exploitation cible. Les références d'EJB sont mises à disposition dans le sous-contexte de nommage java:comp/env/ejb Java ou dans un autre espace de nom java: si le nom de la référence est une URL java:module, java:app ou java:app. Une référence d'EJB avec un nom sous forme d'URL est liée dans l'espace de noms correspondant, en fonction de cette URL.

Le produit affecte des valeurs JNDI aux cibles de référence d'EJB 3.0 incomplètes.

Vous devez spécifier un nom JNDI pour chaque référence EJB 2.1 ou antérieure. Un exemple de nom JNDI pour une référence d'EJB Supplier dans une application Store peut être store/ejb/Supplier. La définition de liaison est stockée dans des fichiers de liaison IBM, tel que ibm-ejb-jar-bnd.xmi. Lorsque l'EJB référencé est également déployé sur le même serveur d'applications, vous pouvez indiquer un nom JNDI dont la portée est le serveur. Mais si l'EJB référencé est déployé sur un autre serveur d'applications ou si ejb-ref est défini dans un module client d'application, vous devez spécifier le nom JNDI global au niveau de la cellule.

Si un déployeur choisit de générer des liaisons par défaut lors de l'installation de l'application, l'assistant d'installation lie les références d'EJB comme suit : si un élément <ejb-link> est détecté, il est est pris en compte. Si le ejb-name d'un EJB défini dans l'application correspond au nom ejb-ref, cet EJB est choisi. Sinon, si un EJB unique est détecté avec une interface home correspondante (ou local home) comme bean référencé, la référence est résolue automatiquement.

Pendant et après l'installation de l'application, vous pouvez spécifier des noms JNDI de référence d'EJB dans la page Mappage des références d'EJB vers les beans. Après l'installation, cliquez sur Applications > Types d'application > Applications d'entreprise WebSphere > nom_application > Références d'EJB dans la console d'administration.

Remarque : Pour permettre la résolution automatique des cibles de références d'EJB si les références proviennent de modules EJB 2.1 ou antérieurs ou de modules Web 2.3 ou antérieurs, sélectionnez Générer des liaisons par défaut dans la page Préparation de l'installation de l'application ou sélectionnez Autoriser la résolution automatique des cibles de référence d'EJB dans les pages de la console Sélection des options d'installation, Mappage des références d'EJB vers les beans ou Références d'EJB.
Références de ressource
Une référence de ressource est un nom logique utilisé pour localiser une ressource externe pour une application. Les références de ressources sont spécifiées au cours du déploiement. Pendant la phase d'exécution, les références sont liées à l'emplacement physique (nom JNDI global) de la ressource dans l'environnement d'exploitation cible. Les références de ressource qui n'utilisent pas d'URL pour le nom JNDI sont rendues disponibles de la manière suivante :
Tableau 1. Sous-contextes des références de ressources. Les noms java:comp/env JNDI sont utilisés pour les sous-contextes de référence de ressource.
Type de référence de ressource Sous-contexte déclaré dans
Source de données JDBC (Java DataBase Connectivity) java:comp/env/jdbc
Fabrique de connexions JMS java:comp/env/jms
Fabrique de connexions JavaMail java:comp/env/mail
Fabrique de connexions d'URL (Uniform Resource Locator) java:comp/env/url

Des applications peuvent également affecter des noms à des références de ressource qui sont des URL java: avec des préfixes tels que java:module, java:app et java:global. Les URL sont mappées à des espaces de noms autres que l'espace de noms des composants, qui contient les liaisons des noms java:comp/env. Une référence de ressource avec un nom sous forme d'URL est liée dans l'espace de noms correspondant, en fonction de cette URL.

Pour chaque référence de ressource, vous devez spécifier un nom JNDI. Si un déployeur choisit de générer des liaisons par défaut lors de l'installation de l'application, l'assistant d'installation génère des liaisons de référence de ressource issues de la balise <res-ref-name>, en supposant que le nom java:comp/env est identique au nom JNDI global de la ressource.

Pendant l'installation de l'application, vous pouvez spécifier des noms JNDI de référence de ressource dans la page Mappage des références de ressources vers des références. Indiquez des noms JNDI pour les ressources représentant les noms logiques dans les références de ressources. Vous pouvez également spécifier le nom de configuration de connexion et les propriétés d'authentification de la ressource. Une fois les propriétés d'authentification spécifiées, cliquez sur OK pour enregistrer les valeurs et revenir à l'étape de mappage. Chaque référence de ressource définie dans une application doit être liée à une ressource définie dans votre configuration WebSphere Application Server configuration. Après l'installation, ouvrez la console d'administration et cliquez sur Applications > Types d'applications > Applications d'entreprise WebSphere > nom_application > Références de ressource pour ouvrir la page Références de ressource.

Liaisons d'hôte virtuel pour modules Web
Vous devez lier chaque module Web à un hôte virtuel spécifique. La liaison informe le plug-in du serveur Web que toutes les demandes correspondant à l'hôte virtuel doivent être traitées par l'application Web associée. Par exemple, l'hôte virtuel à lier à une application Web Store pourrait être store_host. La définition des liaisons est stockée dans des fichiers de liaisons IBM tels que WEB-INF/ibm-web-bnd.xmi.

Si un déployeur choisit de générer des liaisons par défaut lors de l'installation de l'application, l'assistant d'installation spécifie l'hôte virtuel default_host pour chaque fichier .war.

Pendant et après l'installation de l'application, vous pouvez mapper un hôte virtuel vers un module Web défini dans votre application. Dans la page Mappage des hôtes virtuels pour les modules Web, indiquez un hôte virtuel. Le numéro de port indiqué dans la définition d'hôte virtuel est utilisé dans l'URL permettant d'accéder à des artefacts tels que les servlets et les fichiers JSP (JavaServer Pages) contenus dans le module Web. Par exemple, l'URL pour accéder depuis l'extérieur à un artefact Web tel qu'un fichier JSP est de la forme http://nom_hôte:port_hôte_virtuel/racine_contexte/chemin_jsp. Après l'installation, cliquez sur Applications > Types d'application > Applications d'entreprise WebSphere > nom_application > Hôtes virtuels dans la console d'administration.

Beans gérés par message
Pour chaque bean géré par message, vous devez spécifier une file d'attente ou un sujet dont le bean sera à l'écoute. Un bean géré par message est appelé par un programme d'écoute JMS (Java Messaging Service) lorsqu'un message arrive dans la file d'entrée contrôlée par le programme. Un déployeur spécifie un port d'écoute ou le nom JNDI d'une spécification d'activation, telle que définie dans un module de connecteur (fichier .rar) sous Liaisons WebSphere dans la page Beans d'un éditeur de descripteur de déploiement d'EJB d'outil d'assemblage. Un exemple de nom JNDI pour un port d'écoute destiné à être utilisé par une application Store peut être StoreMdbListener. La définition de liaison est stockée dans des fichiers de liaison IBM, tel que ibm-ejb-jar-bnd.xmi.
Si un déployeur choisit de générer des liaisons par défaut lors de l'installation de l'application, l'assistant d'installation affecte des noms JNDI aux liaisons incomplètes.
  • Pour les beans gérés par message EJB 2.0 ou supérieur et déployés en tant que ressources compatibles JCA 1.5, l'assistant d'installation affecte des noms JNDI correspondants aux instances activationSpec sous la forme eis/MDB_ejb-name.
  • Pour les beans gérés par message EJB 2.0 ou ultérieurs déployés sur les ports d'écoute, les ports d'écoute sont dérivés de la balise <ejb-name> suivie de la chaîne Port dans le bean géré par message.

Au cours de l'installation de l'application à l'aide de la console d'administration, vous pouvez spécifier un nom de port d'écoute ou un nom JNDI de spécification d'activation pour chaque bean géré par message dans la page Liaison des écouteurs pour les beans gérés par message. Un nom de port d'écoute doit être fourni lors de l'utilisation des fournisseurs JMS : Messagerie par défaut V5, WebSphere MQ ou générique. Une spécification d'activation doit être fournie lorsque les ressources de l'application sont configurées à l'aide du fournisseur de messagerie par défaut ou d'un adaptateur de ressources J2C générique prenant en charge la messagerie entrante. Si aucun des deux n'est spécifié, une erreur de validation s'affiche lors que vous cliquez sur Terminer dans la page Récapitulatif.

Après l'installation de l'application, vous pouvez spécifier des noms JNDI et configurer des beans gérés par message dans les pages de la console sous Ressources > JMS > Fournisseurs JMS ou Ressources > Adaptateurs de ressources.

Restriction : Vous pouvez uniquement lier des beans gérés par message définis dans un module EJB 3.0 ou de version ultérieure avec une spécification d'activation.
Références de destination de message
Une référence de destination de message est un nom logique utilisé pour localiser un bean enterprise dans un module EJB qui agit en tant que destination de message. Des références de destination de message existent uniquement dans des artefacts J2EE 1.4 ou ultérieurs, tels que :
  • Clients d'application J2EE 1.4
  • Projets EJB 2.1
  • Applications Web 2.4

Si plusieurs références de destination de message sont associées à un seul lien de destination de message, dans ce cas un seul nom JNDI pour un bean enterprise mappant vers le lien de destination du message, et en retour vers toutes les références de destination du message lié, est collecté au cours du déploiement. Lors de l'exécution, les références de destination du message sont liées aux destinations de message administrées dans l'environnement d'exploitation cible.

Si une référence de destination de message et un bean géré par message sont reliés par la même destination de message, ils doivent aussi avoir le même nom JNDI de destination. Si tel est le cas, seul le nom JNDI de destination pour le bean géré par message est relevé et appliqué à la référence de destination de message correspondante.

Si un déployeur choisit de générer des liaisons par défaut lors de l'installation de l'application, l'assistant d'installation affecte des noms JNDI aux références de destination de message incomplètes comme suit : si une référence de destination de message comporte une balise <message-destination-link>, le nom JNDI est ejs/message-destination-linkName. Sinon, le nom JNDI est défini à eis/message-destination-refName.

Selon les références de votre application et les artefacts qu'elle utilise, il se peut que vous deviez définir des liaisons pour d'autres références et artefacts.

Conflits entre ressources d'application

Avant la version 8 du produit, les ressources définies par une application, telles que les références et les entrées d'environnement, étaient liées dans l'espace de noms java:comp/env. Dans la version 8.0 ou les versions ultérieures, un développeur d'applications peut affecter un nom à une ressource qui est une URL java: avec un préfixe java:module, java:app ou java:global. Chacune de ces URL est résolue en un espace de noms distinct et différent de l'espace de noms des composants (comp). Un espace de noms java:module est partagé par tous les composants d'un module particulier, un espace de noms java:app est partagé par tous les modules d'une application particulière et un espace de noms java:global est partagé par toutes les applications dans une cellule spécifique. Comme les espaces de noms sont partagés, il est possible que le même nom soit attribué à différentes ressources et qu'il en résulte des conflits.

Au niveau d'un module, les conflits ne peuvent se produire que si deux composants dans ce module définissent des ressources ayant le même nom. Il est toutefois peu probable qu'un vrai conflit entre noms de ressources se produise dans un module, du fait de la portée relativement limitée à ce niveau. Cependant, s'il existe plusieurs instances de la même définition de ressources, elles doivent toutes être configurées de la même manière. Par exemple, deux références d'EJB désignant un type d'EJB particulier et auxquelles le même nom java:module est attribué doivent toutes deux être configurées avec les mêmes données de liaison. Sinon, les deux ressources seront en conflit et l'action de configuration de l'application échouera.

Les ressources sectorisées au niveau application sont comme les ressources de niveau module. La seule différence est que les définitions peuvent provenir de n'importe module dans l'application. Comme avec les ressources de niveau module, les ressources de niveau application qui ont le même nom doivent être du même type et être configurées avec les mêmes données de liaison.

Les ressources globales diffèrent des ressources des niveaux application et module en ce que les conflits sont susceptibles d'avoir lieu entre des applications différentes. Lorsqu'un tel conflit se produit, les applications impliquées ne peuvent coexister si les ressources ne sont pas les mêmes d'un point de vue logique. Si plusieurs occurrences d'une ressource globale identifient toutes logiquement la même ressource, elles doivent toutes être configurées avec les mêmes données de liaison ; elles seraient sinon identifiées comme sources de conflit par le produit. Si vous devez éditer une ressource globale dont il existe plusieurs occurrences pour différentes applications, toutes ces applications doivent être éditées dans la même session, sous peine de conflit et d'échec à la sauvegarde de la session.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_app_bindings
Nom du fichier : crun_app_bindings.html