Jini: Ny teknologi til en netværksnetværk

Forrige 1 2 Side 2 Side 2 af 2

Jini i sammenhæng

Traditionelt er operativsystemer designet med den antagelse, at en computer vil have en processor, noget hukommelse og en disk. Når du starter en computer, er det første, det gør, at kigge efter en disk. Hvis den ikke finder en disk, kan den ikke fungere som en computer. I stigende grad vises computere imidlertid i en anden forklædning: som indlejrede enheder, der har en processor, noget hukommelse og en netværksforbindelse - men ingen disk. Det første, en mobiltelefon gør, når du f.eks. Starter den, er at kigge efter telefonnettet. Hvis det ikke finder netværket, kan det ikke fungere som en mobiltelefon. Denne tendens i hardwaremiljøet, fra disk-centreret til netværks-centreret, vil påvirke, hvordan vi organiserer vores software - og det er her Jini kommer ind.

Jini er et forsøg på at genoverveje computerarkitektur i betragtning af den stigende betydning af netværket og spredning af processorer i enheder, der ikke har noget diskdrev. Disse enheder, som kommer fra mange forskellige leverandører, skal interagere over et netværk. Selve netværket vil være meget dynamisk - enheder og tjenester tilføjes og fjernes regelmæssigt. Jini tilbyder mekanismer, der muliggør problemfri tilføjelse, fjernelse og søgning af enheder og tjenester på netværket. Derudover leverer Jini en programmeringsmodel, der gør det lettere for programmører at få deres enheder til at tale med hinanden.

Jini forsøger at udvide Java, objektserialisering og RMI, som gør det muligt for objekter at bevæge sig rundt i netværket fra virtuel maskine til virtuel maskine, og udvide fordelene ved objektorienteret programmering til netværket. I stedet for at kræve, at enhedsleverandører er enige om netværksprotokollerne, hvorigennem deres enheder kan interagere, giver Jini enhederne mulighed for at tale med hinanden via grænseflader til objekter.

Hvad er Jini?

Jini er et sæt API'er og netværksprotokoller, der kan hjælpe dig med at opbygge og implementere distribuerede systemer, der er organiseret som sammenslutninger af tjenester. EN service kan være alt, hvad der sidder på netværket og er klar til at udføre en nyttig funktion. Hardwareenheder, software, kommunikationskanaler - selv menneskelige brugere selv - kan være tjenester. Et Jini-aktiveret diskdrev kan for eksempel tilbyde en "opbevaringstjeneste". En Jini-aktiveret printer kan tilbyde en "udskrivningstjeneste". EN sammenslutning af tjenester derefter er der et sæt tjenester, der i øjeblikket er tilgængelige på netværket, som en klient (hvilket betyder et program, en tjeneste eller en bruger) kan samle for at hjælpe den med at nå et mål.

For at udføre en opgave beder en klient sig om hjælp fra tjenester. Et klientprogram kan f.eks. Uploade billeder fra billedlagertjenesten i et digitalt kamera, downloade billederne til en vedvarende lagertjeneste, der tilbydes af et diskdrev, og sende en side med miniaturestørrelser af billederne til udskrivningstjenesten i en farveprinter. I dette eksempel bygger klientprogrammet et distribueret system bestående af sig selv, billedopbevaringstjenesten, den vedvarende opbevaringstjeneste og farveudskrivningstjenesten. Klienten og tjenesterne i dette distribuerede system arbejder sammen om at udføre opgaven: at downloade og gemme billeder fra et digitalt kamera og udskrive en side med miniaturer.

Ideen bag ordet føderation er baseret på Jini-synet på netværket - der er ikke en central kontrolmyndighed. Da ingen tjenester har ansvaret, udgør sættet af alle tilgængelige tjenester på netværket en føderation - en gruppe sammensat af lige jævnaldrende. I stedet for en central myndighed giver Ninis runtime-infrastruktur kun en måde for klienter og tjenester at finde hinanden på (via en opslagstjeneste, der gemmer en mappe med aktuelt tilgængelige tjenester). Efter at tjenester har fundet hinanden, er de alene. Klienten og dens hyrede tjenester udfører deres opgave uafhængigt af Jini-runtime-infrastrukturen. Hvis Jini-opslagstjenesten går ned, kan distribuerede systemer samlet via opslagstjenesten, før den styrtede, fortsætte deres arbejde. Jini inkluderer endda en netværksprotokol, som klienter kan bruge til at finde tjenester i fravær af en opslagstjeneste.

