¿Por qué usar JNDI para orígenes de datos?

Question

¿Puede alguien ayudar a explicar por qué JNDI debería ser una forma preferida de exponer servicios como una base de datos/jms?

Las publicaciones con las que me encuentro hablan de la ventaja de no tener que cargar un administrador de controlador específico, beneficiándose de la agrupación de conexiones, etc. pero eso se logra fácilmente especificando el administrador de controladores en un archivo de propiedades y utilizando la reflexión.

La agrupación de conexiones también se puede lograr mediante el cableado en la implementación correcta en un bean de aplicación a través de un muelle o de otro modo.

¿Por qué el uso de JNDI sería mejor?

Answer 1

JNDI realmente brilla cuando tienes que mover una aplicación entre entornos: desarrollo a integración para probar la producción. Si configura cada servidor de aplicaciones para usar el mismo nombre JNDI, puede tener diferentes bases de datos en cada entorno y no tener que cambiar su código. Simplemente toma el archivo WAR y lo deja caer en el nuevo entorno.

Éstos son algunos otros supuestos que son cruciales para saber la hora de juzgar esta respuesta:

• que no tienen acceso a los servidores en los que se despliega en todo el código, excepto para acceso de sólo lectura a registros
• La persona que escribe y empaqueta el código no es la misma persona que configura y administra el servidor.
• Una vez que un archivo WAR comienza su viaje a PROD, no se puede volver a cambiar sin volver al principio. Cualquier prueba realizada por QA en el servidor de prueba debe volver a realizarse si WAR se modifica.

Quizás no vea este beneficio porque es un desarrollador solitario que escribe código en un escritorio local y lo despliega directamente en la producción.

Answer 2

Creo que el mecanismo "preferido" es el preferido por la persona que hace la configuración y el administrador. Como Duffymo señaló, es crucial que la configuración sea externa a su artefacto desplegable, pero de lo contrario, diría que todo vale. Si su administrador de sistemas prefiere usar una GUI para configurar entradas JDNI, genial. Si él/ella prefiere editar archivos de propiedades con cssh y vi, también es genial. Si eres responsable tanto del desarrollo como de la configuración/implementación de tu aplicación, entonces esa es tu llamada. Personalmente, me gusta mantener la mayor implementación posible dentro de mi artefacto, lo que significa que mi fuente de datos y controladores también viven allí.

Si está preguntando sobre los beneficios técnicos de JNDI sobre las alternativas, no estoy seguro de que existan, pero es posible que desee aclarar su pregunta.

Answer 3

Según lo mencionado por otros JNDI en su mayor parte se utiliza para la búsqueda de ubicación de servicio, pero principalmente para los recursos tipo DB.

Lo más molesto es que la API LDAP de Java también es la API JNDI. Cuando se trabaja con LDAP, las abstracciones son muy confusas. JNDI también tiene la desventaja de ser a veces un único punto de falla.

Puede lograr fácilmente la mayoría de lo que hace JNDI usando alias de nombre de host. Eso es hacer un alias que apunte MYRESOURCE al 127.0.0.1 en su /etc/hosts (o donde sea para su env). Luego, en la configuración de su aplicación, use MYRESOURCE como nombre de host (en una url jdbc, por ejemplo).

Entonces, cuando usted mueve su aplicación a la producción acaba de modificación del archivo de la producción /etc/hosts señalar myresource al recurso de producción/servicio (como servidor de base de datos de prod).

El anterior es un directorio de nombres de huellas más pequeño y portátil que funcionará en otros idiomas (ruby, python). También funcionará con cosas que normalmente no se hacen con JNDI, como los servicios REST. Lo único molesto es que tendrá que actualizar los archivos hosts de su servidor, pero esto se puede automatizar a través de scripts SSH.

Answer 4

El beneficio real de JNDI sobre los archivos de propiedades se produce cuando se implementa en un entorno en clúster. El uso de archivos de propiedades deja la posibilidad de que algunas de las instancias del servidor tengan un valor diferente. Al usar JNDI, el controlador de dominio envía el mismo valor a todos los servidores en clúster, eliminando la necesidad de copiar el mismo archivo de propiedad en todos los servidores (y probablemente reiniciar el servidor/aplicación).

Answer 5

Otra área donde JNDI ayuda:

It resúmenes la búsqueda de recursos. Normalmente, la configuración JNDI se almacena en un archivo XML en el servidor de aplicaciones, pero no es necesario. La configuración podría, por ejemplo, almacenarse en un servidor LDAP, para que sea más fácil mantenerla centralmente.

Si las aplicaciones que ejecuta utilizan JNDI para buscar lo que necesitan, puede pasar de los archivos de configuración a utilizar un servidor LDAP sin modificar las aplicaciones. Si cada aplicación espera un archivo de propiedades con un nombre codificado, no tiene suerte. Imagine una empresa con docenas de aplicaciones en producción, cambiarlas sería un problema importante.

En otras palabras, JNDI brilla principalmente para escenarios de despliegue complejos, como:

• muchos servidores de aplicaciones (posiblemente agrupadas)
• muchas aplicaciones diferentes
• configuración centralizada
• etapas de servidor diferente (prueba , producción)

Así que puede parecer exagerado al principio, pero es muy útil en estos escenarios. Por supuesto, algunos beneficios se aplican incluso para implementaciones pequeñas, como la configuración estandarizada de las conexiones de base de datos.