Perché utilizzare JNDI per le origini dati

Question

Qualcuno può aiutare a spiegare perché JNDI dovrebbe essere un modo preferito per esporre servizi come un database/jms?

I post di cui parlo parlano del vantaggio di non dover caricare un gestore di driver specifico, che si avvale del pooling di connessioni ecc. Ma che è facilmente raggiungibile specificando il gestore di driver in un file di proprietà e utilizzando il reflection.

Il pool di connessioni può anche essere ottenuto collegando l'implementazione corretta in un bean di applicazione tramite molla o altro.

Quindi, perché utilizzare JNDI potrebbe essere migliore?

Answer 1

JNDI brilla davvero quando è necessario spostare un'applicazione tra gli ambienti: sviluppo in integrazione per verificare la produzione. Se si configura ciascun server dell'app per utilizzare lo stesso nome JNDI, è possibile avere database diversi in ogni ambiente e non modificare il codice. Basta prendere il file WAR e rilasciarlo nel nuovo ambiente.

Qui ci sono alcune altre ipotesi che sono cruciali per conoscere nel giudicare questa risposta:

• non ho accesso ai server su cui il codice è distribuito a tutti, tranne che per accesso in sola lettura ai log.
• La persona che scrive e confeziona il codice non è la stessa persona che configura e gestisce il server.
• Una volta che un file WAR inizia il suo viaggio verso PROD, non può essere cambiato di nuovo senza tornare all'inizio. Qualsiasi test eseguito dal QA sul server di prova deve essere rifatto se la WAR viene modificata.

Forse non si vede questo vantaggio perché sei uno sviluppatore solitario che scrive codice su un desktop locale e distribuisce direttamente alla produzione.

Answer 2

Penso che il meccanismo "preferito" sia quello preferito dalla persona che esegue l'amministrazione e la configurazione. Come ha sottolineato Duffymo, è fondamentale che la configurazione sia esterna al tuo artefatto dispiegabile, ma in caso contrario, direi che tutto va bene. Se il tuo sysadmin preferisce utilizzare una GUI per configurare le voci JDNI, cool. Se lui/lei preferisce modificare i file delle proprietà con cssh e vi, anche bello. Se sei responsabile sia dello sviluppo che della configurazione/distribuzione della tua app, allora è più o meno la tua chiamata. Personalmente, mi piace mantenere il maggior numero di implementazioni possibili all'interno del mio manufatto, il che significa che anche la mia fonte di dati e i driver ci vivono.

Se stai chiedendo dei vantaggi tecnici di JNDI rispetto alle alternative, non sono sicuro che ce ne siano, ma potresti voler chiarire la tua domanda.

Answer 3

Come già detto da altri JNDI per la maggior parte viene utilizzato per la ricerca della posizione del servizio, ma principalmente per le risorse di tipo DB.

La cosa più fastidiosa è che l'API LDAP di Java è anche l'API JNDI. Quando si lavora con LDAP, le astrazioni sono molto confuse. JNDI ha anche lo svantaggio di essere a volte un singolo punto di errore.

È possibile eseguire facilmente la maggior parte di ciò che fa JNDI utilizzando alias nome host. Questo è fare un alias che punta MYRESOURCE a 127.0.0.1 nel tuo /etc/hosts (o ovunque sia per il tuo env). Quindi nella configurazione dell'app utilizzare MYRESOURCE come nome host (in un url jdbc, ad esempio).

Quindi quando si sposta l'app in produzione è sufficiente modificare il file /etc/hosts della produzione in modo che punti MYRESOURCE alla risorsa/servizio di produzione (come il server del database di prod).

Quanto sopra è una directory di denominazione di impronte più piccola e più portatile che funzionerà in altre lingue (ruby, python). Funzionerà anche con cose che normalmente non sono fatte con JNDI come i servizi REST. L'unica cosa fastidiosa è che dovrai aggiornare i file degli host dei tuoi server, ma questo può essere automatizzato tramite gli script SSH.

Answer 4

Il vero vantaggio di JNDI sui file di proprietà arriva quando si esegue la distribuzione in un ambiente con cluster. L'utilizzo dei file di proprietà lascia la possibilità che alcune istanze del server abbiano un valore diverso. Quando si utilizza JNDI, lo stesso valore viene trasferito a tutti i server in cluster dal controller di dominio, eliminando la necessità di copiare lo stesso file di proprietà su tutti i server (e probabilmente riavviando il server/l'app).

Answer 5

Un'altra area in cui JNDI aiuta:

It abstract la ricerca delle risorse. Normalmente la configurazione JNDI è memorizzata in un file XML sul server delle applicazioni, ma non è necessario. Ad esempio, la configurazione può essere archiviata su un server LDAP per semplificare la manutenzione centralizzata.

Se le applicazioni eseguite utilizzano JNDI per cercare ciò di cui hanno bisogno, è possibile passare dai file di configurazione all'utilizzo di un server LDAP senza modificare le applicazioni. Se ogni applicazione si aspetta un file di proprietà con un nome scritto a mano, sei sfortunato. Immagina un'azienda con dozzine di applicazioni in produzione: cambiarle tutte sarebbe un problema significativo.

In altre parole, JNDI brilla soprattutto per scenari di distribuzione complessi, come:

• molti application server (possibilmente in cluster)
• molte applicazioni diverse
• configurazione centralizzata
• diverse fasi del server (di prova , produzione)

Quindi potrebbe sembrare eccessivo, in un primo momento, ma è molto utile in questi scenari. Ovviamente, alcuni vantaggi si applicano anche per le piccole distribuzioni, come la configurazione standardizzata delle connessioni DB.