Gør plads til JavaSpaces, del 1

Denne artikel begynder en anden tråd af Jiniologi serie. I juni lancerede Bill Venners Jiniologi med et overblik over Jini-teknologi - en kraftfuld ny infrastruktur til opbygning og implementering af distribuerede systemer, der er organiseret som sammenslutninger af tjenester. Denne tråd, som vil blive vist hver anden måned i denne kolonne, fokuserer på JavaSpaces, en Jini-kernetjeneste fra Sun Microsystems, der giver et højt niveau til oprettelse af samarbejdende og distribuerede applikationer. Hvis du bygger applikationer med Jini, vil du gerne vide, hvordan du bruger JavaSpaces til at koordinere deltagerne i en Jini-federation. Men det er også vigtigt at huske, at du kan bruge JavaSpaces separat fra Jini, som et værktøj til at opbygge generelle distribuerede systemer i Java. I begge tilfælde er JavaSpaces et besøg værd, fordi det i væsentlig grad kan lette design og kodning af distribuerede applikationer.

Gør plads til JavaSpaces: Læs hele serien!

Del 1. Nem udviklingen af distribuerede apps med JavaSpaces
Del 2. Byg en beregningsserver med JavaSpaces
Del 3. Koordiner dine Jini-apps med JavaSpaces
Del 4. Undersøg Jini-transaktioner med JavaSpaces
Del 5. Gør din computerserver robust og skalerbar

