Programmering

JNDI-oversikt, del 3: Avansert JNDI

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:

  1. 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"); 
  2. 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"); 
  3. 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 en DirContext 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.

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