Hvordan Jini fungerer

Jini definerer en runtime-infrastruktur der findes på netværket og giver mekanismer, der giver dig mulighed for at tilføje, fjerne, lokalisere og få adgang til tjenester. Runtime-infrastrukturen ligger på netværket tre steder: i opslagstjenester, der sidder på netværket; i tjenesteudbydere (såsom Jini-aktiverede enheder); og hos klienter. Opslagstjenester er den centrale organiseringsmekanisme for Jini-baserede systemer. Når nye tjenester bliver tilgængelige på netværket, registrerer de sig selv med en opslagstjeneste. Når klienter ønsker at finde en tjeneste for at hjælpe med en opgave, konsulterer de en opslagstjeneste.

Runtime-infrastrukturen bruger en netværksniveauprotokol, kaldet opdagelseog to protokol på objektniveau kaldet tilslutte og kig op. Discovery gør det muligt for klienter og tjenester at finde opslagstjenester. Deltagelse gør det muligt for en tjeneste at registrere sig selv i en opslagstjeneste. Opslag gør det muligt for en klient at søge efter en opslagstjeneste efter tjenester, der kan hjælpe klienten med at nå sine mål.

Opdagelsesprocessen

Discovery fungerer således: Forestil dig, at du har et Jini-aktiveret diskdrev, der tilbyder en vedvarende opbevaringstjeneste. Så snart du forbinder drevet til netværket, sender det en meddelelse om tilstedeværelse ved at droppe en multicast-pakke på en velkendt port. Inkluderet i tilstedeværelsesmeddelelsen er en IP-adresse og et portnummer, hvor diskdrevet kan kontaktes af en opslagstjeneste.

Opslagstjenester overvåger den velkendte port for tilstedeværelsesmeddelelsespakker. Når en opslagstjeneste modtager en tilstedeværelsesmeddelelse, åbner den og inspicerer pakken. Pakken indeholder information, der gør det muligt for opslagstjenesten at afgøre, om den skal kontakte afsenderen af pakken. Hvis det er tilfældet, kontakter det afsenderen direkte ved at oprette en TCP-forbindelse til IP-adressen og portnummeret, der er ekstraheret fra pakken. Ved hjælp af RMI sender opslagstjenesten et objekt, kaldet a service registrar, på tværs af netværket til pakkens ophavsmand. Formålet med objektregistratorobjektet er at lette yderligere kommunikation med opslagstjenesten. Ved at påkalde metoder på dette objekt kan afsenderen af meddelelsespakken udføre tilslutning og opslag i opslagstjenesten. I tilfælde af diskdrev ville opslagstjenesten oprette en TCP-forbindelse til diskdrevet og sende det et service-registrarobjekt, hvorigennem diskdrevet derefter ville registrere sin vedvarende lagertjeneste via tilslutningsprocessen.

Tilslutningsprocessen

Når en tjenesteudbyder har et service registrar-objekt, slutproduktet af opdagelsen, er det klar til at deltage - for at blive en del af sammenslutningen af tjenester, der er registreret i opslagstjenesten. For at tilmelde dig påkalder tjenesteudbyderen Tilmeld() metode på service registrar objektet, og videresender som parameter et objekt kaldet a servicepost, et bundt med objekter, der beskriver tjenesten. Det Tilmeld() metode sender en kopi af serviceelementet op til opslagstjenesten, hvor serviceposten er gemt. Når dette er afsluttet, har tjenesteudbyderen afsluttet tilslutningsprocessen: dens service er blevet registreret i opslagstjenesten.

Serviceposten er en container til flere objekter, inklusive et objekt kaldet a service objekt, hvilke klienter kan bruge til at interagere med tjenesten. Serviceposten kan også omfatte et hvilket som helst antal egenskaber, som kan være ethvert objekt. Nogle potentielle attributter er ikoner, klasser, der giver GUI'er til tjenesten, og objekter, der giver mere information om tjenesten.

