Jini: Ny teknologi for en nettverksverden

Forrige 1 2 Side 2 Side 2 av 2

Jini i sammenheng

Tradisjonelt har operativsystemer blitt designet med den antagelsen at en datamaskin vil ha en prosessor, noe minne og en disk. Når du starter en datamaskin, er det første den ser etter en disk. Hvis den ikke finner en disk, kan den ikke fungere som en datamaskin. I økende grad vises imidlertid datamaskiner i en annen forkledning: som innebygde enheter som har en prosessor, noe minne og en nettverkstilkobling - men ingen disk. Det første en mobiltelefon gjør når du starter den, er for eksempel å se etter telefonnettverket. Hvis det ikke finner nettverket, kan det ikke fungere som en mobiltelefon. Denne trenden i maskinvaremiljøet, fra disksentrisk til nettverkssentrisk, vil påvirke hvordan vi organiserer programvaren vår - og det er der Jini kommer inn.

Jini er et forsøk på å tenke om dataarkitektur, gitt den økende betydningen av nettverket og spredningen av prosessorer i enheter som ikke har noen diskstasjon. Disse enhetene, som kommer fra mange forskjellige leverandører, må samhandle over et nettverk. Selve nettverket vil være veldig dynamisk - enheter og tjenester vil bli lagt til og fjernet regelmessig. Jini tilbyr mekanismer som muliggjør jevn tilføying, fjerning og funn av enheter og tjenester i nettverket. I tillegg gir Jini en programmeringsmodell som gjør det lettere for programmerere å få enhetene sine til å snakke med hverandre.

Jini prøver å utvide fordelene med objektorientert programmering til nettverket ved å bygge på Java, objektserialisering og RMI, som gjør at objekter kan bevege seg rundt i nettverket fra virtuell maskin til virtuell maskin. I stedet for å kreve at enhetsleverandører blir enige om nettverksprotokollene som enhetene deres kan samhandle med, gjør Jini at enhetene kan snakke med hverandre gjennom grensesnitt til objekter.

Hva er Jini?

Jini er et sett med APIer og nettverksprotokoller som kan hjelpe deg med å bygge og distribuere distribuerte systemer som er organisert som tjenesteforbund. EN service kan være alt som sitter i nettverket og er klar til å utføre en nyttig funksjon. Maskinvareenheter, programvare, kommunikasjonskanaler - til og med menneskelige brukere selv - kan være tjenester. En Jini-aktivert diskstasjon, for eksempel, kan tilby en "lagringstjeneste". En Jini-aktivert skriver kan tilby en "utskrift" -tjeneste. EN føderasjon av tjenester, er det et sett med tjenester, som for øyeblikket er tilgjengelige på nettverket, som en klient (som betyr et program, en tjeneste eller en bruker) kan samle for å hjelpe den med å nå et mål.

For å utføre en oppgave, bruker en klient hjelp fra tjenester. Et klientprogram kan for eksempel laste opp bilder fra bildelagringstjenesten i et digitalt kamera, laste ned bildene til en vedvarende lagringstjeneste som tilbys av en diskstasjon, og sende en side med miniatyrstørrelser av bildene til utskriftstjenesten til en fargeskriver. I dette eksemplet bygger klientprogrammet et distribuert system bestående av seg selv, bildelagringstjenesten, den vedvarende lagringstjenesten og fargetrykk-tjenesten. Klienten og tjenestene til dette distribuerte systemet jobber sammen for å utføre oppgaven: å laste ned og lagre bilder fra et digitalt kamera og skrive ut en miniatyrside.

Ideen bak ordet føderasjon er basert på Jini-synet på nettverket - det er ikke en sentral kontrollerende myndighet. Fordi ingen tjenester har ansvaret, danner settet med alle tilgjengelige tjenester i nettverket en føderasjon - en gruppe som består av like jevnaldrende. I stedet for en sentral myndighet gir Ninis kjøretidsinfrastruktur bare en måte for klienter og tjenester å finne hverandre (via en oppslagstjeneste, som lagrer en katalog med tilgjengelige tjenester). Etter at tjenester har funnet hverandre, er de alene. Klienten og dens vervet tjenester utfører oppgaven uavhengig av Jini-kjøretidsinfrastrukturen. Hvis Jini-oppslagstjenesten krasjer, kan distribuerte systemer samlet via oppslagstjenesten før den krasjet, fortsette arbeidet. Jini inkluderer til og med en nettverksprotokoll som klienter kan bruke for å finne tjenester i fravær av en oppslagstjeneste.

