Jeg trenger å dekke mye bakken denne måneden, så jeg vil utelukke lo og kutte rett til kulepunktene. For det første spiller Java Naming and Directory Interface en viktig rolle i flere Java-teknologier. Vi skal ta en titt på denne rollen for å bedre forstå JNDIs strategiske posisjon i det samlede Java-bildet. Deretter, i erkjennelse av ditt behov for en fungerende JNDI-tjeneste å leke med, vil jeg introdusere deg for en fritt tilgjengelig, bærbar LDAP-implementering, og jeg vil lære deg hvordan du kobler til og bruker en JNDI-tjenesteleverandør. Til slutt tar jeg deg nærmere inn på bindende objekter til oppføringer i JNDI.
TEKSTBOKS:
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
Før jeg begynner er det litt i orden. I løpet av de siste to månedene har jeg prøvd å overbevise deg om at navngivning og katalogtjenester omtrent er den elektroniske ekvivalenten til kortkatalogene som finnes i biblioteker. Nå som vi begynner på vår tur til de avanserte funksjonene til JNDI, vil jeg at du glemmer denne analogien fullstendig - den illustrerer grovt kraften til JNDI.
La oss begynne med en titt på hvordan JNDI vises i andre Java-teknologier.
JNDI overalt
JNDI spiller en rolle i en rekke Java-teknologier. La oss vurdere tre av dem: JDBC (Java Database Connectivity package), JMS (Java Messaging Service) og EJB (Enterprise JavaBeans).
JDBC er Java-teknologi for relasjonsdatabaser. JNDI dukket først opp i JDBC 2.0 valgfri pakke (se ressurser) i forbindelse med Datakilde
grensesnitt. EN Datakilde
eksempel, som navnet antyder, representerer en datakilde - ofte fra en database, men ikke alltid. EN Datakilde
forekomst lagrer informasjon om en datakilde - for eksempel navnet, driveren som skal lastes inn og brukes og plasseringen - og lar et program få en forbindelse til datakilden uten hensyn til de underliggende detaljene. JDBC-spesifikasjonen anbefaler at du bruker JNDI til å lagre Datakilde
gjenstander.
JMS er Java-teknologi for meldinger. JMS-spesifikasjonen beskriver administrerte objekter - objekter som inneholder JMS-konfigurasjonsinformasjon og brukes av JMS-klienter for å finne spesifikke meldingskøer og emner. Som tilfellet er med JDBC, anbefaler spesifikasjonen å finne JMS-administrerte objekter via JNDI.
Til slutt, vurder Enterprise JavaBeans. Alle bedriftsbønner publiserer et hjemmegrensesnitt - det eneste stedet klienter finner en bestemt bedriftsbønne gjennom - via JNDI.
Hva bringer JNDI til bordet som får det til å bli så høyt ansett?
For det første fremmer JNDI forestillingen om en sentralt administrert informasjonskilde - et viktig krav for bedriftsapplikasjoner. En sentralt administrert informasjonskilde er lettere å administrere enn en distribuert samling av informasjonskilder. Det er også enklere for klienter å finne nødvendig informasjon hvis de bare trenger å lete på ett sted.
For det andre, som du skal se, tillater JNDIs evne til å lagre Java-objekter direkte det å integrere nesten gjennomsiktig i Java-applikasjoner.
Poenget til leverandøren
For å bruke JNDI, trenger du en navn- og katalogtjeneste og en JNDI-tjenesteleverandør. Sun leverer flere leverandører av vanlige navngivnings- og katalogtjenester (COS-navngivning, NIS, RMI-registeret, LDAP og mer). Jeg har avgjort LDAP.
LDAP (Lightweight Directory Access Protocol) har de to fordelene ved å bli implementert mye (både i kommersielle og gratisformer) og er rimelig enkel å bruke. Funksjonene støttes også godt av Suns LDAP-tjenesteleverandør og JNDI.
Siden å skaffe og konfigurere en LDAP-server ikke egentlig er et Java-tema, vil jeg bare få deg i riktig retning og gi deg referanser til Internett-ressurser.
Tallrike LDAP-implementeringer er tilgjengelige. Mange er kommersielle produkter som Netscape Directory Server og IBMs Secure Way Directory. Noen er pakket som en del av større tilbud (Microsofts Active Directory er en del av Windows 2000). Hvis du har tilgang til en slik implementering, kan du hoppe over det meste av denne delen. Ellers skal jeg beskrive OpenLDAP - en fritt tilgjengelig implementering av LDAP basert på University of Michigan referanseimplementering - samt installasjon og konfigurasjon.
OpenLDAP er tilgjengelig fra OpenLDAP Foundation (se Ressurser). Lisensen er basert på Perls "kunstneriske lisens", noe som betyr at OpenLDAP er gratis (eller åpen kildekode) programvare. Ferdigpakket binærfiler er tilgjengelig for forskjellige varianter av Linux (Debian, Red Hat) samt BSD Unix. Arbeidet pågår med en port til Windows NT.
Hvis du planlegger å installere OpenLDAP, bør du lese SLAPD og SLURPD Administratorhåndbok (slapd er navnet på den kjørbare LDAP-serveren, og slurpd er navnet på LDAP-replikeringsserveren. Se Ressurser for plasseringen).
Jeg har et siste forslag om å gjøre hele opplevelsen din mer behagelig: uansett hvilken LDAP-implementering du bruker, snu skjemakontroll av. Et LDAP-skjema, som et databaseskjema, definerer begrensninger for den lagrede informasjonen. Ved normal bruk bidrar skjemakontroll til at oppføringer (tenk adressebokoppføringer) samsvarer med riktig format. Men siden du sannsynligvis vil spille i stedet for å bygge noe av varig betydning, vil skjemakontroll bare komme i veien. Ta ordet mitt for det.
Koble til en JNDI-kontekst
I tidligere artikler prøvde jeg å unngå å forklare i detalj hvordan jeg kunne samhandle med en JNDI-tjenesteleverandør som LDAP-tjenesteleverandøren. Jeg nevnte at du trenger en innledende kontekst for å utføre JNDI-operasjoner, men jeg brukte ikke mye tid på å fortelle deg hvordan du skulle få en. La meg fylle ut hullene. (For mer om innledende sammenhenger, se de to første artiklene i denne serien.)
Før du kan gjøre noe med JNDI, trenger du en innledende kontekst. Alle operasjoner utføres i forhold til konteksten eller en av dens underkontekster.
Å få en innledende kontekst krever tre trinn:
Velg først en tjenesteleverandør. Hvis du skal bruke OpenLDAP eller en annen LDAP-implementering, leverer Sun en LDAP-tjenesteleverandør (se Ressurser). Legg til navnet på tjenesteleverandøren i settet med miljøegenskaper (lagret i en
Hashtable
forekomst):Hashtable hashtableEnvironment = ny Hashtable (); hashtableEnvironment.put (Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
Legg til eventuell ekstra informasjon tjenesteleverandøren krever. For LDAP inkluderer URL-adressen som identifiserer tjenesten, rotkonteksten og navnet og passordet du kan koble til:
// tjenesten: ldap: // localhost: 389 / // rotkonteksten: dc = etcee, dc = com hashtableEnvironment.put (Context.PROVIDER_URL, "ldap: // localhost: 389 / dc = etcee, dc = com "); hashtableEnvironment.put (Context.SECURITY_PRINCIPAL, "navn"); hashtableEnvironment.put (Context.SECURITY_CREDENTIALS, "passord");
Til slutt, få den første sammenhengen. Hvis du bare har tenkt å utføre navngivningsoperasjoner, trenger du bare en
Kontekst
forekomst. Hvis du har tenkt å utføre en katalogoperasjon også, trenger du enDirContext
forekomst i stedet. Ikke alle leverandører leverer begge deler:Kontekstkontekst = ny InitialContext (hashtableEnvironment);
Eller:
DirContext dircontext = ny InitialDirContext (hashtableEnvironment);
Det er alt det er med det. La oss nå se på hvordan applikasjoner lagrer objekter til og henter gjenstander fra JNDI.
Arbeid med gjenstander
Muligheten til å lagre Java-objekter er nyttig: objektlagring gir utholdenhet og lar objekter deles mellom applikasjoner eller mellom forskjellige kjøringer av samme applikasjon.
Fra synspunktet til den involverte koden er objektlagring overraskende enkelt:
context.bind ("navn", objekt)
De binde()
operasjon binder et navn til et Java-objekt. Syntaksen til kommandoen minner om RMI, men semantikken er ikke så tydelig definert. Det er tillatt for binde()
operasjon for å lagre enten et øyeblikksbilde av objektet eller en referanse til et "live" objekt, for eksempel.
Vær oppmerksom på at binde()
operasjonen kaster en Navngi unntak
hvis det oppstår et unntak under operasjonen.
La oss nå ta en titt på binde()
operasjonens komplement - se opp()
:
Objektobjekt = context.lookup ("navn")
De se opp()
operasjon henter gjenstanden bundet til det angitte navnet. Nok en gang minner syntaksen om RMI, men metodens semantikk er ikke så tydelig definert.
Akkurat som med binde()
, den se opp()
operasjonen kaster en Navngi unntak
hvis det oppstår et unntak under operasjonen.
Objektlagring
Hva betyr det å lagre et objekt i en JNDI navn- og katalogtjeneste? Vi har allerede nevnt at den eksakte semantikken til binde()
og se opp()
operasjoner er ikke nøye definert; det er opp til JNDI-tjenesteleverandøren å definere sin semantikk.
I henhold til JNDI-spesifikasjonen oppfordres tjenesteleverandører (men ikke nødvendig) til å støtte objektlagring i ett av følgende formater:
- Serialiserte data
- Henvisning
- Attributter i katalogsammenheng
Hvis alle JNDI-tjenesteleverandører støtter disse standardmekanismene, står Java-programmerere fritt til å utvikle generiske løsninger som fungerer selv når det underliggende tjenesteleverandørslaget endres.
Hver av metodene ovenfor har fordeler og ulemper. Den beste metoden vil avhenge av kravene til applikasjonen under utvikling.
La oss vurdere hver etter hverandre.
Som seriell data
Den mest åpenbare tilnærmingen til å lagre et objekt i en katalog er å lagre den serielle representasjonen av et objekt. Det eneste kravet er at objektets klasse implementerer Serialiserbar
grensesnitt.
Når et objekt serialiseres, blir dets tilstand transformert til en strøm av byte. Tjenesteleverandøren tar strømmen av byte og lagrer den i katalogen. Når en klient ser opp objektet, rekonstruerer tjenesteleverandøren det fra de lagrede dataene.
Følgende kode viser hvordan du binder en LinkedList
til en oppføring i en JNDI-tjeneste:
// opprett koblet liste LinkedList linkedlist = new LinkedList (); . . . // bind context.bind ("cn = foo", koblet liste); . . . // lookup linkedlist = (LinkedList) context.lookup ("cn = foo");
Det er så enkelt!
Dessverre er de to andre metodene mer kompliserte. Jeg vil beskrive dem kort, men reservere en detaljert diskusjon for en senere dato.
Som referanse
Noen ganger er det ikke hensiktsmessig (eller mulig) å serieisere et objekt. Hvis objektet for eksempel tilbyr en tjeneste i et nettverk, er det ikke fornuftig å lagre tilstanden til selve objektet. Vi er interessert i informasjonen som er nødvendig for å finne og kommunisere med objektet.
Et eksempel er en forbindelse til en ekstern ressurs (en utenfor omfanget av Java Virtual Machine), for eksempel en database eller fil. Det er tydeligvis ikke fornuftig å prøve å lagre databasen eller selve filen i JNDI-tjenesten. I stedet ønsker vi å lagre den informasjonen som er nødvendig for å rekonstruere forbindelsen.
I dette tilfellet skal programmereren enten binde en Henvisning
forekomst som tilsvarer objektet eller har objektets klasse til å implementere Refererer
grensesnitt (der objektet genererer og gir et Henvisning
forekomst på forespørsel fra tjenesteleverandøren).
De Henvisning
forekomst inneholder nok informasjon til å gjenskape referansen. Hvis en referanse til en fil ble lagret, inneholder referansen nok informasjon til å opprette en Fil
objekt som peker på riktig fil.
Som attributter
Hvis du bruker en tjenesteleverandør som tilbyr katalogfunksjonalitet i stedet for bare navngivningsfunksjonalitet, kan du også lagre et objekt som en samling attributter på en DirContext
objekt (a DirContext
forekomst skiller seg fra en Kontekst
eksempel ved at det kan ha attributter).
For å bruke denne metoden må du opprette objekter som implementerer DirContext
grensesnitt og inneholder koden som er nødvendig for å skrive deres interne tilstand som en Attributter
gjenstand. Du må også opprette en objektfabrikk for å rekonstruere objektet.
Denne tilnærmingen er nyttig når objektet må være tilgjengelig for ikke-Java-applikasjoner.
Konklusjon
Hvis du har lest serien, bør du forstå og sette pris på kraften og betydningen av JNDI - du hører ikke mye om det, men det er der under dekslene.
Neste måned tar vi en titt på et JNDI-basert program. I mellomtiden bør du prøve å få JNDI i gang på en LDAP-server.
Lær mer om dette emnet
- JDBC 2.0 valgfri pakke
//java.sun.com/products/jdbc/articles/package2.html
- Gå til OpenLDAP Foundation for å laste ned OpenLDAP
//www.openldap.org/
- For å laste ned SLAPD og SLURPD Administratorhåndbok, gå til
//www.umich.edu/~dirsvcs/ldap/doc/guides/
- JNDI-informasjon, tjenesteleverandører og så videre
//java.sun.com/products/jndi/
Denne historien, "JNDI-oversikt, del 3: Avansert JNDI" ble opprinnelig utgitt av JavaWorld.