Programmering

JNDI-oversigt, del 3: Avanceret JNDI

Jeg har brug for at dække en masse jord i denne måned, så jeg udelader fnug og skærer lige til kuglepunkterne. For det første spiller Java Naming and Directory Interface en vigtig rolle i flere Java-teknologier. Vi skal se på denne rolle for bedre at forstå JNDIs strategiske position i det samlede Java-billede. Som en anerkendelse af dit behov for en fungerende JNDI-tjeneste at lege med, introducerer jeg dig for en frit tilgængelig, bærbar LDAP-implementering, og jeg lærer dig, hvordan du opretter forbindelse til og bruger en JNDI-tjenesteudbyder. Endelig tager jeg dig ind for at se nærmere på bindende objekter til poster i JNDI.

TEKSTBOKS:

TEXTBOX_HEAD: JNDI-oversigt: Læs hele serien!

  • Del 1. En introduktion til navngivningstjenester

  • Del 2. Brug JNDI-katalogtjenester til bedre at administrere dine distribuerede applikationer

  • Del 3. Brug JNDI til at gemme dine distribuerede applikations objekter

  • Del 4. Træk sammen, hvad du har lært med en JNDI-aktiveret applikation

: END_TEXTBOX

Inden jeg begynder, er der en lille dobbelttænkning i orden. I løbet af de sidste to måneder har jeg forsøgt at overbevise dig om, at navngivning og katalogtjenester omtrent er det elektroniske svar på kortkatalogerne, der findes i bibliotekerne. Nu når vi begynder vores rundvisning i de avancerede funktioner i JNDI, vil jeg have dig til at glemme denne analogi fuldstændigt - den illustrerer groft JNDIs kraft.

Lad os begynde med et kig på, hvordan JNDI vises i andre Java-teknologier.

JNDI overalt

JNDI spiller en rolle i en række Java-teknologier. Lad os overveje tre af dem: JDBC (Java Database Connectivity-pakke), JMS (Java Messaging Service) og EJB (Enterprise JavaBeans).

JDBC er Java-teknologien til relationsdatabaser. JNDI dukkede først op i JDBC 2.0 valgfri pakke (se ressourcer) i forbindelse med Datakilde interface. EN Datakilde eksempel, som navnet antyder, repræsenterer en datakilde - ofte fra en database, men ikke altid. EN Datakilde forekomst gemmer information om en datakilde - såsom dens navn, driveren, der skal indlæses og bruges, og dens placering - og giver et program mulighed for at få forbindelse til datakilden uden hensyn til de underliggende detaljer. JDBC-specifikationen anbefaler, at du bruger JNDI til at gemme Datakilde genstande.

JMS er Java-teknologien til messaging. JMS-specifikationen beskriver administrerede objekter - objekter, der indeholder JMS-konfigurationsoplysninger og bruges af JMS-klienter til at finde specifikke meddelelseskøer og emner. Som det er tilfældet med JDBC, anbefaler specifikationen at finde JMS-administrerede objekter via JNDI.

Endelig overvej Enterprise JavaBeans. Alle virksomhedsbønner udgiver et hjemmegrænseflade - det enkelte sted, hvor klienter finder en bestemt virksomhedsbønne - via JNDI.

Hvad bringer JNDI til bordet, der får det til at blive så højt anset?

For det første fremmer JNDI forestillingen om en centralt styret informationskilde - et nøglekrav til virksomhedsapplikationer. En centralt administreret informationskilde er lettere at administrere end en distribueret samling af informationskilder. Det er også enklere for klienter at finde de nødvendige oplysninger, hvis de kun skal se ét sted.

For det andet, som du skal se, giver JNDIs evne til direkte at gemme Java-objekter, at det integreres næsten gennemsigtigt i Java-applikationer.

Pointen med udbyderen

For at bruge JNDI skal du bruge en navngivnings- og katalogtjeneste og en JNDI-tjenesteudbyder. Sun leverer flere udbydere af almindelige navngivnings- og katalogtjenester (COS-navngivning, NIS, RMI-registreringsdatabasen, LDAP og mere). Jeg har slået mig ned på LDAP.

LDAP (Lightweight Directory Access Protocol) har de dobbelte fordele ved at blive implementeret bredt (både i kommercielle og gratis former) og at være rimelig nem at bruge. Dens funktioner understøttes også godt af Suns LDAP-tjenesteudbyder og JNDI.

Da hentning og konfiguration af en LDAP-server ikke rigtig er et Java-emne, får jeg kun dig i den rigtige retning og forsyner dig med referencer til internetressourcer.

