Omówienie JNDI, część 1: Wprowadzenie do usług nazewnictwa

Ci z was, którzy byli w bibliotece i nadal pamiętają to doświadczenie, mogą przypomnieć sobie proces lokalizowania książki z biblioteki. Jeśli nie masz kontaktu ze swoją antykwaryczną stroną, ta sytuacja będzie wydawać się nieznana; ale od czasu do czasu wędruję do lokalnej biblioteki w poszukiwaniu prawdziwej książki offline. Biblioteki są wypełnione tysiącami rzeczy - są zakurzone i zrobione z miazgi drzewnej i skóry bydlęcej, ale na swój sposób fascynują. W każdym razie, gdy pojawia się przymus znalezienia jakiejś, unikam naiwnego chodzenia po korytarzach biblioteki w poszukiwaniu jej i zamiast tego zwracam się do katalogu kart.

TEXTBOX: TEXTBOX_HEAD: Przegląd JNDI: Przeczytaj całą serię!

  • Część 1. Wprowadzenie do usług nazewnictwa
  • Część 2. Użyj usług katalogowych JNDI do lepszego zarządzania aplikacjami rozproszonymi

  • Część 3. Użyj JNDI do przechowywania obiektów aplikacji rozproszonej

  • Część 4. Zbierz wszystko, czego się nauczyłeś, dzięki aplikacji obsługującej JNDI: END_TEXTBOX

Katalog kartkowy dla niewtajemniczonych odwzorowuje nazwy książek na ich lokalizację w bibliotece. Idąc najpierw do katalogu kart i sprawdzając lokalizację książki, oszczędzam sobie znacznej ilości chodzenia. (Nawiasem mówiąc, słyszałem, że niektóre biblioteki pozwalają klientom korzystać z komputerów zamiast katalogu kartkowego. W połowie mają rację - teraz, jeśli po prostu umieszczą informacje z książek na komputerze, do którego należą. ..)

Choć może się to wydawać zaskakujące, pojęcie katalogu kartkowego jest bardzo przydatne również w świecie komputerów. W informatyce nazywamy to usługą nazewniczą, która kojarzy nazwy z lokalizacjami usług i informacjami. Zapewnia programom komputerowym jedno miejsce, w którym mogą znaleźć potrzebne im zasoby. Nawiasem mówiąc, programy nie marnują czasu na wykonywanie elektronicznego odpowiednika chodzenia po przejściach i nie wymagają również, aby lokalizacje były zakodowane na stałe w ich logice.

Znajdowanie zasobów ma szczególne znaczenie w dużych środowiskach korporacyjnych, w których tworzone aplikacje mogą zależeć od usług świadczonych przez aplikacje napisane przez inne grupy w innych działach. Dobrze zaprojektowana infrastruktura nazewnicza umożliwia takie projekty - a brak jednego uniemożliwia ich realizację. W rzeczywistości wiele działań związanych z przebudową procesów biznesowych rozpoczyna się od zaprojektowania i wdrożenia solidnej infrastruktury nazewnictwa i katalogów obejmującej całe przedsiębiorstwo.

W tym miesiącu przedstawiam Java Naming and Directory Interface (JNDI). JNDI zapewnia interfejs wspólnego mianownika dla wielu istniejących usług nazewnictwa. W związku z tym JNDI nie zostało zaprojektowane w celu zastąpienia istniejącej technologii; zamiast tego zapewnia wspólny interfejs dla istniejących usług nazewnictwa. Zacznijmy od przyjrzenia się niektórym z tych usług.

Wprowadzenie do usług nazewnictwa

Poniższy rysunek przedstawia organizację ogólnej usługi nazewnictwa.

Usługa nazewnictwa obsługuje zestaw powiązań. Wiązania odnoszą się do nazw obiektów. Wszystkie obiekty w systemie nazewnictwa są nazywane w ten sam sposób (to znaczy podlegają tej samej konwencji nazewnictwa ). Klienci używają usługi nazewnictwa do lokalizowania obiektów według nazwy.

Istnieje wiele istniejących usług nazewnictwa, z których kilka opiszę poniżej. Każdy z nich jest zgodny z powyższym wzorem, ale różnią się szczegółami.

  • Nazewnictwo COS (Common Object Services): Usługa nazewnictwa dla aplikacji CORBA; umożliwia aplikacjom przechowywanie i dostęp do odniesień do obiektów CORBA.

  • DNS (Domain Name System): internetowa usługa nazewnicza; mapuje przyjazne dla ludzi nazwy (takie jak www.etcee.com) na przyjazne dla komputera adresy IP (protokołu internetowego) w notacji kropkowanej czwórki (207.69.175.36). Co ciekawe, DNS to rozproszona usługa nazewnicza, co oznacza, że ​​usługa i jej baza danych są rozproszone na wielu hostach w Internecie.

  • LDAP (Lightweight Directory Access Protocol): opracowany przez University of Michigan; jak sama nazwa wskazuje, jest to uproszczona wersja DAP (Directory Access Protocol), która z kolei jest częścią X.500, standardu usług katalogowych w sieci. Obecnie ponad 40 firm wspiera LDAP.

  • NIS (Network Information System) i NIS +: usługi nazewnictwa sieciowego opracowane przez Sun Microsystems. Oba umożliwiają użytkownikom dostęp do plików i aplikacji na dowolnym hoście za pomocą jednego identyfikatora i hasła.

