Ingress: Fra Java-miljøet er det nå kommet en spesifikasjon på hvordan en kan skjære alle katalogsystemer over én kam, og bruke samme programmeringsmetoder mot dem alle: Java Naming and Directory Interface.
Av Anders Fongen
Mange av de programmene som vi bruker har en eller annen navnetjeneste, og vi bruker dem hele tiden. Tenk bare på Internet, hvor vi ikke et øyeblikk ville klare oss uten ”Domain Name Services”. DNS lar oss slippe å huske på 32-bits nettverksadresser, men heller memorere opplagte navn som f.eks www.aftenposten.no. Videre ønsker vi inne i et lokalnett ikke å huske på nettverksspesifikke opplysninger om printeren som står ved siden av oss, men derimot kun et enkelt navn, f.eks. ”Laserjet-Kursrom”.
Om du ønsker å sende en utskrift til en skriver hos aftenposten, kunne man da tenke seg å angi skrivernavnet ”skrivere.aftenposten.no/Laserjet-Kursrom”. Dette er ikke uten videre mulig, men hypotetisk har vi dette tilfellet laget en navnekombinasjon av to katalogsystemer: Den første delen er det globale navnesystemet som brukes i Internet, nemlig DNS, den andre delen er ett eller annet navnesystem som egner seg til bruk i et lokal nett. Det kan være Novell NDS, Sun NIS, eller kanskje LDAP. Og det som skal skje når vi gjør dette, er ikke bare å få fremvist opplysninger om denne skriveren, men å få lastet over den riktige driveren, og koplet den til utskriftstjenesten på vår egen arbeidsstasjon, slik at vi uten videre kan skrive til den.
Det finnes for øyeblikket ingen standard metode for knytte sammen forskjellige katalogtjenester på denne måten, selv om man i noen utstrekning kan bruke DNS for å navigere seg frem til andre ”lokale” tjenester som E-post og X.500-katalog. Men tanken på en ”meta-katalog”, som omfavner alle eksisterende og fremtidige katalog- og navnesystemer, det er ikke på plass ennå.
Men dette er altså at det Java-baserte JNDI-produktet forsøker å rette på. ”Java Naming and Directory Interface” er et API (programtjeneneste) som lar Java-programmereren bruke de ulike katalogsystemene på en ensartet måte, dvs. med de samme operasjonene uansett om dette er en LDAP, NIS, DNS, NDS eller X.500-katalog, eller en annen katalog som vi ikke har hørt om ennå:
JNDI tilbyr nemlig også et ”Service Provider Interface” (SPI). Dette er ”undersiden” av JNDI, og der skal alle som har en katalogtjeneste kunne ”plugge seg inn” i JNDI, slik at denne tjenesten blir synlig og brukbar gjennom JNDI.
JNDI blir dermed et slags ”utjevningsplattform” som representerer en standard modell for hvordan en navne- og katalogtjeneste skal vises frem for omgivelsene, og som i større eller mindre grad klarer å utnytte de særlige fordelene som hver enkelt katalogtjeneste måtte ha (og unngå begrensningene ved den enkelte tjenesten).
Men la oss først gå litt inn i den begrepsbruken som JNDI legger inn i sin katalogmodell:
Et navnesystem knytter sammen et navn og et objekt, slik at man gjennom en “lookup”-operasjon kan bruke navnet for å få tilgang til objektet. Legg merke til at vi ikke snakker om katalogdata ennå, vi er fortsatt i det “generelle” hjørnet hvor det navngitte objektet kan være hva som helst. Vi kan f.eks. tenke oss at vi i et Java-program kan skrive:
Printer pr1 = (Printer) ctx.lookup(”skrivere.aftenposten.no/Laserjet-Kursrom”);
pr1.printFile(new FileInputStream(”d:\brev.doc”));
I dette tilfellet er vi ikke interessert i noen opplysninger om skriveren, kun interessert i å benytte den som et tjenerobjekt.
Og hva er et navn? JNDI bestemmer at et fullt navn er satt sammen (compound name) av ett eller flere atomiske navn (atomic name) i en ordnet rekkefølge. Vi drar kjensel på denne regelen, og tenker på stinavn i UNIX (/usr/bin/perl) eller maskinnavn i Internet (www.sol.no). Med “ordnet” mener vi ikke nødvendigvis fra venstre mot høyre; et DNS-navn er ordnet fra høyre mot venstre.
Begreper som “current directory (UNIX) og “domain” (DNS) henspeiler på at alle atomiske navn befinner seg i en kontekst, dvs. et slags “ståsted” i navnesystemet. En kontekst kan dessuten selv befinne seg i en kontekst, noe som avspeiler seg nettopp i “compound names”.
Et navnesystem blir dermed nettopp dette nettverket av kontekst-objekter og de reglene som beskriver hvilke operasjoner som kan utføres på disse. Og det tilhørende navnerommet er alle mulige navn i et navnesystem (som følger navnesystemets regler).
Et navnesystem er altså kjennetegnet av et felles sett av regler og lovlige operasjoner. Vi kan derimot godt tenke oss navnekombinasjoner som “spenner over” flere navnesystemer, og vi har allerede berørt det i skrivereksemplet ovenfor. I http-protokollens adresseform (kalt URI – Uniform Resource Identifier) ser vi et eksempel på navnekombinasjoner: Først en protokollangivelse (http:) deretter angivelse av vertsmaskinen i DNS-systemet (www.aftenposten.no), deretter en ressursangivelse som tolkes lokalt av vertsmaskinen (ofte en kombinasjon av stinavn og parametre). Men fortsatt er dette eksempler på navnekombinasjoner som er spesifikt sammensatt. JNDI utvider dette til å gi et mye mer generelt apparat for å sette sammen navnesystemer.
Navnesystemet kopler altså et navn sammen med et objekt. Et katalogobjekt er en type objekt som kan romme data i form av attributter. Attributter har en identifikator og et sett av verdier.
Operasjonene på katalogobjekter er å lage, endre og fjerne attributter. Dersom vi tenker oss at et katalogobjekt også representerer en kontekst, kan vi lage et informasjonstre hvor de interne nodene både inneholder attributter og representerer en kontekst for atomiske navn.
Dette blir veldig teoretisk, men saken er at vi har akkurat dette i et vanlig filsystem: Ethvert navn hører til en katalog (kontekst), og kan selv være en kontekst for andre navn (dersom det er en katalog). Alle navnene er dessuten knyttet til informasjon om eier, beskyttelse, datostempel o.l. (attributter). Løvnodene (filene) er dessuten knyttet til et informasjonsinnhold (filen).
En moderne applikasjon vil ta i bruk mange ulike navne- og katalogtjenester. Den ønsker å finne et fjernobjekt gjennom en CORBA- eller RMI-basert navnetjener, noe som innebærer kall til DNS for å finne navnetjeneren, deretter kall til navnetjeneren gjennom en særskilt protokoll. Dersom vi ønsker å spørre om E-mail adresser kan det tenkes at vi spørre en LDAP-basert katalogtjener om dette, og opplysninger om rettigheter hos en pålogget bruker kan vi spørre en Novell DNS-basert katalogtjener om å få.
Dette kan innebære et overveldene stort antall metoder å holde styr på, og et overveldende antall klasser som må lastes inn under utføring. Vi tror at JNDI vil kunne tilby programmereren et mer jevnt sett av metoder for å skaffe alle disse dataene, selv om programeksempler i Java antyder at terskelen for å benyte JNDI er ganske høy.
Service Provider Interface
Som nevnt innledningsvis er JNDI også et rammeverk for dem som lager navne- og katalogtjenester, og som ønsker å plassere tjenesten under denne samme paraplyen. Dette foregår ved at tjenesteleverandøren må skrive Java-klasser som utfyller et sett av grensesnitt (interfaces), dvs. må implementere et bestemt sett av metoder for denne klassen. Disse klassene blir lastet inn og tatt i bruk når programmet instansierer et objekt av denne klassen.
Den enkleste tjenesteleverandøren trenger bare å tilby grensesnittet Context, og med den eneste metoden lookup. Den kan da tilby en enkel navnetjeneste som kan søke etter navn i ett navnerom, og returnere det objektet som er bundet til dette navnet. Noe slikt er nyttig når man bare vil lokalisere et objekt i en objekt-tjener, f.eks. et objekt som kan brukes til utskrift.
Mer komplisert blir det når tjenesteleverandøren vil tilby navnekombinasjoner (kalt name federation), dvs. navn som spenner over flere navnerom. Navnekombinasjoner kan ikke ta vilkårlige former, men må være gjenstand for en syntaks slik tilfellet er med f.eks. URI’er i Internet. Én tjenesteleverandør vil få oversendt et navn som følger denne syntaksen, og vil splitte opp delene og sørge for at de riktige tjenesteleverandørene får behandle “sin” del. Ved navnekombinasjoner kan det dessuten hende at ett navn i ett navnerom peker til nærmere bestemt kontekst i et annet navnerom og at søket i dette navnerommet ikke skal begynne “på toppen”, men et sted nede i treet. Dette er noe som tjenesteleverandøren må sørge for idet navnekombinasjonen sendes videre til neste “kollega”.
En annen ting som må kunne tas vare på gjennom SPI er katalogoppslag som summerer informasjonen fra flere kilder. Vi kan tenke oss muligheten av at en tjenesteleverandør gjør et LDAP katalogoppslag for å finne noen opplysninger om en person, og at det deretter søkes i E-postkatalogen, telefonlisten og billedarkivet. Til slutt stilles disse dataene sammen på en slik måte at de fremstår som et resultat av ett katalogoppslag.
Og her kan vi avslutningsvis si at et svært interessant egenskap ved JNDI er at den tilbyr at alle slags data, fra relasjonsdatabaser, flate filer, filkataloger og E-postsystemer, å bli sammenstillet og presentert på en måte som fremstår som et hierarkisk katalogsystem. JNDI kan altså ikke bare skape en enhetlig struktur på eksisterende navn- og katalogsystemer, men selv lage en katalogstruktur på alle slags datakilder.