Programmering

Gjør plass til JavaSpaces, del 1

Denne artikkelen begynner en annen tråd av Jiniologi serie. I juni lanserte Bill Venners Jiniologi med en oversikt over Jini-teknologi - en kraftig ny infrastruktur for å bygge og distribuere distribuerte systemer som er organisert som tjenesteforbund. Denne tråden, som vil bli omtalt annenhver måned i denne kolonnen, fokuserer på JavaSpaces, en kjernetjeneste fra Sun Microsystems som gir et høyt nivå for å lage samarbeidende og distribuerte applikasjoner. Hvis du bygger applikasjoner med Jini, vil du vite hvordan du bruker JavaSpaces for å koordinere deltakerne i en Jini-føderasjon. Men det er også viktig å huske at du kan bruke JavaSpaces separat fra Jini, som et verktøy for å bygge generelle distribuerte systemer i Java. I begge tilfeller er JavaSpaces verdt å se, fordi det kan lette design og koding av distribuerte applikasjoner betydelig.

Gi plass til JavaSpaces: Les hele serien!

  • Del 1. Lett utviklingen av distribuerte apper med JavaSpaces
  • Del 2. Bygg en beregningsserver med JavaSpaces
  • Del 3. Koordinere Jini-appene dine med JavaSpaces
  • Del 4. Utforsk Jini-transaksjoner med JavaSpaces
  • Del 5. Gjør databehandlingsserveren robust og skalerbar

I denne serien vil vi begynne med å introdusere deg for den unike JavaSpaces programmeringsmodellen, som er ganske forskjellig fra andre nettverks- og distribuerte verktøy som du kanskje er kjent med. I påfølgende artikler vil vi dekke detaljene i JavaSpaces API og hvordan du kan bruke den til å lime prosesser sammen i et distribuert program, og beskrive hvordan JavaSpaces samhandler med andre komponenter i Jini. Gjennom hele serien ser du at JavaSpaces er enkelt (API-en består bare av en håndfull operasjoner), uttrykksfull (et stort antall problemer kan løses ved hjelp av JavaSpaces) og kraftig (du kan bygge sofistikerte distribuerte systemer med små mengder av JavaSpaces-kode).

La oss komme i gang.

En ny distribuert datamodell

Å bygge distribuerte applikasjoner med konvensjonelle nettverksverktøy innebærer vanligvis å sende meldinger mellom prosesser eller påkalle metoder på eksterne objekter. I JavaSpaces-applikasjoner kommuniserer prosesser derimot ikke direkte, men koordinerer i stedet aktivitetene sine ved å utveksle objekter gjennom en rom, eller delt minne. En prosess kan skrive nye objekter inn i et rom, ta gjenstander fra et rom, eller lese (lage en kopi av) objekter i et rom; Figur 1 viser flere prosesser (representert av hertugene) som interagerer med mellomrom ved hjelp av disse operasjonene. Når du tar eller leser objekter, bruker prosesser enkel matching, basert på verdiene til feltene, for å finne gjenstandene som betyr noe for dem. Hvis et samsvarende objekt ikke blir funnet umiddelbart, kan en prosess vente til en ankommer. I motsetning til konvensjonelle objektbutikker endrer prosesser i JavaSpaces ikke objekter i rommet eller påkaller metodene deres direkte - mens det er objekter bare passive data. For å modifisere et objekt, må en prosess eksplisitt fjerne det, oppdatere det og sette det inn i rommet igjen.

Spaces er objektbutikker med flere viktige egenskaper som bidrar til å gjøre JavaSpaces til et kraftig, uttrykksfullt verktøy. La oss se nærmere på:

  • Plasser deles: Mange eksterne prosesser kan samhandle med et rom samtidig - selve plassen håndterer detaljene for samtidig tilgang, slik at du kan fokusere på utformingen av høynivåprotokollene mellom prosessene dine.

  • Plassene er vedvarende: Plasser gir pålitelig lagring av gjenstander. Når du lagrer et objekt i et rom, vil det forbli der på ubestemt tid til det blir fjernet. Du kan også be om en leietid hvor et objekt skal lagres. Når det er lagret i rommet, vil et objekt forbli der til leietiden (som kan fornyes) er over, eller til en prosess eksplisitt fjerner den. Vi vil diskutere leieavtaler nærmere, senere i denne serien.

  • Plasser er assosiative: Objekter i et rom er lokalisert via assosiativ oppslag, ikke etter minneplassering eller etter identifikator. Associativ oppslag gir et enkelt middel for å finne gjenstandene du er interessert i, i henhold til innholdet, uten å måtte vite hva objektet heter, hvem som opprettet det, eller hvor det er lagret. For å slå opp et objekt, oppretter du et mal (et objekt med noen eller alle feltene satt til bestemte verdier, og de andre er igjen som null å fungere som jokertegn). Et objekt i rommet samsvarer med en mal hvis det samsvarer nøyaktig med malens angitte felt. Du vil se at med assosiativ oppslag kan du enkelt uttrykke spørsmål om objekter som "Er det noen oppgaver å beregne?" eller "Er det noen svar på hovedfaktoren jeg ba om?"

  • Plasser er transaksjonelt sikre: JavaSpaces bruker Ninis transaksjonstjeneste for å sikre at en operasjon i et rom er atomisk (enten operasjonen blir brukt, eller ikke). Transaksjoner støttes for enkeltoperasjoner på ett mellomrom, samt flere operasjoner over ett eller flere mellomrom (enten alle operasjonene blir brukt, eller ingen er). Som du vil se senere i serien, er transaksjoner en viktig måte å takle delvis feil på.

  • Mellomrom lar deg utveksle kjørbart innhold: Mens du er i et rom, er objekter bare passive data - du kan ikke endre dem eller påkalle metodene deres. Når du leser eller tar et objekt fra et mellomrom, opprettes det imidlertid en lokal kopi av objektet. Som med ethvert annet lokalt objekt, kan du endre dets offentlige felt og påkalle metodene, selv om du aldri har sett et objekt som det før. Denne muligheten gir deg en kraftig mekanisme for å utvide oppførselen til applikasjonene dine gjennom et mellomrom.