Wspólne cechy

Jak wspomniałem wcześniej, podstawową funkcją systemu nazewnictwa jest wiązanie nazw z obiektami (lub w niektórych przypadkach z odwołaniami do obiektów - o których za chwilę). Aby być usługą nazewnictwa, usługa musi przynajmniej zapewniać możliwość wiązania nazw z obiektami i wyszukiwania obiektów według nazwy.

Wiele systemów nazewnictwa nie przechowuje obiektów bezpośrednio. Zamiast tego przechowują odniesienia do obiektów. Jako ilustracja rozważ DNS. Adres 207.69.175.36 to odniesienie do lokalizacji komputera w Internecie, a nie samego komputera.

JNDI zapewnia interfejs obsługujący wszystkie te typowe funkcje. Ten interfejs przedstawię w dalszej części artykułu.

Ich różnice

Ważne jest również, aby zrozumieć, czym różnią się istniejące usługi nazewnictwa, ponieważ JNDI musi zapewniać funkcjonalną abstrakcję, która omija te różnice.

Oprócz różnic funkcjonalnych, najbardziej zauważalną różnicą jest sposób, w jaki każda usługa nazewnictwa wymaga określenia nazw - jej konwencja nazewnictwa. Kilka przykładów powinno zilustrować problem.

W DNS nazwy są tworzone z komponentów oddzielonych kropkami („.”). Czytają od prawej do lewej. Nazwa „www.etcee.com” określa maszynę o nazwie „www” w domenie „etcee.com”. Podobnie nazwa „etcee.com” określa domenę „etcee” w domenie najwyższego poziomu „com”.

W LDAP sytuacja jest nieco bardziej skomplikowana. Nazwy są tworzone z komponentów oddzielonych przecinkami („,”). Podobnie jak nazwy DNS, czytają od prawej do lewej. Jednak komponenty w nazwie LDAP muszą być określone jako pary nazwa / wartość. Nazwa „cn = Todd Sundsted, o = ComFrame, c = US” określa osobę „cn = Todd Sundsted” w organizacji „o = ComFrame, c = US”. Podobnie nazwa „o = ComFrame, c = US” określa organizację „o = ComFrame” w kraju „c = US”.

Jak ilustrują powyższe przykłady, sama konwencja nazewnictwa usługi nazewnictwa może potencjalnie wprowadzić znaczną część smaku bazowej usługi nazewnictwa do JNDI. Nie jest to funkcja, którą powinien mieć interfejs niezależny od implementacji.

JNDI rozwiązuje ten problem za pomocą Nameklasy i jej podklas oraz klas pomocniczych. NameKlasa reprezentuje nazwę składającą się z uporządkowanej sekwencji subnames i dostarcza metod pracy z nazwami niezależnych od danej usługi nazewnictwa.

Rzut oka na nazewnictwo JNDI

Jak wspomniałem powyżej, należy pamiętać, że JNDI to interfejs, a nie implementacja. Ten fakt ma pewne wady - potrzebujesz dostępu do istniejącej usługi nazewnictwa (takiej jak usługa LDAP) i musisz coś zrozumieć, jak to działa, aby móc bawić się JNDI. Z drugiej strony pozwala JNDI na bezproblemową integrację z istniejącym środowiskiem komputerowym, w którym dominuje ustalona usługa nazewnictwa.

Nazewnictwo JNDI obraca się wokół małego zestawu klas i kilku operacji. Przyjrzyjmy się im.

Kontekst i InitialContext

ContextInterfejs odgrywa kluczową rolę w JNDI. Kontekst reprezentuje zestaw powiązań w ramach usługi nazewnictwa, które mają tę samą konwencję nazewnictwa. ContextObiekt zapewnia metody wiązania nazw obiektom i Rozpinanie nazw z przedmiotami, do zmiany nazw obiektów, a dla wymieniając oprawy.

Niektóre usługi nazewnictwa zapewniają również funkcjonalność podkontekstu. Podobnie jak katalog w systemie plików, podkontekst jest kontekstem w kontekście. Ta hierarchiczna struktura pozwala na lepszą organizację informacji. W przypadku usług nazewnictwa, które obsługują podkonteksty, Contextklasa udostępnia również metody tworzenia i niszczenia podkontekstów.

