Pourquoi utiliser JNDI pour les sources de données
Quelqu'un peut-il expliquer pourquoi JNDI devrait être un moyen privilégié d'exposer des services tels qu'une base de données/jms?
Les articles que je rencontre parlent tous de l'avantage de ne pas avoir à charger un gestionnaire de pilotes spécifique, de bénéficier du pool de connexions, etc. mais c'est facilement réalisable en spécifiant le gestionnaire de pilotes dans un fichier de propriétés et en utilisant la réflexion.
Le regroupement de connexions peut également être réalisé en câblant la bonne mise en œuvre dans un bean d'application via un ressort ou autrement.
Alors pourquoi utiliser JNDI serait-il mieux?
JNDI brille vraiment lorsque vous devez déplacer une application entre des environnements: du développement à l'intégration pour tester à la production. Si vous configurez chaque serveur d'applications pour utiliser le même nom JNDI, vous pouvez avoir différentes bases de données dans chaque environnement et ne pas avoir à modifier votre code. Vous venez de récupérer le fichier WAR et de le déposer dans le nouvel environnement.
Voici quelques autres hypothèses qui sont cruciales à connaître pour juger cette réponse:
- Je n'ai pas du tout accès aux serveurs sur lesquels le code est déployé, à l'exception de l'accès en lecture seule aux journaux.
- La personne qui écrit et compile le code n'est pas la même personne qui configure et gère le serveur.
- Une fois qu'un fichier WAR a commencé son cheminement vers PROD, il ne peut plus être modifié sans revenir au début. Tout test effectué par QA sur le serveur de test doit être refait si le WAR est modifié.
Peut-être que vous ne voyez pas cet avantage parce que vous êtes un développeur seul qui écrit du code sur un bureau local et se déploie directement en production.
Je pense que le mécanisme "préféré" est celui qui est préféré par la personne qui fait l'administration et la configuration. Comme l'a souligné duffymo, il est crucial que la configuration soit externe à votre artefact déployable, mais sinon, je dirais que tout se passe. Si votre administrateur système préfère utiliser une interface graphique pour configurer les entrées JDNI, cool. S'il préfère éditer les fichiers de propriétés avec cssh et vi, cool aussi. Si vous êtes responsable du développement et de la configuration/déploiement de votre application, c'est à peu près votre appel. Personnellement, j'aime garder autant d'implémentations que possible dans mon artefact, ce qui signifie que ma source de données et mes pilotes y vivent également.
Si vous posez des questions sur les avantages techniques de JNDI par rapport aux alternatives, je ne suis pas sûr qu'il y en ait, mais vous voudrez peut-être clarifier votre question.
Comme mentionné par d'autres, JNDI est principalement utilisé pour la recherche d'emplacement de service, mais principalement pour les ressources de type DB.
Ce qui est le plus ennuyeux, c'est que l'API LDAP de Java est également l'API JNDI. Lorsque vous travaillez avec LDAP, les abstractions sont très déroutantes. JNDI a également l'inconvénient d'être parfois un point de défaillance unique.
Vous pouvez facilement accomplir la plupart de ce que fait JNDI en utilisant des alias de nom d'hôte. C'est-à-dire créer un alias qui pointe MYRESOURCE vers 127.0.0.1 dans ton /etc/hosts (ou où que ce soit pour votre env). Ensuite, dans votre configuration d'application, utilisez MYRESOURCE comme nom d'hôte (dans une URL jdbc par exemple).
Ensuite, lorsque vous déplacez votre application en production, modifiez simplement le /etc/hosts fichier pour pointer MYRESOURCE vers la ressource/le service de production (comme le serveur de base de données prod).
Ce qui précède est un répertoire de nommage beaucoup plus portable et plus petit qui fonctionnera dans d'autres langues (Ruby, python). Cela fonctionnera également avec des choses qui ne sont pas normalement effectuées avec JNDI comme les services REST. La seule chose ennuyeuse est que vous devrez mettre à jour vos fichiers hôtes de serveurs mais cela peut être automatisé via des scripts SSH.
Le véritable avantage de JNDI sur les fichiers de propriétés vient du déploiement dans un environnement en cluster. L'utilisation de fichiers de propriétés laisse la possibilité que certaines instances de serveur aient une valeur différente. Lorsque vous utilisez JNDI, la même valeur est transmise à tous les serveurs en cluster par le contrôleur de domaine, supprimant la nécessité de copier le même fichier de propriétés sur tous les serveurs (et probablement en redémarrant le serveur/l'application).
Un autre domaine où JNDI aide:
Il résumés la recherche de ressources. Normalement, la configuration JNDI est stockée dans un fichier XML sur le serveur d'applications, mais ce n'est pas nécessaire. La configuration peut par exemple être stockée sur un serveur LDAP, pour faciliter la maintenance de manière centralisée.
Si les applications que vous exécutez utilisent JNDI pour rechercher ce dont elles ont besoin, vous pouvez passer des fichiers de configuration à l'utilisation d'un serveur LDAP sans modifier les applications. Si chaque application attend un fichier de propriétés avec un nom codé en dur, vous n'avez pas de chance. Imaginez une entreprise avec des dizaines d'applications en production - les changer toutes serait un problème important.
En d'autres termes, JNDI brille principalement pour les scénarios de déploiement complexes, comme:
- de nombreux serveurs d'applications (éventuellement en cluster)
- de nombreuses applications différentes
- configuration centralisée
- différentes étapes du serveur (test, production)
Il peut donc sembler excessif au premier abord, mais il est très utile dans ces scénarios. Bien sûr, certains avantages s'appliquent même pour les petits déploiements, tels que la configuration standardisée des connexions DB.