Programmering

JNDI-oversikt, del 1: En introduksjon til navngivningstjenester

De av dere som har vært på et bibliotek og fremdeles husker opplevelsen, kan huske prosessen med å finne en biblioteksbok. Hvis du ikke er i kontakt med den antikvariske siden, vil denne situasjonen virke ukjent; men innimellom vandrer jeg til et lokalt bibliotek for å lete etter en ekte, offline bok. Biblioteker er fylt med tusenvis av ting - de er støvete og laget av tremasse og kuskinn, men de er fascinerende på sin egen måte. Under alle omstendigheter, når tvangen til å finne en bestemt slår til, unngår jeg det naive løpet av å gå opp og ned i biblioteksgangene og lete etter det og snar i stedet til kortkatalogen.

TEXTBOX: TEXTBOX_HEAD: JNDI oversikt: Les hele serien!

  • Del 1. En introduksjon til navngivningstjenester
  • Del 2. Bruk JNDI-katalogtjenester for å bedre administrere distribuerte applikasjoner

  • Del 3. Bruk JNDI til å lagre objektene til det distribuerte programmet

  • Del 4. Trekk sammen det du har lært med et JNDI-aktivert program: END_TEXTBOX

En kortkatalog, for uinnvidde, tilordner navnene på bøkene til deres plassering i biblioteket. Ved å gå til kortkatalogen først og slå opp bokens plassering, sparer jeg meg mye å gå. (Forresten har jeg hørt at noen biblioteker faktisk tillater lånetakere å bruke datamaskiner i stedet for kortkatalogen. De har fått det halve riktig - nå hvis de bare legger informasjonen i bøkene inn i datamaskinen der den hører hjemme. ..)

Så overraskende som det kan virke, er forestillingen om en kortkatalog ganske praktisk også i databehandlingen. I databehandling kaller vi det a navngivningstjeneste, som knytter navn til stedene for tjenester og med informasjon. Det gir dataprogrammer med ett sted der de kan finne ressursene de trenger. På den måten kaster ikke programmer bort tid ved å utføre den elektroniske ekvivalenten for å gå opp og ned gangene, og krever heller ikke at stedene skal være hardkodet i sin logikk.

Det er spesielt viktig å finne ressurser i store bedriftsmiljøer, der applikasjonene du bygger kan avhenge av tjenester levert av applikasjoner skrevet av andre grupper i andre avdelinger. En godt designet navngivningsinfrastruktur muliggjør slike prosjekter - og mangelen på en gjør dem umulige. Faktisk begynner mange prosesser for omlegging av forretningsprosesser med utforming og implementering av en robust, omfattende virksomhetsomfattende navn- og kataloginfrastruktur.

Denne måneden introduserer jeg Java Naming and Directory Interface (JNDI). JNDI gir et fellesnevnergrensesnitt til mange eksisterende navngivningstjenester. Som sådan var JNDI ikke designet for å erstatte eksisterende teknologi; i stedet gir det et felles grensesnitt til eksisterende navngivningstjenester. La oss begynne med å se på noen av disse tjenestene.

En introduksjon til navngivningstjenester

Figuren nedenfor viser organisasjonen av en generisk navnetjeneste.

En navngivningstjeneste opprettholder et sett med bindinger. Bindinger knytter navn til objekter. Alle objekter i et navnesystem er navngitt på samme måte (det vil si at de abonnerer på det samme navnekonvensjon). Klienter bruker navngivningstjenesten for å finne objekter etter navn.

Det er en rekke eksisterende navngivningstjenester, hvorav noen vil jeg beskrive nedenfor. De følger hver mønsteret ovenfor, men avviker i detaljene.

  • COS (Common Object Services) Navngivning: Navnetjenesten for CORBA-applikasjoner; lar applikasjoner lagre og få tilgang til referanser til CORBA-objekter.

  • DNS (Domain Name System): Internett sin navngivningstjeneste; kartlegger personvennlige navn (for eksempel www.etcee.com) til datavennlige IP-adresser (Internet Protocol) i stiplet kvadratnotasjon (207.69.175.36). Interessant, DNS er en distribuert navngivningstjeneste, noe som betyr at tjenesten og dens underliggende database er spredt over mange verter på Internett.

  • LDAP (Lightweight Directory Access Protocol): Utviklet av University of Michigan; som navnet antyder, er det en lett versjon av DAP (Directory Access Protocol), som igjen er en del av X.500, en standard for nettverkskatalogtjenester. For tiden støtter over 40 selskaper LDAP.

  • NIS (Network Information System) og NIS +: Nettverksnavningstjenester utviklet av Sun Microsystems. Begge lar brukerne få tilgang til filer og applikasjoner på en hvilken som helst vert med en enkelt ID og passord.

Vanlige trekk