Talrige LDAP-implementeringer er tilgængelige. Mange er kommercielle produkter såsom Netscape Directory Server og IBMs Secure Way Directory. Nogle er pakket som en del af større tilbud (Microsofts Active Directory er en del af Windows 2000). Hvis du har adgang til en sådan implementering, kan du springe det meste af dette afsnit over. Ellers vil jeg beskrive OpenLDAP - en frit tilgængelig implementering af LDAP baseret på University of Michigan's referenceimplementering - samt dens installation og konfiguration.

OpenLDAP er tilgængelig fra OpenLDAP Foundation (se Ressourcer). Dens licens er baseret på Perls "kunstneriske licens", hvilket betyder, at OpenLDAP er gratis (eller open source) software. Færdigpakkede binære filer fås til forskellige varianter af Linux (Debian, Red Hat) samt BSD Unix. Der arbejdes med en port til Windows NT.

Hvis du planlægger at installere OpenLDAP, skal du læse SLAPD og SLURPD Administratorvejledning (slapd er navnet på den eksekverbare LDAP-server, og slurpd er navnet på LDAP-replikeringsserveren; se Ressourcer for placeringen).

Jeg har et sidste forslag til at gøre hele din oplevelse mere behagelig: uanset hvilken LDAP-implementering du bruger, drej skemakontrol af. Et LDAP-skema, som et databaseskema, definerer begrænsninger for den lagrede information. Ved normal brug hjælper skemakontrol med at sikre, at poster (tænk på adressebogsposter) stemmer overens med det korrekte format. Men da du sandsynligvis spiller i stedet for at opbygge noget af varig betydning, vil skemakontrol bare komme i vejen. Tag mit ord for det.

Opretter forbindelse til en JNDI-kontekst

I tidligere artikler forsøgte jeg at undgå at forklare detaljeret, hvordan man interagerer med en JNDI-tjenesteudbyder, såsom LDAP-tjenesteudbyderen. Jeg nævnte, at du har brug for en indledende kontekst for at udføre JNDI-operationer, men jeg brugte ikke meget tid på at fortælle dig, hvordan du får en. Lad mig udfylde hullerne. (For mere om indledende sammenhænge, ​​se de første to artikler i denne serie.)

Inden du kan gøre noget med JNDI, skal du have en indledende kontekst. Alle operationer udføres i forhold til konteksten eller en af ​​dens underkontekster.

At opnå en indledende kontekst kræver tre trin:

  1. Vælg først en tjenesteudbyder. Hvis du vil bruge OpenLDAP eller en anden LDAP-implementering, leverer Sun en LDAP-referenceudbyder (se Ressourcer). Føj navnet på tjenesteudbyderen til sættet med miljøegenskaber (gemt i en Hashtable eksempel):

     Hashtable hashtableEnvironment = ny Hashtable (); hashtableEnvironment.put (Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); 
  2. Tilføj eventuelle ekstra oplysninger, som tjenesteudbyderen kræver. For LDAP inkluderer det URL'en, der identificerer tjenesten, rodkonteksten og navnet og adgangskoden, der skal forbindes med:

     // tjenesten: ldap: // localhost: 389 / // rodkonteksten: 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, "adgangskode"); 
  3. Endelig få den indledende kontekst. Hvis du bare har til hensigt at udføre navngivningsoperationer, behøver du kun en Sammenhæng eksempel. Hvis du også vil udføre en bibliotekshandling, skal du bruge en DirContext eksempel i stedet. Ikke alle udbydere leverer begge:

     Kontekstkontekst = ny InitialContext (hashtableEnvironment); 

    Eller:

     DirContext dircontext = ny InitialDirContext (hashtableEnvironment); 

Det er alt der er ved det. Lad os nu se på, hvordan applikationer gemmer objekter til og henter objekter fra JNDI.

Arbejd med genstande

Evnen til at gemme Java-objekter er nyttig: objektlagring giver vedholdenhed og gør det muligt at dele objekter mellem applikationer eller mellem forskellige udførelser af den samme applikation.

Set fra den involverede kodes synspunkt er objektlagring overraskende let:

 context.bind ("navn", objekt) 

Det binde() operation binder et navn til et Java-objekt. Syntaksen for kommandoen minder om RMI, men semantikken er ikke så klart defineret. Det er tilladt for binde() handling for at gemme enten et øjebliksbillede af objektet eller en henvisning til et "live" objekt, for eksempel.

Vær opmærksom på, at binde() operation kaster en Navngivelse af undtagelse hvis der opstår en undtagelse under udførelsen af ​​operationen.

Lad os nu se på binde() operationens komplement - kig op():

 Objektobjekt = context.lookup ("navn") 

Det kig op() operation henter objektet bundet til det angivne navn. Endnu en gang minder syntaksen om RMI, men metodens semantik er ikke så klart defineret.