Hvordan Jini fungerer

Jini definerer en kjøretidsinfrastruktur som ligger i nettverket og gir mekanismer som gjør det mulig for deg å legge til, fjerne, finne og få tilgang til tjenester. Kjøretidsinfrastrukturen ligger i nettverket tre steder: i oppslagstjenester som sitter i nettverket; hos tjenesteleverandørene (for eksempel Jini-aktiverte enheter); og hos klienter. Oppslagstjenester er den sentrale organiseringsmekanismen for Jini-baserte systemer. Når nye tjenester blir tilgjengelige i nettverket, registrerer de seg med en oppslagstjeneste. Når klienter ønsker å finne en tjeneste for å hjelpe deg med noen oppgaver, konsulterer de en oppslagstjeneste.

Kjøretidsinfrastrukturen bruker en protokoll på nettverksnivå, kalt oppdagelse, og to objektnivåprotokoller, kalt bli med og se opp. Discovery gjør det mulig for klienter og tjenester å finne oppslagstjenester. Join gjør det mulig for en tjeneste å registrere seg i en oppslagstjeneste. Oppslag gjør det mulig for en klient å spørre etter en oppslagstjeneste etter tjenester som kan hjelpe klienten med å nå sine mål.

Oppdagelsesprosessen

Discovery fungerer slik: Tenk deg at du har en Jini-aktivert diskstasjon som tilbyr en vedvarende lagringstjeneste. Så snart du kobler stasjonen til nettverket, sender den a kunngjøring om tilstedeværelse ved å slippe en multicast-pakke på en kjent port. Inkludert i nærværsmeldingen er en IP-adresse og portnummer der diskstasjonen kan kontaktes av en oppslagstjeneste.

Oppslagstjenester overvåker den velkjente porten for pakker for tilstedeværelse. Når en oppslagstjeneste mottar en tilstedeværelsesmelding, åpnes den og inspiserer pakken. Pakken inneholder informasjon som gjør det mulig for oppslagstjenesten å avgjøre om den skal kontakte avsenderen av pakken eller ikke. I så fall kontakter den avsenderen direkte ved å opprette en TCP-forbindelse til IP-adressen og portnummeret ekstrahert fra pakken. Ved hjelp av RMI sender oppslagstjenesten et objekt, kalt a service registrar, over nettverket til opphavsmannen til pakken. Hensikten med service registrar objektet er å legge til rette for videre kommunikasjon med oppslagstjenesten. Ved å påkalle metoder på dette objektet, kan avsenderen av kunngjøringspakken utføre sammenføyning og oppslag i oppslagstjenesten. Når det gjelder diskstasjonen, vil oppslagstjenesten opprette en TCP-tilkobling til diskstasjonen og sende den et tjenestegistratorobjekt, gjennom hvilken diskstasjonen deretter vil registrere sin vedvarende lagringstjeneste via tilknytningsprosessen.

Bli med prosessen

Når en tjenesteleverandør har et tjeneste registrar-objekt, som er sluttproduktet av oppdagelsen, er det klart for å bli med - for å bli en del av føderasjonen av tjenester som er registrert i oppslagstjenesten. For å bli med, påkaller tjenesteleverandøren registrere() metode på tjenestegistratorobjektet, og sender som parameter et objekt som kalles a serviceelement, en bunke med objekter som beskriver tjenesten. De registrere() metoden sender en kopi av tjenesteelementet opp til oppslagstjenesten, hvor tjenesteelementet er lagret. Når dette er fullført, har tjenesteleverandøren fullført tilknytningsprosessen: tjenesten har blitt registrert i oppslagstjenesten.

Tjenesteelementet er en container for flere objekter, inkludert et objekt som kalles a tjenesteobjekt, hvilke klienter kan bruke til å samhandle med tjenesten. Tjenesteelementet kan også omfatte et hvilket som helst antall attributter, som kan være et hvilket som helst objekt. Noen potensielle attributter er ikoner, klasser som gir GUI-er for tjenesten, og objekter som gir mer informasjon om tjenesten.