Som jeg nevnte tidligere, er den primære funksjonen til et navnesystem å binde navn til objekter (eller i noen tilfeller til referanser til objekter - mer om det i et øyeblikk). For å være en navngivningstjeneste, må en tjeneste i det minste gi muligheten til å binde navn til objekter og å slå opp objekter etter navn.

Mange navnesystemer lagrer ikke objekter direkte. I stedet lagrer de referanser til objekter. Ta hensyn til DNS som illustrasjon. Adressen 207.69.175.36 er en referanse til datamaskinens plassering på Internett, ikke selve datamaskinen.

JNDI gir et grensesnitt som støtter all denne vanlige funksjonaliteten. Jeg vil presentere dette grensesnittet senere i denne artikkelen.

Forskjellene deres

Det er også viktig å forstå hvordan eksisterende navngivningstjenester er forskjellige, siden JNDI må gi en gjennomførbar abstraksjon som kommer rundt disse forskjellene.

Bortsett fra funksjonelle forskjeller, er den mest merkbare forskjellen måten hver navngivningstjeneste krever at navn spesifiseres - dens navnekonvensjon. Noen få eksempler skal illustrere problemet.

I DNS bygges navn fra komponenter som er atskilt med prikker ("."). De leser fra høyre til venstre. Navnet "www.etcee.com" navngir en maskin som heter "www" i "etcee.com" -domenet. På samme måte kaller navnet "etcee.com" domenet "etcee" i toppdomenet "com".

I LDAP er situasjonen litt mer komplisert. Navn er bygget fra komponenter som er atskilt med komma (","). Som DNS-navn, leser de fra høyre til venstre. Komponenter i et LDAP-navn må imidlertid spesifiseres som navn / verdipar. Navnet "cn = Todd Sundsted, o = ComFrame, c = US" navngir personen "cn = Todd Sundsted" i organisasjonen "o = ComFrame, c = US." På samme måte kaller navnet "o = ComFrame, c = US" organisasjonen "o = ComFrame" i landet "c = US."

Som eksemplene ovenfor illustrerer, har en navngivningstjenestes navnekonvensjon alene potensialet til å introdusere en betydelig mengde av smaken til den underliggende navnetjenesten i JNDI. Dette er ikke en funksjon et implementeringsuavhengig grensesnitt skal ha.

JNDI løser dette problemet med Navn klasse og dens underklasser og hjelperklasser. De Navn klasse representerer et navn sammensatt av en ordnet sekvens av undernavn, og gir metoder for å jobbe med navn uavhengig av den underliggende navnetjenesten.

En titt på JNDI-navngivning

Som jeg nevnte ovenfor, er det viktig å huske at JNDI er et grensesnitt heller enn en gjennomføring. Dette faktum har noen ulemper - du trenger tilgang til en eksisterende navngivningstjeneste (for eksempel en LDAP-tjeneste), og du må forstå noe om hvordan den fungerer for å spille med JNDI. På den annen side tillater det JNDI å integreres sømløst i et eksisterende databehandlingsmiljø der en etablert navnetjeneste holder styr.

JNDI-navngivning dreier seg om et lite sett med klasser og en håndfull operasjoner. La oss ta en titt på dem.

Kontekst og innledende kontekst

De Kontekst grensesnitt spiller en sentral rolle i JNDI. En kontekst representerer et sett med bindinger i en navngivningstjeneste som alle deler samme navnekonvensjon. EN Kontekst objektet gir metodene for å binde navn til objekter og løse opp navn fra objekter, for å gi nytt navn til objekter og for å liste opp bindingene.

Noen navngivningstjenester tilbyr også underkontekstfunksjonalitet. I likhet med en katalog i et filsystem, er en underkontekst en kontekst i en kontekst. Denne hierarkiske strukturen tillater bedre organisering av informasjon. For navngivningstjenester som støtter underkontekster, Kontekst klasse gir også metoder for å lage og ødelegge underkontekster.

JNDI utfører alle navngivningsoperasjoner i forhold til en sammenheng. For å hjelpe deg med å finne et sted å starte, definerer JNDI-spesifikasjonen en InitialContext klasse. Denne klassen er instansert med egenskaper som definerer typen navngivningstjeneste i bruk, og for navngivningstjenester som gir sikkerhet, ID og passord som skal brukes når du kobler til.

For de av dere som er kjent med RMI Navngivning klasse, mange av metodene som tilbys av Kontekst grensesnittet som er beskrevet nedenfor, vil se kjent ut. La oss ta en titt på Kontekstsine metoder:

  • void bind (String stringName, Object object): Binder et navn til et objekt. Navnet må ikke være bundet til et annet objekt. Alle mellomkontekster må allerede eksistere.

  • ugyldig rebind (String stringName, Object object): Binder et navn til et objekt. Alle mellomkontekster må allerede eksistere.

  • Objektoppslag (String stringName): Returnerer det angitte objektet.

  • void unbind (String stringName): Binder opp det spesifiserte objektet.