I denne serie begynder vi med at introducere dig til den unikke JavaSpaces-programmeringsmodel, som er meget forskellig fra andre netværk og distribuerede værktøjer, som du måske er bekendt med. I efterfølgende artikler vil vi dække detaljerne i JavaSpaces API, og hvordan du kan bruge det til at lime processer sammen til en distribueret applikation, og beskrive, hvordan JavaSpaces interagerer med andre komponenter i Jini. I hele serien ser du, at JavaSpaces er enkle (API'en består kun af en håndfuld operationer), ekspressivt (et stort antal problemer kan løses ved hjælp af JavaSpaces) og kraftfuld (du kan opbygge sofistikerede distribuerede systemer med små mængder af JavaSpaces-kode).

Lad os komme igang.

En ny distribueret computermodel

Opbygning af distribuerede applikationer med konventionelle netværksværktøjer indebærer normalt videregivelse af meddelelser mellem processer eller påkaldelse af metoder på eksterne objekter. I JavaSpaces-applikationer kommunikerer processer derimod ikke direkte, men koordinerer i stedet deres aktiviteter ved at udveksle objekter gennem en plads, eller delt hukommelse. En proces kan skrive nye objekter i et rum, tage objekter fra et rum eller Læs (lav en kopi af) objekter i et rum; Figur 1 viser flere processer (repræsenteret af hertuger), der interagerer med rum ved hjælp af disse operationer. Når man tager eller læser objekter, bruger processer simpel matchning baseret på værdierne i felter for at finde de objekter, der betyder noget for dem. Hvis et matchende objekt ikke findes med det samme, kan en proces vente, indtil en ankommer. I modsætning til konventionelle objektbutikker ændrer processer i JavaSpaces ikke objekter i rummet eller påkalder deres metoder direkte - mens der, er objekter bare passive data. For at ændre et objekt skal en proces eksplicit fjerne det, opdatere det og genindsætte det i rummet.

Spaces er objektbutikker med flere vigtige egenskaber, der bidrager til at gøre JavaSpaces til et kraftfuldt, udtryksfuldt værktøj. Lad os se nærmere på:

Pladser deles: Mange fjernprocesser kan interagere med et rum samtidigt - selve rummet håndterer detaljerne om samtidig adgang, så du kan fokusere på designet af protokollerne på højt niveau mellem dine processer.
Pladserne er vedvarende: Pladser giver pålidelig opbevaring af objekter. Når du gemmer et objekt i et rum, forbliver det der på ubestemt tid, indtil det fjernes. Du kan også anmode om en tid af udlejning hvorunder et objekt skal opbevares. Når det er opbevaret i rummet, forbliver et objekt der, indtil dets lejetid (som kan fornyes) er forbi, eller indtil en proces eksplicit fjerner det. Vi vil diskutere lejemål mere detaljeret senere i denne serie.
Pladser er associerende: Objekter i et rum er placeret via associerende opslag, ikke efter hukommelsesplacering eller efter identifikator. Associativ opslag giver et simpelt middel til at finde de objekter, du er interesseret i, i henhold til deres indhold uden at skulle vide, hvad objektet hedder, hvem der oprettede det, eller hvor det er gemt. For at slå et objekt op, opretter du et skabelon (et objekt med nogle eller alle dets felter indstillet til specifikke værdier, og de andre er tilbage som nul at fungere som jokertegn). Et objekt i rummet matcher en skabelon, hvis det matcher skabelonens angivne felter nøjagtigt. Du vil se, at du med associerende opslag let kan udtrykke forespørgsler til objekter som "Er der nogen opgaver at beregne?" eller "Er der nogen svar på den primære faktor, jeg bad om?"
Pladserne er transaktionelt sikre: JavaSpaces gør brug af Ninis transaktionstjeneste for at sikre, at en operation på et rum er atomisk (enten operationen anvendes eller ikke). Transaktioner understøttes til enkelte operationer i et enkelt rum såvel som flere operationer over et eller flere mellemrum (enten alle operationer anvendes, eller ingen er). Som du vil se senere i serien, er transaktioner en vigtig måde at håndtere delvis fiasko på.
Med pladser kan du udveksle eksekverbart indhold: Mens det er i et rum, er objekter bare passive data - du kan ikke ændre dem eller påberåbe sig deres metoder. Men når du læser eller tager et objekt fra et rum, oprettes der en lokal kopi af objektet. Som med ethvert andet lokalt objekt kan du ændre dets offentlige felter og påberåbe sig metoderne, selvom du aldrig har set et objekt som det før. Denne funktion giver dig en kraftig mekanisme til at udvide dine applikations opførsel gennem et rum.

Efterhånden som denne serie skrider frem, vil vi vise dig, hvordan disse egenskaber spiller en nøglerolle i at lade dig oprette distribuerede applikationer, der fungerer godt i Jini-miljøet, hvor netværk ofte er spontant, og processer slutter og forlader beregningen dynamisk, undertiden på grund af enhed eller netværksfejl.

Oprindelsen til JavaSpaces

Vi har beskrevet JavaSpaces som en ny distribueret computermodel, men dens oprindelse kan spores tilbage til Yale University i begyndelsen af 1980'erne. Der udviklede Dr. David Gelernter et værktøj kaldet Linda til oprettelse af distribuerede applikationer. Linda består af et lille antal operationer kombineret med en vedvarende butik kaldet a dobbelt plads. Disse operationer er vinkelrette på ethvert bestemt programmeringssprog; de er en del af en koordinationssprog der kan føjes til enhver anden beregningssprog. Resultatet af Linda-forskningen var overraskende: ved at bruge en objektbutik sammen med et lille antal enkle operationer kan du nemt implementere en stor klasse af parallelle og distribuerede problemer ved hjælp af teknikker, der lindrer mange af faldgruberne ved at opbygge netværkssystemer. Med andre ord er rumbaserede systemer ikke kun enkle (kræver kun få operationer), men også udtryksfulde (egner sig godt til at løse mange distribuerede problemer).

Dr. Gelernters arbejde inspirerede Suns JavaSpaces-tjeneste og påvirkede også designet af opslags- og opdagelseskomponenterne i kernen Jini-teknologi (som du vil se som Jiniologi serien skrider frem). Mens JavaSpaces arvede rummodellen fra Linda, har designerne af JavaSpaces opdateret modellen på betydelige måder og udnyttet kraften fra Java-objekter, Jini, RMI og objektserialisering.

JavaSpaces i sammenhæng

Vores beskrivelse hidtil har været lidt abstrakt, så lad os overveje et par eksempler på ægte distribuerede applikationer, som du kan modellere som processer, der udveksler objekter gennem rum.

Chat-systemer

Overvej et simpelt flerbrugerchatsystem, hvor et mellemrum fungerer som et chatområde, der indeholder alle de meddelelser, der udgør en diskussion. For at tale, deponerer en deltager beskedobjekter i rummet. Alle chatmedlemmer venter på, at nye beskedobjekter vises, læser dem og viser deres indhold. Forsinkede ankomster kan undersøge de eksisterende beskedobjekter i rummet for at gennemgå tidligere diskussion. Faktisk, da rummet er vedvarende, kan en ny deltager se diskussionen længe efter at alle andre er gået væk, og deltagerne kan endda komme tilbage meget senere for at afslutte samtalen, hvor de slap. Listen over chatdeltagere kan også opbevares i rummet og opdateres, når nogen tilmelder sig eller forlader samtalen.

Beregn servere

Overvej nu at analysere realtidsradioteleskopdata for tegn på udenjordisk liv (meget som SETI @ home-projektet gør). Sådanne data er omfangsrige, og analyse af dem er et beregningsintensivt job, der er velegnet til parallel beregning af et netværk af computere - med andre ord en "beregningsserver". Ved hjælp af JavaSpaces-teknologien skrives en række opgaver - for eksempel en opgave pr. Del data, der skal analyseres - ind i rummet. Hver deltagende computer søger i rummet efter en opgave, fjerner den, fuldfører det nødvendige beregningsarbejde, slipper resultatet tilbage i rummet og fortsætter derefter med at lede efter flere opgaver. Denne tilgang skaleres naturligt: det fungerer på samme måde, om der er 10 computere til rådighed eller 1.000. Metoden giver også naturlig belastningsafbalancering, da hver arbejdstager opfanger nøjagtigt så meget arbejde, som den kan klare på et givet tidspunkt, hvor langsomme computere gør mindre arbejde og hurtige computere gør mere.

Mæglersystemer

Som et tredje eksempel, overvej et online auktionssystem, der bringer købere og sælgere af varer og tjenester sammen. Antag, at du som en potentiel køber beskriver den vare (såsom en bil), du gerne vil købe, og den pris, du er villig til at betale, pakk informationen ind i en post og skriv den resulterende ønskede-at-købe post til et rum. Samtidig overvåger potentielle sælgere løbende pladsen til ankomsten af ønskede at købe poster, der matcher varer i deres lager. For eksempel overvåger Mazda-forhandlere pladsen til poster, der beskriver Mazdas, mens brugte bilforhandlere overvåger pladsen til alle anmodninger om brugt bil. Når en matchende anmodning findes og læses, skriver en potentiel sælger en budindgang i rummet med angivelse af en udbudspris. Som en potentiel køber overvåger du løbende pladsen for bud på dine udestående anmodninger, og når du finder en, der er acceptabel, fjerner du budene og kontakter sælgeren (muligvis gennem rummet via en anden post).

En kort oversigt over API

Nu er det tid til at introducere JavaSpaces API. Som vi allerede har sagt, er det simpelt; Faktisk vil vi i resten af denne artikel dække alt, hvad du har brug for at vide (uden nogle mindre detaljer) om det. Men før vi beskriver JavaSpace interface og dens metoder, skal vi først tale om poster.

Indlæg

Et objekt, der er gemt i et rum, kaldes et

indgang.

For at være en post skal et objekt bare implementere

Indgang

interface. Lad os som et eksempel definere en meddelelsespost, som du kan skrive i et mellemrum:

 import net.jini.core.entry.Entry; 
 offentlig klasse Meddelelsesimplementer Indtastning {offentlig Stringindhold; 
 // en ikke-arg konstruktør offentlig besked () {}}

Her har vi defineret en Besked klasse med et strengfelt, der indeholder indholdet af meddelelsen. Fordi vi vil bruge denne klasse med mellemrum, skal vi implementere grænsefladen net.jini.core.entry.Entry, som findes i pakken net.jini.core.entry. Det er vigtigt at påpege det Indgang er en markørgrænseflade; med andre ord indeholder grænsefladen ingen konstanter eller metoder og kræver derfor ikke noget særligt arbejde at implementere, bortset fra tilføjelse implementerer indgang til din klassedefinition.

Udover at implementere Indgang interface, er der et par andre konventioner, som vores poster skal følge. Vi får mere at sige om årsagerne til senere artikler, men indtil videre ser vi bare på de brede konturer. En post skal have en offentlig konstruktør, der ikke tager argumenter (en såkaldt no-arg konstruktør); dette krav stammer fra den underliggende serialisering, der opstår, når poster overføres til og ud af mellemrum. Bemærk, at vores definition af Besked indeholder en no-arg konstruktør. En anden konvention er, at felter i en post skal erklæres offentlig; dette lader andre processer finde dine poster i mellemrum via associerende opslag, baseret på værdierne i disse felter. En tredje konvention er, at felter i en post skal indeholde referencer til objekter snarere end primitive typer (det vil sige, hvis du har brug for at definere et primitivt typefelt såsom int, skal du bruge den tilsvarende indpakningsklasse Heltal i stedet). For at sikre, at du dækker alle dine baser i at definere poster, anbefaler vi, at du henviser til JavaSpaces-principper, mønstre og praksis,eller til Sun Microsystems JavaSpaces Specification for detaljer. Vi vil også som nævnt berøre nogle af de finere punkter i senere artikler.

Ud over disse krav er en post som enhver anden Java-klasse; du kan instantiere det, påberåbe sig metoderne og tildele værdier til dets offentlige felter. Nu hvor vi har defineret en Besked indgangsklasse, lad os se, hvilke operationer der er tilgængelige for interaktion med poster i mellemrum.

JavaSpace-grænsefladen

For at interagere med et rum skal du få adgang til et objekt, der implementerer JavaSpace interface. Der er mange måder at få adgang til et sådant objekt (du kan for eksempel bruge Jini-opslag eller RMI-registreringsdatabasen), og vi vil dække detaljerne i dette i den næste artikel. For nu vil vi koncentrere os om JavaSpace interface selv.