JNDI performs all naming operations relative to a context. To assist in finding a place to start, the JNDI specification defines an InitialContext class. This class is instantiated with properties that define the type of naming service in use and, for naming services that provide security, the ID and password to use when connecting.

For those of you familiar with the RMI Naming class, many of the methods provided by the Context interface outlined below will look familiar. Let's take a look at Context's methods:

  • void bind(String stringName, Object object): Binds a name to an object. The name must not be bound to another object. All intermediate contexts must already exist.

  • void rebind(String stringName, Object object): Binds a name to an object. All intermediate contexts must already exist.

  • Object lookup(String stringName): Returns the specified object.

  • void unbind(String stringName): Unbinds the specified object.

The Context interface also provides methods for renaming and listing bindings.

  • void rename(String stringOldName, String stringNewName): Changes the name to which an object is bound.
  • NamingEnumeration listBindings(String stringName): Returns an enumeration containing the names bound to the specified context, along with the objects and the class names of the objects bound to them.

  • NamingEnumeration list(String stringName): Returns an enumeration containing the names bound to the specified context, along with the class names of the objects bound to them.

Each of these methods has a sibling that takes a Name object instead of a String object. A Name object represents a generic name. The Name class allows a program to manipulate names without having to know as much about the specific naming service in use.

The example

The example below illustrates how to connect to a naming service, list all of the bindings, or list a specific binding. It uses the filesystem service provider, which is one of the reference JNDI service-provider implementations provided by Sun. The filesystem service provider makes the filesystem look like a naming service (which it is, in many ways -- filenames like /foo/bar/baz are names and are bound to objects like files and directories). I selected it because everyone has access to a filesystem (as opposed to, say, an LDAP server).

import javax.naming.Context; import javax.naming.InitialContext; import javax.naming.Binding; import javax.naming.NamingEnumeration; import javax.naming.NamingException; import java.util.Hashtable; public class Main { public static void main(String [] rgstring) { try { // Create the initial context. The environment // information specifies the JNDI provider to use // and the initial URL to use (in our case, a // directory in URL form -- file:///...). Hashtable hashtableEnvironment = new Hashtable(); hashtableEnvironment.put( Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory" ); hashtableEnvironment.put( Context.PROVIDER_URL, rgstring[0] ); Context context = new InitialContext(hashtableEnvironment); // If you provide no other command line arguments, // list all of the names in the specified context and // the objects they are bound to. if (rgstring.length == 1) { NamingEnumeration namingenumeration = context.listBindings(""); while (namingenumeration.hasMore()) { Binding binding = (Binding)namingenumeration.next(); System.out.println( binding.getName() + " " + binding.getObject() ); } } // Otherwise, list the names and bindings for the // specified arguments. else { for (int i = 1; i < rgstring.length; i++) { Object object = context.lookup(rgstring[i]); System.out.println( rgstring[i] + " " + object ); } } context.close(); } catch (NamingException namingexception) { namingexception.printStackTrace(); } } } 

The program in the listing above first creates an initial context from the specified JNDI provider (in this case, Sun's filesystem provider) and a URL specifying a local directory. If no additional command-line arguments are specified, the program lists the objects and names of every entity in the specified directory. Otherwise, it lists the objects and names of only those items specified on the command line.

Conclusion

You should now have both an understanding of and an appreciation for naming services in general and JNDI in particular. In distributed environments, they are valuable tools for locating information and resources. JNDI makes it possible to work with a variety of naming services without having to master a multitude of APIs. Next month, we'll take a look at the other half of JNDI -- its directory functions.

Todd Sundsted pisze programy, odkąd komputery stały się dostępne w wygodnych modelach biurkowych. Chociaż początkowo zainteresowany budowaniem aplikacji rozproszonych w C ++, Todd przeszedł do języka programowania Java, kiedy stał się oczywistym wyborem dla tego rodzaju rzeczy. Oprócz pisania, Todd pracuje również jako architekt Java w oprogramowaniu ComFrame.

Dowiedz się więcej na ten temat

  • Pobierz pełny kod źródłowy tego artykułu w formacie zip

    //images.techhive.com/downloads/idge/imported/article/jvw/2000/01/jw-01-howto.zip

  • Wszystkie rzeczy JNDI

    //java.sun.com/products/jndi/

  • Dokumentacja JNDI

    //java.sun.com/products/jndi/docs.html

  • Aktualnie dostępni usługodawcy

    //java.sun.com/products/jndi/serviceproviders.html

  • Pełna lista poprzednich kolumn How-To Java

    //www.javaworld.com/javaworld/topicalindex/jw-ti-howto.html

Ta historia, „Przegląd JNDI, Część 1: Wprowadzenie do usług nazewnictwa”, została pierwotnie opublikowana przez JavaWorld.