Etter hvert som denne serien skrider frem, vil vi vise deg hvordan disse egenskapene spiller en nøkkelrolle i å la deg lage distribuerte applikasjoner som fungerer bra i Jini-miljøet, der nettverk ofte er spontan, og prosesser blir med og forlater beregningen dynamisk, noen ganger på grunn av enhet nettverksfeil.

Opprinnelsen til JavaSpaces

Vi har beskrevet JavaSpaces som en ny distribuert datamodell, men dens opprinnelse kan spores tilbake til Yale University på begynnelsen av 1980-tallet. Der utviklet Dr. David Gelernter et verktøy som heter Linda for å lage distribuerte applikasjoner. Linda består av et lite antall operasjoner kombinert med en vedvarende butikk kalt a dobbeltrom. Disse operasjonene er ortogonale i forhold til et bestemt programmeringsspråk; de er en del av en koordineringsspråk som kan legges til andre beregningsspråk. Resultatet av Linda-forskningen var overraskende: ved å bruke en objektbutikk sammen med et lite antall enkle operasjoner, kan du enkelt implementere en stor klasse av parallelle og distribuerte problemer ved hjelp av teknikker som lindrer mange av fallgruvene ved å bygge nettverkssystemer. Med andre ord er rombaserte systemer ikke bare enkle (krever bare noen få operasjoner), men også uttrykksfulle (egner seg godt til å løse mange distribuerte problemer).

Dr. Gelernters arbeid inspirerte Suns JavaSpaces-tjeneste, og påvirket også utformingen av oppslags- og oppdagelseskomponentene til kjernen Jini-teknologi (som du vil se som Jiniologi serien skrider frem). Mens JavaSpaces arvet rommodellen fra Linda, har designerne av JavaSpaces oppdatert modellen på betydelige måter og utnyttet kraften til Java-objekter, Jini, RMI og objektserialisering.

JavaSpaces i sammenheng

Beskrivelsen vår til nå har vært litt abstrakt, så la oss se på noen få eksempler på ekte distribuerte applikasjoner som du kan modellere som prosesser som utveksler objekter gjennom mellomrom.

Chat-systemer

Tenk på et enkelt chattesystem med flere brukere, der et mellomrom fungerer som et chatteområde som inneholder alle meldingene som utgjør en diskusjon. For å snakke deponerer en deltaker meldingsobjekter i rommet. Alle chat-medlemmer venter på at nye meldingsobjekter skal vises, lese dem og vise innholdet. Sen ankomst kan undersøke de eksisterende meldingsobjektene i rommet for å gjennomgå tidligere diskusjon. Faktisk, siden plassen er vedvarende, kan en ny deltaker se diskusjonen lenge etter at alle andre har gått bort, og deltakerne kan til og med komme tilbake mye senere for å avslutte samtalen der de slapp. Listen over chattedeltakere kan også holdes i rommet og oppdateres når noen blir med eller forlater samtalen.

Beregn servere

Vurder nå å analysere sanntid radioteleskopdata for tegn på utenomjordisk liv (mye som SETI @ home-prosjektet gjør). Slike data er omfattende, og å analysere det er en beregningsintensiv jobb som er godt egnet til parallell beregning av et nettverk av datamaskiner - med andre ord en "beregningsserver". Ved hjelp av JavaSpaces-teknologien skrives en rekke oppgaver - for eksempel en oppgave per del data som må analyseres - inn i rommet. Hver datamaskin som deltar søker i plassen for en oppgave, fjerner den, fullfører det nødvendige beregningsarbeidet, slipper resultatet tilbake i rommet, og fortsetter deretter å lete etter flere oppgaver. Denne tilnærmingen skalerer seg naturlig: den fungerer på samme måte om det er 10 datamaskiner tilgjengelig eller 1000. Tilnærmingen gir også naturlig lastbalansering, siden hver arbeider tar opp akkurat så mye arbeid som den kan takle på en gitt tid, med sakte datamaskiner som gjør mindre arbeid og raske datamaskiner gjør mer.

