Jaki jest cel JNDI

91

Jak możesz zrealizować użycie JNDI, z przykładem, jeśli to możliwe?

java jndi Ajay
źródło
3
Możesz sprawdzić osobisty post na blogu pod kątem przypadków użycia: tshikatshikaaa.blogspot.com/2013/01/…
Jérôme Verstrynge
@JVerstry +1 za wskazanie artykułu, który mówi o powiązanych LDAP, JCA i CCI.
Ajay,
Sprawdź ten wątek SO
Aniket Thakur

Odpowiedzi:

110

JNDI to Java Naming and Directory Interface. Służy do oddzielenia obaw twórcy aplikacji od osoby wdrażającej aplikację . Kiedy piszesz aplikację, która opiera się na bazie danych, nie powinieneś martwić się o nazwę użytkownika lub hasło do łączenia się z tą bazą danych. JNDI pozwala programistom nadać nazwę bazie danych i polegać na wdrażającym, aby odwzorować tę nazwę na rzeczywistą instancję bazy danych.

Na przykład, jeśli piszesz kod działający w kontenerze Java EE, możesz napisać to, aby uzyskać źródło danych o nazwie JNDI „Baza danych”:


DataSource dataSource = null;
try
{
    Context context = new InitialContext();
    dataSource = (DataSource) context.lookup("Database");
}
catch (NamingException e)
{
    // Couldn't find the data source: give up
}

Zauważ, że nie ma tu nic na temat sterownika bazy danych, nazwy użytkownika ani hasła. To jest skonfigurowane wewnątrz kontenera.

JNDI nie ogranicza się do baz danych (JDBC); można nadać nazwy wszystkim rodzajom usług. Aby uzyskać więcej informacji, zapoznaj się z samouczkiem Oracle .

Simon Nickerson
źródło
10
Na tym przykładzie, czym różni się JNDI od umieszczania nazw baz danych w pliku konfiguracyjnym XML lub pliku właściwości, a następnie odczytywania ich z tego miejsca?
Ajay
11
Po pierwsze, musiałbyś przechowywać hasło w postaci zwykłego tekstu w pliku konfiguracyjnym. Po drugie, jeśli masz kilka aplikacji wskazujących na tę samą bazę danych i coś o zmianach konfiguracji bazy danych, musisz zaktualizować konfigurację w wielu miejscach.
Simon Nickerson
1
dobrze, jak JNDI pomaga tutaj?
Ajay
1
powinien zawierać wszystko, co musisz wiedzieć o JNDI, czy to w kontekście J2EE, czy w kontekście JavaSE. javaworld.com/javaworld/jw-04-2002/jw-0419-jndi.html
Nico
5
@SimonNickerson Hi !. Dowiaduję się o JNDI. To dobra odpowiedź, ale jeśli zauważysz pytanie „Jak możesz uświadomić sobie użycie JNDI?” wtedy wygląda na niedokończone. Opisałeś realizację z perspektywy dewelopera. A co z perspektywą wdrażającego?
lxknvlk
31

JNDI to bardzo potężny mechanizm służący zarówno do organizowania informacji konfiguracyjnych, jak i do wykrywania usług oraz nasłuchiwania ich za pośrednictwem EventContext. W JNDI można wyszukiwać i nasłuchiwać dowolnego obiektu (nie tylko obiektów DataSource), zakładając, że obsługuje go dostawca usług JNDI.

Oczywiście jedynym problemem jest faktyczne posiadanie dostawcy usług JNDI; wspaniałą rzeczą w tym jest to, że zaskakująco łatwo jest toczyć własny. Po tym wszystkim można zakodować każdą instancję Java w XMLużyciu JavaBeans XMLEncoderi XMLDecoder: nie trzeba polegać na prowadzeniu w ramach serwera aplikacji!

Więc jaka jest różnica między tym a posiadaniem plików konfiguracyjnych? Cóż, może być znacznie czystszy, ponieważ wszystkie aplikacje mogą uzyskać konfigurację z tego samego miejsca . Jeśli potrzebują współużytkować informacje konfiguracyjne (np. Lokalizacje baz danych), można to zdefiniować raz w JNDI . Przypuśćmy, że przeniosłeś serwery baz danych: nie musisz pamiętać plików konfiguracyjnych Gazillion z ich lokalizacją. Po prostu udajesz się w jedno miejsce: JNDI.

oxbow_lakes
źródło
To jest zdecydowanie najbardziej zaokrąglone wyjaśnienie - dziękuję oxbow_lakes! Przy okazji, czy miałbyś wskaźniki kodu, w których jakaś instancja Java została zakodowana, jak sugerujesz?
Rohan Kumar
13

JNDI jest interfejsem API używanym do uzyskiwania dostępu do usług katalogowych i nazewnictwa (tj. Środków, za pomocą których nazwy są kojarzone z obiektami). Powiązanie nazwy z obiektem nazywane jest wiązaniem.

Podstawowym przykładem usługi nazewnictwa jest DNS, który odwzorowuje nazwy komputerów na adresy IP.

Korzystając z JNDI, aplikacje mogą przechowywać i pobierać nazwane obiekty Java dowolnego typu.

W kontekście Java może to być używane w plikach konfiguracyjnych, w których nie chcesz na stałe kodować zmiennych specyficznych dla środowiska.

Przykład wiosny:

Plik kontekstu sprężyny

<bean id="WSClientConfig" class="com.example.BaseClientConfigImpl">
<property name="protocol">
    <jee:jndi-lookup jndi-name="java:comp/env/protocol" />
</property>
<property name="endpoint">
    <jee:jndi-lookup jndi-name="java:comp/env/endpoint" />
</property>
<property name="requestPath">
<jee:jndi-lookup jndi-name="java:comp/env/requestPath" />    
</property>

Plik kontekstu Tomcat

<Environment name="protocol" type="java.lang.String" value="https://"/>
<Environment name="endpoint" type="java.lang.String" value="172.0.0.1"/>
<Environment name="requestPath" type="java.lang.String" value="/path/to/service"/>
Ithar
źródło
3

JNDI umożliwia uproszczenie konstrukcji zasobu do samej nazwy . Tak więc wiele szczegółów jest zgrupowanych w 1 dla wygody / bezpieczeństwa / itp. (inaczej warstwa abstrakcji)

do zrealizowania: skonfiguruj listę właściwości, która odpowiada predefiniowanym polom w Jndi Context Interface. (te właściwości określają ustawienia wykonania jndi, ale * nie nazwa wyszukiwania)

Properties props = new Properties();
//field Context.INITIAL_CONTEXT_FACTORY => property name java.naming.factory.initial
    //field Context.PROVIDER_URL => property name java.naming.provider.url
props.load(new FileInputStream("*properties file*")); //prop file in this case

Context ctx = new InitialContext(props);
    Object o = ctx.lookup("*name of resource*");

Idealnie byłoby, gdyby istniała wyspecjalizowana funkcja do utrzymywania katalogu LDAP, DNS itp. w Twojej organizacji (więc ujednolicony pojedynczy zestaw mapowania obsługuje wszystko, zmniejszając rozbieżności)

Lista dostawców usług JNDI: https://www.ibm.com/support/knowledgecenter/en/SSVSD8_8.4.1/com.ibm.websphere.dtx.adapjndi.doc/concepts/c_jndi_JNDI_Service_Providers_.htm

ilupper
źródło