Tjenesteobjekter implementerer vanligvis ett eller flere grensesnitt som klienter samhandler med tjenesten gjennom. For eksempel er en oppslagstjeneste en Jini-tjeneste, og dens serviceobjekt er tjenestegistratoren. De registrere() metode påkalt av tjenesteleverandører under sammenkobling er erklært i Tjenesteregistrator grensesnitt, som alle service registrar objekter implementerer. Kunder og tjenesteleverandører snakker med oppslagstjenesten gjennom tjenestens registrarobjekt ved å påkalle metoder som er angitt i Tjenesteregistrator grensesnitt. På samme måte vil en diskstasjon gi et serviceobjekt som implementerte et velkjent lagringstjenestegrensesnitt. Kunder vil slå opp og samhandle med diskstasjonen ved hjelp av dette lagringstjenestegrensesnittet.

Oppslagsprosessen

Når en tjeneste har registrert seg med en oppslagstjeneste via tilknytningsprosessen, er den tjenesten tilgjengelig for bruk av klienter som spør etter oppslagstjenesten. For å bygge et distribuert tjenestesystem som vil jobbe sammen for å utføre noen oppgaver, må en klient finne og verve hjelp fra de enkelte tjenestene. For å finne en tjeneste, spør kunder om oppslagstjenester via en prosess som kalles se opp.

For å utføre et oppslag påkaller en klient se opp() metode på et service registrar objekt. (En klient, i likhet med en tjenesteleverandør, får en tjenestegistrator gjennom oppdagelsesprosessen, som beskrevet tidligere i denne artikkelen.) Klienten sender som et argument til se opp() en tjenestemal, et objekt som fungerer som søkekriterier for spørringen. Servicemalen kan inneholde en referanse til en rekke Klasse gjenstander. Disse Klasse objekter angir for oppslagstjenesten Java-typen (eller typene) av tjenesteobjektet som ønsket av klienten. Servicemalen kan også inneholde en tjeneste-ID, som unikt identifiserer en tjeneste, og attributter, som nøyaktig må samsvare med attributtene som er lastet opp av tjenesteleverandøren i tjenesteelementet. Servicemalen kan også inneholde jokertegn for alle disse feltene. Et jokertegn i tjeneste-ID-feltet vil for eksempel matche enhver tjeneste-ID. De se opp() metoden sender tjenestemalen til oppslagstjenesten, som utfører spørringen og sender null tilbake til mange samsvarende tjenesteobjekter. Klienten får en referanse til de matchende tjenesteobjektene som returverdien av se opp() metode.

Generelt sett ser en klient opp en tjeneste etter Java-type, vanligvis et grensesnitt. For eksempel, hvis en klient trengte å bruke en skriver, ville den komponere en tjenestemal som inkluderte en Klasse objekt for et kjent grensesnitt til skrivertjenester. Alle skrivertjenester vil implementere dette velkjente grensesnittet. Oppslagstjenesten returnerer et tjenesteobjekt (eller objekter) som implementerte dette grensesnittet. Attributter kan inkluderes i tjenestemalen for å begrense antall treff for et slikt typebasert søk. Klienten vil bruke skrivertjenesten ved å påkalle serviceobjektmetodene som er angitt i det velkjente grensesnittet for skrivertjeneste.

Separasjon av grensesnitt og implementering

Jinis arkitektur bringer objektorientert programmering til nettverket ved å gjøre det mulig for nettverkstjenester å dra nytte av en av de grunnleggende tingene for objektorientert programmering: separasjon av grensesnitt og implementering. Et serviceobjekt kan for eksempel gi klienter tilgang til tjenesten på mange måter. Objektet kan faktisk representere hele tjenesten, som lastes ned til klienten under oppslag og deretter utføres lokalt. Alternativt kan tjenesteobjektet bare tjene som en proxy til en ekstern server. Når klienten påkaller metoder på tjenesteobjektet, sender den forespørslene over hele nettverket til serveren, som gjør det virkelige arbeidet. Det lokale tjenesteobjektet og en ekstern server kan også gjøre en del av arbeidet.

En viktig konsekvens av Jinis arkitektur er at nettverksprotokollen som brukes til å kommunisere mellom et proxy-tjenesteobjekt og en ekstern server, ikke trenger å være kjent for klienten. Som illustrert i figuren nedenfor er nettverksprotokollen en del av tjenestens implementering. Denne protokollen er en privat sak som er bestemt av utvikleren av tjenesten. Klienten kan kommunisere med tjenesten via denne private protokollen fordi tjenesten injiserer noe av sin egen kode (tjenesteobjektet) i klientens adresseområde. Det injiserte serviceobjektet kunne kommunisere med tjenesten via RMI, CORBA, DCOM, noe hjemmebrygget protokoll bygget på toppen av stikkontakter og strømmer eller noe annet. Klienten trenger rett og slett ikke å bry seg om nettverksprotokoller, fordi den kan snakke med det velkjente grensesnittet som tjenesteobjektet implementerer. Tjenesteobjektet tar seg av all nødvendig kommunikasjon på nettverket.