Meglersystemer

Som et tredje eksempel kan du vurdere et nettauksjonssystem som bringer kjøpere og selgere av varer og tjenester sammen. Anta at du, som en potensiell kjøper, beskriver varen (for eksempel en bil) du vil kjøpe, og prisen du er villig til å betale, pakk informasjonen inn i en oppføring og skriv den resulterende ønsket-å-kjøpe oppføringen til et rom. Samtidig overvåker potensielle selgere kontinuerlig rommet for ankomst av ønsket-å-kjøpe oppføringer som samsvarer med varene i varelageret. For eksempel overvåker Mazda-forhandlere plassen for oppføringer som beskriver Mazdas, mens forhandlere av bruktbiler overvåker plassen for alle forespørsler om bruktbil. Når en samsvarende forespørsel blir funnet og lest, skriver en potensiell selger en budoppføring i rommet, og oppgir en tilbudspris. Som potensiell kjøper overvåker du kontinuerlig budrommet på dine utestående forespørsler, og når du finner en som er akseptabel, fjerner du budene og kontakter selgeren (muligens gjennom plassen via en annen oppføring).

En kort oversikt over API

Nå er det på tide å introdusere JavaSpaces API. Som vi allerede har sagt, er det enkelt; faktisk, i resten av denne artikkelen, vil vi dekke alt du trenger å vite (uten noen mindre detaljer) om det. Imidlertid, før vi beskriver JavaSpace grensesnitt og dets metoder, må vi først snakke om oppføringer.

Innganger

Et objekt som er lagret i et rom kalles et

inngang.

For å være en oppføring trenger et objekt bare å implementere

Inngang

grensesnitt. La oss som et eksempel definere en meldingoppføring som du kan skrive inn i et mellomrom:

importere net.jini.core.entry.Entry;

offentlig klasse Melding implementerer oppføring {public String content;

// en offentlig melding om ikke-arg konstruktør () {}}

Her har vi definert en Beskjed klasse med et strengfelt som inneholder innholdet i meldingen. Fordi vi vil bruke denne klassen med mellomrom, må vi implementere grensesnittet net.jini.core.entry.Entry, som finnes i pakken net.jini.core.entry. Det er viktig å påpeke det Inngang er en markør grensesnitt; med andre ord inneholder grensesnittet ingen konstanter eller metoder og krever derfor ikke noe spesielt arbeid å implementere, annet enn å legge til implementerer inngang til klassedefinisjonen din.

Foruten å implementere Inngang grensesnitt, er det noen få andre konvensjoner som oppføringene våre må følge. Vi vil ha mer å si om årsakene i senere artikler, men foreløpig vil vi bare se på de store omrissene. En oppføring må ha en offentlig konstruktør som ikke tar noen argumenter (en såkalt no-arg konstruktør); Dette kravet stammer fra den underliggende serialisasjonen som oppstår når oppføringer overføres til og ut av mellomrom. Merk at vår definisjon av Beskjed inneholder en no-arg konstruktør. En annen konvensjon er at felt i en oppføring skal erklæres offentlig; Dette lar andre prosesser finne oppføringene dine i mellomrom via assosiativ oppslag, basert på verdiene til disse feltene. En tredje konvensjon er at felt i en oppføring må inneholde referanser til objekter, i stedet for primitive typer (det vil si hvis du trenger å definere et primitivt typefelt som f.eks. int, bør du bruke den tilsvarende innpakningsklassen Heltall i stedet). For å sikre at du dekker alle grunnlagene dine når du definerer oppføringer, anbefaler vi at du refererer til JavaSpaces-prinsipper, mønstre og praksis,eller til Sun Microsystems JavaSpaces Specification for detaljer. Vi vil også, som nevnt, berøre noen av de finere punktene i senere artikler.

Annet enn disse kravene, er en oppføring som alle andre Java-klasser; du kan instantiere den, påkalle metodene og tilordne verdier til sine offentlige felt. Nå som vi har definert en Beskjed inngangsklasse, la oss se hvilke operasjoner som er tilgjengelige for interaksjon med oppføringer i mellomrom.

JavaSpace-grensesnittet

For å samhandle med et rom, må du få tilgang til et objekt som implementerer JavaSpace grensesnitt. Det er mange måter å få tilgang til et slikt objekt (du kan for eksempel bruke Jini-oppslag eller RMI-registeret), og vi vil dekke detaljene for å gjøre det i neste artikkel. For nå vil vi konsentrere oss om JavaSpace grensesnittet selv.

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