setfont - new font java

Por qué usar JNDI para fuentes de datos

Question

¿Alguien puede 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 puede lograr fácilmente especificando el administrador del controlador en un archivo de propiedades y utilizando el reflejo.

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 resorte o de otro modo.

Entonces, ¿por qué usar JNDI sería mejor?

Answer 1

Como se menciona por otros, JNDI en su mayor parte se utiliza para la búsqueda de la ubicación del 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 a 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).

Luego, cuando mueva su aplicación a producción, simplemente cambie el /etc/hosts de la producción para apuntar MYRESOURCE al recurso / servicio de producción (como el servidor de la base de datos prod).

Lo anterior es un directorio de nombres de huella 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 2

Creo que el mecanismo "preferido" es el preferido por la persona que hace la administración y la configuración. 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 acerca de 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

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 4

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.

Aquí hay algunas otras suposiciones que son cruciales para saber al juzgar esta respuesta:

• No tengo acceso a los servidores en los que se implementó el código, a excepción del acceso de solo lectura a los 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 puede volver a cambiarse sin volver al principio. Cualquier prueba realizada por QA en el servidor de prueba debe volver a realizarse si WAR se modifica.

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

Answer 5

Otra área donde JNDI ayuda:

Resume 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 usar 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 implementación complejos, como:

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

Por lo tanto, puede parecer excesivo 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.