Ulike implementeringer av samme tjenestegrensesnitt kan bruke helt forskjellige implementeringsmetoder og helt forskjellige nettverksprotokoller. En tjeneste kan bruke spesialisert maskinvare for å oppfylle klientforespørsler, eller den kan gjøre alt sitt arbeid med programvare. Faktisk kan implementeringsmetoden som tas av en enkelt tjeneste utvikle seg over tid. Klienten kan være sikker på at den har et serviceobjekt som forstår den nåværende implementeringen av tjenesten, fordi klienten mottar serviceobjektet (ved hjelp av oppslagstjenesten) fra selve tjenesteleverandøren. For klienten ser en tjeneste ut som det velkjente grensesnittet, uavhengig av hvordan tjenesten implementeres.

Konklusjon

Som vi har sett i denne innledende kolonnen, prøver Jini å heve abstraksjonsnivået for distribuert systemprogrammering, fra nettverksprotokollnivået til objektgrensesnittnivået. I den voksende spredningen av innebygde enheter koblet til nettverk, kan mange deler av et distribuert system komme fra forskjellige leverandører. Jini gjør det unødvendig for leverandører av enheter å bli enige om nettverksprotokoller som lar enhetene deres samhandle. I stedet må leverandører bli enige om Java-grensesnitt som enhetene deres kan samhandle med. Prosessene med å oppdage, bli med og slå opp, levert av Jini-kjøretidsinfrastrukturen, vil gjøre det mulig for enheter å finne hverandre i nettverket. Når de har funnet hverandre, vil enhetene kunne kommunisere med hverandre via Java-grensesnitt.

Neste måned

Selv om denne kolonnen hovedsakelig vil fokusere på hvordan man kan løse spesifikke programmeringsproblemer ved hjelp av Jini, for eksempel å legge til et GUI i en tjeneste eller å gjøre en tjeneste administrerbar, skal jeg diskutere Jini's virkelige problemer og potensielle kunder neste måned.

Diskuterer Jini

For å diskutere materialet som presenteres i denne artikkelen, besøk: //www.artima.com/jini/jf/intro/index.html

Bill Venners har skrevet programvare profesjonelt i 14 år. Basert i Silicon Valley, tilbyr han programvarekonsultering og opplæringstjenester og vedlikeholder et nettsted for Java og Jini-utviklere, artima.com. Han er forfatter av boka: Inside the Java Virtual Machine, utgitt av McGraw-Hill.

Lær mer om dette emnet

Besøk Jini Community for informasjon om prosessen som kjente grensesnitt vil bli definert
//www.jini.org
Last ned side for den nåværende Jini-utgivelsen (ved Java Developer Connection)
//developer.java.sun.com/developer/products/jini
Last ned side for JDK 1.2 FCS Release, der den nåværende Jini-utgivelsen kjører
//java.sun.com/products/jdk/1.2/
En online Jini-opplæring
//pandonia.canberra.edu.au/java/jini/tutorial/Jini.xml
Online forelesningsnotater for et kurs om RMI og Jini
//www.eli.sdsu.edu/courses/spring99/cs696/notes/index.html
"The Network Revolution," Clyde Higaki og Bill Venners (Suns Jini Technology Homepage, 1999). Forfatterne Clyde Higaki og Bill Venners tilbyr en rekke scenarier for å beskrive hvordan Jini kan brukes i den virkelige verden
//java.sun.com/features/1999/01/jini_scenario.html
Lenker til Jini-ressurser
//www.artima.com/jini/resources/index.html
Den viktigste Jini-siden på Sun
//java.sun.com/products/jini/
Jini Community, det sentrale nettstedet for interaksjon mellom undertegnere av Jini Sun Community Source License
//www.jini.org
Last ned side for alle Jini-spesifikasjonene
//java.sun.com/products/jini/specs/
JINI-USERS postliste arkiver. For å abonnere på JINI-USERS adresseliste, send e-post til [email protected]. Skriv inn meldingen abonner jini-brukere
//archives.java.sun.com/archives/jini-users.html
Vanlige spørsmål om Jini for adresselisten til JINI-USERS
//www.artima.com/jini/faq.html