De Kontekst grensesnittet gir også metoder for å gi nytt navn og liste opp bindinger.

  • ugyldig navn (String stringOldName, String stringNewName): Endrer navnet et objekt er bundet til.
  • NamingEnumeration listBindings (String stringName): Returnerer en oppregning som inneholder navnene bundet til den angitte konteksten, sammen med objektene og klassenavnene til objektene som er bundet til dem.

  • NamingEnumeration list (String stringName): Returnerer en oppregning som inneholder navnene som er bundet til den angitte konteksten, sammen med klassenavnene på objektene som er bundet til dem.

Hver av disse metodene har et søsken som tar en Navn objekt i stedet for en String gjenstand. EN Navn objektet representerer et generisk navn. De Navn klasse lar et program manipulere navn uten å måtte vite så mye om den spesifikke navngivningstjenesten som er i bruk.

Eksempelet

Eksemplet nedenfor illustrerer hvordan du kobler til en navngivningstjeneste, lister opp alle bindinger eller lister opp en spesifikk binding. Den bruker filsystemtjenesteleverandøren, som er en av referansen JNDI-tjenesteleverandørimplementasjoner levert av Sun. Filsystemtjenesteleverandøren gjør at filsystemet ser ut som en navngivningstjeneste (som det er, på mange måter - filnavn som / foo / bar / baz er navn og er bundet til objekter som filer og kataloger). Jeg valgte det fordi alle har tilgang til et filsystem (i motsetning til for eksempel en LDAP-server).

importere javax.naming.Context; importere javax.naming.InitialContext; importere javax.naming.Binding; importere javax.naming.NamingEnumeration; importere javax.naming.NamingException; importere java.util.Hashtable; public class Main {public static void main (String [] rgstring) {try {// Opprett den opprinnelige konteksten. Miljøet // informasjon spesifiserer JNDI-leverandøren som skal bruke // og den opprinnelige URL-en som skal brukes (i vårt tilfelle en // katalog i URL-form - fil: /// ...). Hashtable hashtableEnvironment = ny Hashtable (); hashtableEnvironment.put (Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory"); hashtableEnvironment.put (Context.PROVIDER_URL, rgstring [0]); Kontekstkontekst = ny InitialContext (hashtableEnvironment); // Hvis du ikke gir noen andre kommandolinjeargumenter, // oppgir alle navnene i den angitte konteksten og // objektene de er bundet til. hvis (rgstring.length == 1) {NamingEnumeration namingenumeration = context.listBindings (""); while (namingenumeration.hasMore ()) {Binding binding = (Binding) namingenumeration.next (); System.out.println (binding.getName () + "" + binding.getObject ()); }} // Ellers oppgir du navn og bindinger for // spesifiserte argumenter. annet {for (int i = 1; i <rgstring.length; i ++) {Object object = context.lookup (rgstring [i]); System.out.println (rgstring [i] + "" + objekt); }} context.close (); } fange (NamingException namingexception) {namingexception.printStackTrace (); }}} 

Programmet i oppføringen ovenfor oppretter først en innledende kontekst fra den angitte JNDI-leverandøren (i dette tilfellet Suns filsystemleverandør) og en URL som spesifiserer en lokal katalog. Hvis ingen ytterligere kommandolinjeargumenter er spesifisert, viser programmet objektene og navnene til hver enhet i den angitte katalogen. Ellers viser den bare objektene og navnene på de elementene som er spesifisert på kommandolinjen.

Konklusjon

Du bør nå ha både forståelse for og forståelse for navngivningstjenester generelt og JNDI spesielt. I distribuerte miljøer er de verdifulle verktøy for å finne informasjon og ressurser. JNDI gjør det mulig å jobbe med en rekke navngivningstjenester uten å beherske en rekke APIer. Neste måned ser vi på den andre halvdelen av JNDI - dets katalogfunksjoner.

Todd Sundsted har skrevet programmer siden datamaskiner ble tilgjengelig i praktiske stasjonære modeller. Selv om han opprinnelig var interessert i å bygge distribuerte applikasjoner i C ++, gikk Todd videre til Java-programmeringsspråket da det ble det åpenbare valget for den slags ting. I tillegg til å skrive, jobber Todd også som Java-arkitekt med ComFrame Software.

Lær mer om dette emnet

  • Last ned hele kildekoden for denne artikkelen, i zip-format

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

  • Alle ting JNDI

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

  • JNDI-dokumentasjon

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

  • Tjenesteleverandører som er tilgjengelige

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

  • Full liste over forrige Slik gjør du Java kolonner

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

Denne historien, "JNDI-oversikt, del 1: En introduksjon til navngivningstjenester" ble opprinnelig utgitt av JavaWorld.

$config[zx-auto] not found$config[zx-overlay] not found