Ligesom med binde(), det kig op() operation kaster en Navngivelse af undtagelse hvis der opstår en undtagelse under udførelsen af ​​operationen.

Objektlagring

Hvad betyder det at gemme et objekt i en JNDI navngivnings- og katalogtjeneste? Vi har allerede nævnt, at den nøjagtige semantik af binde() og kig op() operationer er ikke stramt defineret; det er op til JNDI-tjenesteudbyderen at definere deres semantik.

I henhold til JNDI-specifikationen opfordres tjenesteudbydere (men ikke påkrævet) til at understøtte objektlagring i et af følgende formater:

  • Serialiserede data
  • Reference
  • Attributter i en mappekontekst

Hvis alle JNDI-tjenesteudbydere understøtter disse standardmekanismer, kan Java-programmører frit udvikle generiske løsninger, der fungerer, selv når det underliggende tjenesteudbyderslag ændres.

Hver af metoderne ovenfor har fordele og ulemper. Den bedste metode afhænger af kravene til applikationen under udvikling.

Lad os overveje hver efter hinanden.

Som serielle data

Den mest oplagte tilgang til lagring af et objekt i en mappe er at gemme den serielle repræsentation af et objekt. Det eneste krav er, at objektets klasse implementerer Serialiserbar interface.

Når et objekt serialiseres, omdannes dets tilstand til en strøm af bytes. Tjenesteudbyderen tager strømmen af ​​bytes og gemmer den i biblioteket. Når en klient ser op på objektet, rekonstruerer tjenesteudbyderen det ud fra de lagrede data.

Den følgende kode viser, hvordan man binder en LinkedList til en post i en JNDI-tjeneste:

 // opret linket liste LinkedList linkedlist = ny LinkedList (); . . . // bind context.bind ("cn = foo", linklist); . . . // lookup linkedlist = (LinkedList) context.lookup ("cn = foo"); 

Det er så let!

Desværre er de to andre metoder mere komplicerede. Jeg vil kort beskrive dem, men reservere en detaljeret diskussion til en senere dato.

Som reference

Nogle gange er det ikke hensigtsmæssigt (eller muligt) at serieisere et objekt. Hvis objektet f.eks. Leverer en tjeneste på et netværk, giver det ikke mening at gemme selve objektets tilstand. Vi er interesserede i de nødvendige oplysninger for at finde og kommunikere med objektet.

Et eksempel er en forbindelse til en ekstern ressource (en uden for Java Virtual Machine), såsom en database eller fil. Det giver helt klart ikke mening at forsøge at gemme databasen eller selve filen i JNDI-tjenesten. I stedet ønsker vi at gemme de oplysninger, der er nødvendige for at rekonstruere forbindelsen.

I dette tilfælde skal programmøren enten binde en Reference forekomst, der svarer til objektet eller har objektets klasse til at implementere Referencerbar interface (hvor objektet genererer og leverer en Reference eksempel, når tjenesteudbyderen anmoder om det).

Det Reference forekomst indeholder tilstrækkelig information til at genskabe referencen. Hvis der blev gemt en henvisning til en fil, indeholder referencen tilstrækkelig information til at oprette en Fil objekt, der peger på den rigtige fil.

Som attributter

Hvis du bruger en tjenesteudbyder, der leverer biblioteksfunktionalitet i stedet for kun navngivningsfunktionalitet, kan du også gemme et objekt som en samling attributter på en DirContext objekt (a DirContext eksempel adskiller sig fra en Sammenhæng eksempel ved at det kan have attributter).

For at bruge denne metode skal du oprette objekter, der implementerer DirContext interface og indeholder den nødvendige kode for at skrive deres interne tilstand som en Egenskaber objekt. Du skal også oprette en objektfabrik for at rekonstruere objektet.

Denne tilgang er nyttig, når objektet skal være tilgængeligt af ikke-Java-applikationer.

Konklusion

Hvis du har læst serien, skal du forstå og sætte pris på kraften og vigtigheden af ​​JNDI - du hører ikke meget om det, men det er der under coveret.

Næste måned ser vi på en JNDI-baseret applikation. I mellemtiden skal du prøve at få JNDI i gang på en LDAP-server.

Lær mere om dette emne

  • JDBC 2.0 valgfri pakke

    //java.sun.com/products/jdbc/articles/package2.html

  • Gå til OpenLDAP Foundation for at downloade OpenLDAP

    //www.openldap.org/

  • At downloade SLAPD og SLURPD Administratorvejledning, gå til

    //www.umich.edu/~dirsvcs/ldap/doc/guides/

  • JNDI-oplysninger, tjenesteudbydere og så videre

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

Denne historie, "JNDI-oversigt, del 3: Avanceret JNDI" blev oprindeligt udgivet af JavaWorld.