Tjenesteobjekter implementerer normalt en eller flere grænseflader, gennem hvilke klienter interagerer med tjenesten. For eksempel er en opslagstjeneste en Jini-tjeneste, og dens tjenesteobjekt er serviceregistratoren. Det Tilmeld() metode, der påberåbes af tjenesteudbydere under tilslutning, er angivet i Service Registrering interface, som alle service registrar objekter implementerer. Kunder og tjenesteudbydere taler med opslagstjenesten gennem service registrar-objektet ved at påkalde metoder, der er angivet i Service Registrering interface. Ligeledes ville et diskdrev tilvejebringe et serviceobjekt, der implementerede et velkendt lagertjenesteinterface. Klienter ser op og interagerer med diskdrevet ved hjælp af denne lagertjenestegrænseflade.

Opslagsprocessen

Når en tjeneste er registreret hos en opslagstjeneste via tilslutningsprocessen, er denne service tilgængelig til brug for klienter, der spørger om den opslagstjeneste. For at opbygge et distribueret servicesystem, der vil arbejde sammen for at udføre en opgave, skal en klient finde og hente hjælp fra de enkelte tjenester. For at finde en service spørger klienter opslagstjenester via en proces kaldet kig op.

For at foretage et opslag påberåber en klient sig kig op() metode på et service registrar objekt. (En klient får, ligesom en tjenesteudbyder, en service-registrator gennem opdagelsesprocessen, som beskrevet tidligere i denne artikel.) Klienten videregiver som et argument til kig op() -en serviceskabelon, et objekt, der fungerer som søgekriterier for forespørgslen. Serviceskabelonen kan indeholde en henvisning til en matrix af Klasse genstande. Disse Klasse objekter angiver til opslagstjenesten Java-typen (eller -typerne) for det serviceobjekt, som klienten ønsker. Serviceskabelonen kan også omfatte en service-id, der entydigt identificerer en tjeneste, og attributter, som nøjagtigt skal matche de attributter, der er uploadet af tjenesteudbyderen i tjenesteemnet. Serviceskabelonen kan også indeholde jokertegn til et af disse felter. Et jokertegn i tjeneste-id-feltet vil f.eks. Matche ethvert service-id. Det kig op() metode sender serviceskabelonen til opslagstjenesten, som udfører forespørgslen og sender nul tilbage til mange matchende serviceobjekter. Klienten får en henvisning til de matchende serviceobjekter som returværdien af kig op() metode.

Generelt ser en klient en tjeneste efter Java-type, normalt en grænseflade. For eksempel, hvis en klient skulle bruge en printer, ville den komponere en serviceskabelon, der indeholdt en Klasse objekt for en velkendt grænseflade til printertjenester. Alle printertjenester vil implementere denne velkendte grænseflade. Opslagstjenesten returnerer et serviceobjekt (eller objekter), der implementerede denne grænseflade. Attributter kan inkluderes i serviceskabelonen for at indsnævre antallet af matches for en sådan typebaseret søgning. Klienten ville bruge printertjenesten ved at påberåbe sig de serviceobjektmetoder, der er angivet i den velkendte printertjenesteinterface.

Adskillelse af interface og implementering

Jinis arkitektur bringer objektorienteret programmering til netværket ved at gøre det muligt for netværkstjenester at drage fordel af et af de grundlæggende elementer i objektorienteret programmering: adskillelse af interface og implementering. For eksempel kan et serviceobjekt give klienter adgang til tjenesten på mange måder. Objektet kan faktisk repræsentere hele tjenesten, som downloades til klienten under opslag og derefter udføres lokalt. Alternativt kan tjenesteobjektet kun tjene som en proxy til en fjernserver. Når klienten påkalder metoder på serviceobjektet, sender den anmodningerne på tværs af netværket til serveren, hvilket gør det rigtige arbejde. Det lokale serviceobjekt og en fjernserver kan hver også udføre en del af arbejdet.

En vigtig konsekvens af Jinis arkitektur er, at netværksprotokollen, der bruges til at kommunikere mellem et proxytjenesteobjekt og en fjernserver, ikke behøver at være kendt for klienten. Som illustreret i nedenstående figur er netværksprotokollen en del af tjenestens implementering. Denne protokol er en privat sag, der er besluttet af udvikleren af tjenesten. Klienten kan kommunikere med tjenesten via denne private protokol, fordi tjenesten injicerer noget af sin egen kode (serviceobjektet) i klientens adresseområde. Det indsprøjtede serviceobjekt kunne kommunikere med tjenesten via RMI, CORBA, DCOM, en hjemmebrygget protokol bygget oven på stikkontakter og streams eller noget andet. Klienten behøver simpelthen ikke bekymre sig om netværksprotokoller, fordi den kan tale med den velkendte grænseflade, som serviceobjektet implementerer. Serviceobjektet tager sig af al nødvendig kommunikation på netværket.

Forskellige implementeringer af den samme servicegrænseflade kan bruge helt forskellige implementeringsmetoder og helt forskellige netværksprotokoller. En tjeneste kan bruge specialhardware til at opfylde klientanmodninger, eller den kan udføre alt sit arbejde i software. Faktisk kan implementeringsmetoden fra en enkelt tjeneste udvikle sig over tid. Klienten kan være sikker på, at den har et serviceobjekt, der forstår den aktuelle implementering af tjenesten, fordi klienten modtager serviceobjektet (ved hjælp af opslagstjenesten) fra selve tjenesteudbyderen. For klienten ser en tjeneste ud som den velkendte grænseflade, uanset hvordan tjenesten implementeres.

Konklusion

Som vi har set i denne indledende kolonne, forsøger Jini at hæve abstraktionsniveauet for programmering af distribuerede systemer fra netværksprotokolniveauet til objektgrænsefladeniveauet. I den nye spredning af indlejrede enheder forbundet til netværk kan mange stykker af et distribueret system komme fra forskellige leverandører. Jini gør det unødvendigt for leverandører af enheder at blive enige om netværksniveauprotokoller, der gør det muligt for deres enheder at interagere. I stedet skal leverandører være enige om Java-grænseflader, gennem hvilke deres enheder kan interagere. Processerne med opdagelse, tilslutning og opslag, leveret af Jini-runtime-infrastrukturen, gør det muligt for enheder at finde hinanden på netværket. Når de finder hinanden, kan enheder kommunikere med hinanden via Java-grænseflader.

Næste måned

Selvom denne kolonne primært vil fokusere på, hvordan man løser specifikke programmeringsproblemer ved hjælp af Jini, såsom at tilføje en GUI til en tjeneste eller gøre en tjeneste administrerbar, vil jeg næste måned diskutere Jini's virkelige problemer og udsigter.

Diskuterer Jini

For at diskutere det materiale, der præsenteres i denne artikel, skal du besøge: //www.artima.com/jini/jf/intro/index.html

Bill Venners har skrevet software professionelt i 14 år. Baseret i Silicon Valley leverer han softwarekonsulent- og træningstjenester og vedligeholder et websted for Java og Jini-udviklere, artima.com. Han er forfatter til bogen: Inside the Java Virtual Machine, udgivet af McGraw-Hill.

Lær mere om dette emne

Besøg Jini Community for information om den proces, hvorved kendte grænseflader vil blive defineret
//www.jini.org
Download side til den aktuelle Jini-udgivelse (ved Java Developer Connection)
//developer.java.sun.com/developer/products/jini
Download-side til JDK 1.2 FCS Release, hvor den aktuelle Jini-version kører
//java.sun.com/products/jdk/1.2/
En online Jini-vejledning
//pandonia.canberra.edu.au/java/jini/tutorial/Jini.xml
Online forelæsningsnotater til et kursus om RMI og Jini
//www.eli.sdsu.edu/courses/spring99/cs696/notes/index.html
"Netværksrevolutionen", Clyde Higaki og Bill Venners (Suns Jini Technology-hjemmeside, 1999). Forfatterne Clyde Higaki og Bill Venners tilbyder en række scenarier for at beskrive, hvordan Jini kan bruges i den virkelige verden
//java.sun.com/features/1999/01/jini_scenario.html
Links til Jini-ressourcer
//www.artima.com/jini/resources/index.html
Den vigtigste Jini-side på Sun
//java.sun.com/products/jini/
Jini Community, det centrale sted for interaktion mellem underskrivere af Jini Sun Community Source License
//www.jini.org
Download side for alle Jini specifikationer
//java.sun.com/products/jini/specs/
JINI-USERS mailingliste arkiver. Send e-mail til for at abonnere på JINI-USERS mailingliste [email protected]. Skriv i tekstens hovedtekst abonner jini-brugere
//archives.java.sun.com/archives/jini-users.html
En Jini FAQ til JINI-USERS mailingliste
//www.artima.com/jini/faq.html