In het vorige hoofdstuk hebben we gekeken naar nauw gekoppelde multiprocessorsystemen met gedeeld geheugen, gedeelde kerneldatastructuren en een gedeelde pool van waaruit processen worden aangeroepen. Vaak is het echter wenselijk om processors zo toe te wijzen dat ze autonoom zijn van de besturingsomgeving en bedrijfsomstandigheden voor het delen van bronnen. Stel bijvoorbeeld dat een gebruiker van een personal computer toegang moet hebben tot bestanden die zich op een grotere machine bevinden, maar tegelijkertijd de controle over de personal computer moet behouden. Hoewel sommige programma's, zoals uucp, netwerkbestandsoverdracht en andere netwerkfuncties ondersteunen, zal het gebruik ervan niet voor de gebruiker verborgen blijven, aangezien de gebruiker zich ervan bewust is dat hij het netwerk gebruikt. Bovendien moet worden opgemerkt dat programma's zoals teksteditors niet werken met verwijderde bestanden, zoals met gewone. Gebruikers moeten over de standaard set UNIX-systeemfuncties beschikken en, afgezien van het potentiële prestatieprobleem, mogen ze niet het gevoel hebben dat de machinegrenzen worden overschreden. Dus, bijvoorbeeld, het werk van de systeemfuncties die geopend en gelezen worden met bestanden op externe machines mag niet verschillen van hun werk met bestanden die tot lokale systemen behoren.

De architectuur van het gedistribueerde systeem wordt getoond in figuur 13.1. Elke computer die in de afbeelding wordt getoond, is een op zichzelf staande eenheid die bestaat uit een CPU, geheugen en randapparatuur. Het model gaat niet kapot, ook al heeft de computer geen lokaal bestandssysteem: hij moet randapparatuur hebben om met andere machines te communiceren, en alle bestanden die erbij horen, kunnen zich op een andere computer bevinden. Het fysieke geheugen dat voor elke machine beschikbaar is, is onafhankelijk van de processen die op andere machines worden uitgevoerd. In dit opzicht verschillen gedistribueerde systemen van de nauw gekoppelde multiprocessorsystemen die in het vorige hoofdstuk zijn besproken. Dienovereenkomstig functioneert de kern van het systeem op elke machine onafhankelijk van de externe bedrijfsomstandigheden van de gedistribueerde omgeving.

Figuur 13.1. Systeemmodel met gedistribueerde architectuur

Gedistribueerde systemen, goed beschreven in de literatuur, vallen traditioneel in de volgende categorieën:

Perifere systemen, dit zijn groepen machines die sterk gemeenschappelijk zijn en worden geassocieerd met één (meestal grotere) machine. Perifere processors delen hun belasting met de centrale processor en sturen alle oproepen naar het besturingssysteem ernaar door. Het doel van een randapparaat is om de algehele netwerkprestaties te verbeteren en de mogelijkheid te bieden om een ​​processor toe te wijzen aan een enkel proces in een UNIX-besturingssysteem. Het systeem start als aparte module op; In tegenstelling tot andere modellen van gedistribueerde systemen, hebben perifere systemen geen echte autonomie, behalve in gevallen die verband houden met procesdispatching en lokale geheugentoewijzing.

Gedistribueerde systemen zoals "Newcastle", waardoor communicatie op afstand mogelijk is door de namen van externe bestanden in de bibliotheek (de naam is ontleend aan het artikel "The Newcastle Connection" - zie). Verwijderde bestanden hebben een stuklijst (distinguished name) die in het zoekpad speciale tekens bevat of een optionele naamcomponent die voorafgaat aan de root van het bestandssysteem. De implementatie van deze methode houdt geen wijzigingen in de systeemkernel in en is daarom eenvoudiger dan de andere methoden die in dit hoofdstuk worden besproken, maar minder flexibel.

Gedistribueerde systemen zijn volledig transparant, waarbij standaard DN-namen voldoende zijn om te verwijzen naar bestanden die zich op andere machines bevinden; het is aan de kernel om deze bestanden als verwijderd te herkennen. Bestandszoekpaden gespecificeerd in hun samengestelde namen overschrijden machinegrenzen op aankoppelpunten, ongeacht hoeveel van dergelijke punten worden gevormd wanneer bestandssystemen op schijven worden gemount.

In dit hoofdstuk zullen we kijken naar de architectuur van elk model; alle verstrekte informatie is niet gebaseerd op de resultaten van specifieke ontwikkelingen, maar op informatie gepubliceerd in verschillende technische artikelen. Dit veronderstelt dat protocolmodules en apparaatstuurprogramma's verantwoordelijk zijn voor adressering, routering, stroomregeling en foutdetectie en -correctie - met andere woorden, dat elk model onafhankelijk is van het netwerk dat wordt gebruikt. De voorbeelden van het gebruik van systeemfuncties in de volgende sectie voor randsystemen werken op een vergelijkbare manier voor systemen zoals Newcastle en voor volledig transparante systemen, die later zullen worden besproken; daarom zullen we ze één keer in detail bekijken, en in de secties die zijn gewijd aan andere soorten systemen, zullen we ons vooral concentreren op de kenmerken die deze modellen van alle andere onderscheiden.

13.1 RANDVERWERKERS

De architectuur van het perifere systeem is weergegeven in figuur 13.2. Het doel van deze configuratie is om de algehele netwerkprestaties te verbeteren door lopende processen opnieuw toe te wijzen aan de CPU en perifere processors. Elk van de perifere processors heeft geen andere lokale randapparatuur tot zijn beschikking dan die nodig zijn om te communiceren met de centrale verwerkingseenheid. Het bestandssysteem en alle apparaten staan ​​ter beschikking van de centrale processor. Stel dat alle gebruikersprocessen worden uitgevoerd op de randprocessor en niet tussen randprocessoren bewegen; eenmaal overgedragen aan de processor, blijven ze erop staan ​​​​totdat ze zijn voltooid. De perifere processor bevat een light-versie van het besturingssysteem, ontworpen om lokale oproepen naar het systeem, interruptbeheer, geheugentoewijzing, werken met netwerkprotocollen en met een apparaatstuurprogramma voor communicatie met de centrale processor af te handelen.

Wanneer het systeem wordt geïnitialiseerd op de centrale processor, laadt de kern het lokale besturingssysteem op elk van de perifere processors via communicatielijnen. Elk proces dat in de periferie draait, wordt geassocieerd met een satellietproces dat behoort tot de centrale processor (zie); wanneer een proces dat draait op een perifere processor een systeemfunctie oproept waarvoor alleen de diensten van de centrale processor nodig zijn, communiceert het perifere proces met zijn satelliet en wordt het verzoek voor verwerking naar de centrale processor gestuurd. Het satellietproces voert een systeemfunctie uit en stuurt de resultaten terug naar de perifere processor. De relatie tussen een randproces en zijn satelliet is vergelijkbaar met de client-serverrelatie die we in detail hebben besproken in hoofdstuk 11: het randproces fungeert als een cliënt van zijn satelliet, die de functies van het werken met het bestandssysteem ondersteunt. In dit geval heeft het externe serverproces slechts één client. In paragraaf 13.4 gaan we kijken naar serverprocessen met meerdere clients.

Figuur 13.2. Configuratie randapparatuur

Figuur 13.3. Berichtformaten

Wanneer een randproces een systeemfunctie aanroept die lokaal kan worden verwerkt, hoeft de kernel geen verzoek naar het satellietproces te sturen. Om bijvoorbeeld extra geheugen te verkrijgen, kan een proces de sbrk-functie aanroepen voor lokale uitvoering. Als de diensten van de centrale processor echter vereist zijn, bijvoorbeeld om een ​​bestand te openen, codeert de kernel informatie over de parameters die aan de aangeroepen functie worden doorgegeven en de procesuitvoeringsvoorwaarden in een bericht dat naar het satellietproces wordt gestuurd (Figuur 13.3). Het bericht bevat een teken waaruit volgt dat de systeemfunctie wordt uitgevoerd door het satellietproces namens de klant, parameters die aan de functie worden doorgegeven en gegevens over de procesuitvoeringsomgeving (bijvoorbeeld gebruikers- en groepsidentificatiecodes), die zijn verschillend voor verschillende functies. De rest van het bericht bestaat uit gegevens met een variabele lengte (bijvoorbeeld een samengestelde bestandsnaam of gegevens die met de schrijffunctie moeten worden geschreven).

Het satellietproces wacht op verzoeken van het perifere proces; wanneer een verzoek wordt ontvangen, decodeert het het bericht, bepaalt het type systeemfunctie, voert het uit en zet de resultaten om in een antwoord dat naar het perifere proces wordt gestuurd. Het antwoord omvat, naast de resultaten van de uitvoering van de systeemfunctie, het foutbericht (indien aanwezig), het signaalnummer en een gegevensarray met variabele lengte die bijvoorbeeld informatie bevat die uit een bestand is gelezen. Het perifere proces wordt opgeschort totdat een reactie is ontvangen, na ontvangst decodeert het en verzendt het de resultaten naar de gebruiker. Dit is het algemene schema voor het afhandelen van oproepen naar het besturingssysteem; laten we nu verder gaan met een meer gedetailleerde beschouwing van individuele functies.

Overweeg een aantal functies om uit te leggen hoe het perifere systeem werkt: getppid, open, write, fork, exit en signal. De getppid-functie is vrij eenvoudig omdat het gaat om eenvoudige verzoek- en antwoordformulieren die worden uitgewisseld tussen het randapparaat en de CPU. De kern van de perifere processor genereert een bericht met een teken waaruit volgt dat de gevraagde functie de getppid-functie is, en stuurt het verzoek naar de centrale processor. Het satellietproces op de centrale processor leest het bericht van de perifere processor, decodeert het type systeemfunctie, voert het uit en verkrijgt de identificatie van zijn ouder. Het genereert dan een reactie en geeft dit door aan een wachtend perifeer proces aan de andere kant van de communicatielijn. Wanneer de perifere processor een reactie ontvangt, geeft deze deze door aan het proces dat de getppid-systeemfunctie heeft genoemd. Als het perifere proces gegevens (zoals de proces-ID van de ouder) opslaat in het lokale geheugen, hoeft het helemaal niet met zijn metgezel te communiceren.

Als de open systeemfunctie wordt aangeroepen, stuurt het perifere proces een bericht naar zijn metgezel, met daarin de bestandsnaam en andere parameters. Indien succesvol, wijst het begeleidende proces een index en ingangspunt toe aan de bestandstabel, wijst een item toe aan de descriptortabel van de gebruikersbestand in zijn ruimte en retourneert de bestandsdescriptor aan het randproces. Al die tijd, aan de andere kant van de communicatielijn, wacht het perifere proces op een reactie. Hij heeft geen structuren tot zijn beschikking die informatie over het geopende bestand zouden opslaan; De descriptor die wordt geretourneerd door open is een verwijzing naar een item in het begeleidende proces in de descriptortabel van het gebruikersbestand. De resultaten van het uitvoeren van de functie worden getoond in figuur 13.4.

Figuur 13.4. De open functie aanroepen vanuit een perifeer proces

Als de systeemfunctie schrijven wordt aangeroepen, genereert de randprocessor een bericht dat bestaat uit een teken van de schrijffunctie, een bestandsdescriptor en de hoeveelheid gegevens die moet worden geschreven. Vervolgens kopieert het vanuit de ruimte van het perifere proces de gegevens naar het satellietproces via de communicatielijn. Het satellietproces decodeert het ontvangen bericht, leest de gegevens van de communicatielijn en schrijft ze naar het overeenkomstige bestand (de descriptor in het bericht wordt gebruikt als een verwijzing naar de index waarvan en het record waarover in de bestandstabel wordt gebruikt ); al deze acties worden uitgevoerd op de centrale processor. Aan het einde van het werk stuurt het satellietproces naar het perifere proces een bericht dat de ontvangst van het bericht bevestigt en het aantal bytes aan gegevens bevat dat met succes naar het bestand is gekopieerd. De leesbewerking is vergelijkbaar; de satelliet informeert het perifere proces over het aantal daadwerkelijk gelezen bytes (bij het uitlezen van data van een terminal of van een kanaal komt dit aantal niet altijd overeen met het aantal dat in het verzoek is opgegeven). Om de ene of de andere functie uit te voeren, kan het nodig zijn om informatieberichten meerdere keren over het netwerk te verzenden, wat wordt bepaald door de hoeveelheid verzonden gegevens en de grootte van de netwerkpakketten.

De enige functie die moet worden gewijzigd terwijl deze op de CPU draait, is de vorksysteemfunctie. Wanneer een proces deze functie op de CPU uitvoert, selecteert de kernel er een perifere processor voor en stuurt een bericht naar een speciaal proces - de server, om deze laatste te informeren dat het het huidige proces gaat ontladen. Ervan uitgaande dat de server het verzoek heeft geaccepteerd, gebruikt de kernel fork om een ​​nieuw randproces te creëren, waarbij een procestabelinvoer en adresruimte wordt toegewezen. De centrale processor ontlaadt een kopie van het proces dat de vorkfunctie aanriep naar de perifere processor, overschrijft de nieuw toegewezen adresruimte, spawnt een lokale satelliet om te communiceren met het nieuwe randproces en stuurt een bericht naar het randapparaat om de programmateller te initialiseren voor het nieuwe proces. Het satellietproces (op de CPU) is een afstammeling van het proces dat fork wordt genoemd; een randproces is technisch gezien een afstammeling van het serverproces, maar logischerwijs is het een afstammeling van het proces dat de vorkfunctie noemde. Het serverproces heeft geen logische verbinding met het kind wanneer de fork is voltooid; de enige taak van de server is om het kind te helpen lossen. Door de sterke verbinding tussen de systeemcomponenten (perifere processors hebben geen autonomie) hebben het perifere proces en het satellietproces dezelfde identificatiecode. De relatie tussen processen is weergegeven in figuur 13.5: de ononderbroken lijn geeft de ouder-kindrelatie weer en de stippellijn geeft de relatie tussen peers weer.

Figuur 13.5. Een vorkfunctie uitvoeren op de CPU

Wanneer een proces de vorkfunctie op de perifere processor uitvoert, stuurt het een bericht naar zijn satelliet op de CPU, die vervolgens de hele reeks acties zoals hierboven beschreven uitvoert. De satelliet selecteert een nieuwe perifere processor en treft de nodige voorbereidingen om het beeld van het oude proces te ontladen: hij stuurt een verzoek naar het bovenliggende perifere proces om zijn beeld te lezen, waarna de overdracht van de gevraagde gegevens aan de andere kant begint van het communicatiekanaal. De satelliet leest het verzonden beeld en overschrijft het naar de perifere afstammeling. Wanneer het lossen van de afbeelding is voltooid, vertakt de satelliet zich, creëert zijn kind op de CPU en geeft de waarde van de programmateller door aan het perifere kind, zodat deze weet vanaf welk adres de uitvoering moet worden gestart. Het is duidelijk dat het beter zou zijn als het kind van het begeleidende proces als ouder aan het perifere kind zou worden toegewezen, maar in ons geval kunnen de gegenereerde processen op andere perifere processors worden uitgevoerd, niet alleen op die waarop ze zijn gemaakt. De relatie tussen processen aan het einde van de vorkfunctie is weergegeven in figuur 13.6. Wanneer het perifere proces zijn werk beëindigt, stuurt het een overeenkomstig bericht naar het satellietproces, en dat stopt ook. Een begeleidend proces kan geen afsluiting initiëren.

Figuur 13.6. Een vorkfunctie uitvoeren op een randprocessor

In zowel multiprocessor- als uniprocessorsystemen moet het proces op dezelfde manier op signalen reageren: het proces voltooit de uitvoering van de systeemfunctie voordat de signalen worden gecontroleerd, of integendeel, bij ontvangst van het signaal, verlaat het onmiddellijk de onderbroken toestand en abrupt het werk van de systeemfunctie onderbreekt, als dit in overeenstemming is met de prioriteit waarmee hij werd geschorst. Aangezien het satellietproces systeemfuncties vervult namens het perifere proces, moet het in coördinatie met dit laatste op signalen reageren. Als op een systeem met één processor een signaal ervoor zorgt dat een proces de functie afbreekt, zou het begeleidende proces op een systeem met meerdere processors zich op dezelfde manier moeten gedragen. Hetzelfde kan gezegd worden over het geval wanneer het signaal het proces ertoe aanzet zijn werk te beëindigen met behulp van de exit-functie: het perifere proces wordt beëindigd en stuurt het bijbehorende bericht naar het satellietproces, dat natuurlijk ook eindigt.

Wanneer een randproces de signaalsysteemfunctie aanroept, slaat het de huidige informatie op in lokale tabellen en stuurt het een bericht naar zijn satelliet om hem te informeren of het gespecificeerde signaal moet worden ontvangen of genegeerd. Het maakt het satellietproces niet uit of het het signaal of de standaardactie onderschept. De reactie van een proces op een signaal hangt af van drie factoren (Figuur 13.7): of een signaal wordt ontvangen terwijl het proces een systeemfunctie uitvoert, of er een indicatie wordt gemaakt met behulp van de signaalfunctie om het signaal te negeren, of het signaal optreedt op dezelfde randprocessor of op een andere. Laten we verder gaan met het overwegen van de verschillende mogelijkheden.

sighandle-algoritme / * signaalverwerkingsalgoritme * /

als (het huidige proces is iemands metgezel of heeft een prototype)

if (signaal wordt genegeerd)

if (het signaal kwam tijdens het uitvoeren van een systeemfunctie)

zet een signaal voor het satellietproces;

stuur een signaalbericht naar een perifeer proces;

anders (/ * perifere proces * /

/ * of er een signaal is ontvangen tijdens het uitvoeren van een systeemfunctie of niet * /

stuur een signaal naar het satellietproces;

algoritme satellite_end_of_syscall / * beëindiging van een systeemfunctie aangeroepen door een perifeer proces * /

invoer informatie: afwezig

opdruk: geen

if (er is een interrupt ontvangen tijdens het uitvoeren van een systeemfunctie)

verzend onderbrekingsbericht, signaal naar randproces;

else / * de uitvoering van de systeemfunctie is niet onderbroken * /

een antwoord verzenden: schakel de vlag in die de aankomst van een signaal aangeeft;

Figuur 13.7. Signaalverwerking in het perifere systeem

Stel dat een randproces zijn werk heeft onderbroken terwijl het satellietproces namens hem een ​​systeemfunctie vervult. Als het signaal ergens anders optreedt, detecteert het satellietproces het eerder dan het perifere proces. Er zijn drie gevallen mogelijk.

1. Als het satellietproces tijdens het wachten op een of andere gebeurtenis niet in de onderbroken toestand is gekomen, waaruit het zou verdwijnen bij ontvangst van een signaal, voert het de systeemfunctie tot het einde uit, stuurt de resultaten van de uitvoering naar het perifere proces en toont welk van de signalen het heeft ontvangen.

2. Als het proces de opdracht geeft om dit type signaal te negeren, blijft de satelliet het uitvoeringsalgoritme van de systeemfunctie volgen zonder de onderbroken toestand door longjmp te verlaten. In het antwoord dat naar het perifere proces wordt gestuurd, zal er geen signaal ontvangen bericht zijn.

3. Als het satellietproces bij ontvangst van een signaal de uitvoering van een systeemfunctie (door longjmp) onderbreekt, informeert het het perifere proces hierover en deelt het het signaalnummer mee.

Het perifere proces zoekt naar informatie over de ontvangst van signalen in de ontvangen respons en verwerkt, indien aanwezig, de signalen voordat het de systeemfunctie verlaat. Het gedrag van een proces in een systeem met meerdere processors komt dus exact overeen met het gedrag in een systeem met één processor: het wordt ofwel afgesloten zonder de kernelmodus te verlaten, of roept een aangepaste signaalverwerkingsfunctie aan, of negeert het signaal en voltooit de systeemfunctie met succes.

Figuur 13.8. Onderbreken tijdens het uitvoeren van een systeemfunctie

Stel bijvoorbeeld dat een randproces een leesfunctie oproept vanaf een terminal die is aangesloten op de centrale processor en zijn werk pauzeert terwijl het satellietproces de functie uitvoert (Figuur 13.8). Als de gebruiker op de breektoets drukt, stuurt de CPU-kern een signaal naar het satellietproces. Als de satelliet in een onderbroken toestand was, wachtend op een deel van de gegevens van de terminal, verlaat hij deze toestand onmiddellijk en beëindigt de leesfunctie. In zijn antwoord op een verzoek van een randproces geeft de satelliet een foutcode en signaalnummer die overeenkomen met de onderbreking. Het perifere proces analyseert het antwoord en, aangezien het bericht zegt dat er een interrupt is aangekomen, stuurt het het signaal naar zichzelf. Voordat de leesfunctie wordt afgesloten, controleert de perifere kern op signalering, detecteert een onderbrekingssignaal van het satellietproces en verwerkt dit zoals gebruikelijk. Als, als gevolg van het ontvangen van een interruptsignaal, het perifere proces zijn werk beëindigt met behulp van de exit-functie, zorgt deze functie ervoor dat het satellietproces wordt uitgeschakeld. Als het perifere proces onderbrekingssignalen onderschept, roept het de door de gebruiker gedefinieerde signaalverwerkingsfunctie op en retourneert het een foutcode naar de gebruiker bij het verlaten van de leesfunctie. Aan de andere kant, als de satelliet de stat-systeemfunctie uitvoert namens het perifere proces, zal hij de uitvoering ervan niet onderbreken wanneer hij een signaal ontvangt (de stat-functie zal gegarandeerd elke pauze beëindigen, omdat hij een beperkte wachttijd voor bronnen heeft ). De satelliet voltooit de uitvoering van de functie en stuurt het signaalnummer terug naar het perifere proces. Het perifere proces zendt een signaal naar zichzelf en ontvangt dit bij het verlaten van de systeemfunctie.

Als er een signaal optreedt op de perifere processor tijdens het uitvoeren van een systeemfunctie, zal het perifere proces in het duister tasten of het spoedig zal terugkeren naar de besturing van het satellietproces of dat dit laatste voor onbepaalde tijd in een opgeschorte toestand zal gaan. Het perifere proces stuurt een speciaal bericht naar de satelliet om deze te informeren over het optreden van een signaal. De kern van de CPU decodeert het bericht en stuurt een signaal naar de satelliet, waarvan de reactie op het ontvangen van het signaal is beschreven in de vorige paragrafen (abnormale beëindiging van de functie-uitvoering of voltooiing ervan). Het perifere proces kan niet rechtstreeks een bericht naar de satelliet sturen omdat de satelliet bezig is met het uitvoeren van een systeemfunctie en geen gegevens van de communicatielijn leest.

Verwijzend naar het gelezen voorbeeld, moet worden opgemerkt dat het perifere proces geen idee heeft of zijn metgezel wacht op invoer van de terminal of andere acties uitvoert. Het perifere proces stuurt een signaalbericht naar de satelliet: als de satelliet in een onderbroken toestand is met een onderbreekbare prioriteit, verlaat het deze toestand onmiddellijk en beëindigt het de systeemfunctie; anders wordt de functie overgedragen naar een succesvolle voltooiing.

Beschouw tenslotte het geval van de aankomst van een signaal op een tijdstip dat niet geassocieerd is met de uitvoering van een systeemfunctie. Als een signaal afkomstig is van een andere processor, ontvangt de satelliet het eerst en stuurt een signaalbericht naar het perifere proces, of het signaal nu het perifere proces betreft of niet. De perifere kern decodeert het bericht en stuurt een signaal naar het proces, dat er op de gebruikelijke manier op reageert. Als het signaal afkomstig is van de perifere processor, voert het proces standaardacties uit zonder zijn toevlucht te nemen tot de diensten van zijn satelliet.

Wanneer een randproces een signaal naar andere randprocessen stuurt, codeert het een kill-oproepbericht en stuurt het naar het satellietproces, dat de opgeroepen functie lokaal uitvoert. Als sommige van de processen waarvoor het signaal bedoeld is, zich op andere perifere processors bevinden, zullen hun satellieten het signaal ontvangen (en erop reageren zoals hierboven beschreven).

13.2 COMMUNICATIETYPE NEWCASTLE

In de vorige sectie hebben we een type nauw gekoppeld systeem beschouwd, dat wordt gekenmerkt door het verzenden van alle oproepen naar de functies van het bestandsbeheersubsysteem die optreden op de perifere processor naar een externe (centrale) processor. We kijken nu naar systemen met een zwakkere verbinding, die bestaan ​​uit machines die bestanden aanroepen die zich op andere machines bevinden. In een netwerk van pc's en werkstations hebben gebruikers bijvoorbeeld vaak toegang tot bestanden die zich op een grote machine bevinden. In de volgende twee secties zullen we kijken naar systeemconfiguraties waarin alle systeemfuncties worden uitgevoerd in lokale subsystemen, maar tegelijkertijd is het mogelijk om toegang te krijgen tot bestanden (via de functies van het bestandsbeheersubsysteem) die zich op andere machines bevinden.

Deze systemen gebruiken een van de volgende twee paden om verwijderde bestanden te identificeren. Op sommige systemen wordt een speciaal teken toegevoegd aan de samengestelde bestandsnaam: de naamcomponent die aan dit teken voorafgaat, identificeert de machine, de rest van de naam is het bestand op die machine. Dus, bijvoorbeeld, de voorname naam

"sftig! / fs1 / mjb / rje"

identificeert het bestand "/ fs1 / mjb / rje" op de machine "sftig". Dit bestandsidentificatieschema volgt de uucp-conventie voor het overbrengen van bestanden tussen UNIX-achtige systemen. In een ander schema worden verwijderde bestanden geïdentificeerd door een speciaal voorvoegsel aan de naam toe te voegen, bijvoorbeeld:

/../sftig/fs1/mjb/rje

waarbij "/../" een voorvoegsel is dat aangeeft dat het bestand is verwijderd; het tweede onderdeel van de bestandsnaam is de naam van de externe machine. Dit schema gebruikt de bekende syntaxis van UNIX-bestandsnamen, dus in tegenstelling tot het eerste schema hoeven gebruikersprogramma's zich niet aan te passen aan het gebruik van namen met een ongebruikelijke constructie (zie).

Figuur 13.9. Opstellen van verzoeken aan de fileserver (processor)

We zullen de rest van deze sectie wijden aan een model van een systeem dat gebruik maakt van een Newcastle-link, waarbij de kernel zich niet bezighoudt met het herkennen van verwijderde bestanden; deze functie is volledig toegewezen aan de subroutines uit de standaard C-bibliotheek, die in dit geval de rol van de systeeminterface spelen. Deze routines analyseren de eerste component van de bestandsnaam, die in beide beschreven identificatiemethoden een teken bevat van de afgelegen ligging van het bestand. Dit wijkt af van de routine waarin bibliotheekroutines geen bestandsnamen ontleden. Figuur 13.9 laat zien hoe verzoeken aan een fileserver worden geformuleerd. Als het bestand lokaal is, verwerkt de lokale systeemkernel het verzoek normaal. Beschouw het tegenovergestelde geval:

open ("/../sftig / fs1 / mjb / rje / bestand", O_RDONLY);

De open subroutine in de C-bibliotheek ontleedt de eerste twee componenten van de DN-bestandsnaam en weet het bestand op de externe machine "sftig" te zoeken. Om informatie te krijgen over de vraag of het proces eerder een verbinding had met een bepaalde machine, start de subroutine een speciale structuur waarin hij dit feit onthoudt, en in geval van een negatief antwoord brengt hij een verbinding tot stand met de bestandsserver die op de externe server draait. machine. Wanneer het proces zijn eerste verzoek voor verwerking op afstand formuleert, bevestigt de externe server het verzoek, indien nodig, records in de velden van de gebruikers- en groepsidentificatiecodes en creëert een satellietproces dat namens het cliëntproces handelt.

Om aan clientverzoeken te voldoen, moet de satelliet dezelfde bestandsrechten op de externe machine hebben als de client. Met andere woorden, de gebruiker "mjb" moet dezelfde toegangsrechten hebben tot zowel externe als lokale bestanden. Helaas is het mogelijk dat de identificatiecode van de "mjb"-cliënt samenvalt met de identificatiecode van een andere cliënt op de machine op afstand. Systeembeheerders op machines die op het netwerk draaien, moeten er dus voor zorgen dat elke gebruiker een identificatiecode krijgt toegewezen die uniek is voor het hele netwerk, of codeconversie uitvoeren op het moment dat een netwerkserviceverzoek wordt opgesteld. Als dit niet wordt gedaan, heeft het begeleidende proces de rechten van een andere client op de externe computer.

Een meer delicate kwestie is het verkrijgen van superuser-rechten met betrekking tot het werken met externe bestanden. Aan de ene kant mag de superuser-client niet dezelfde rechten hebben over het externe systeem om de beveiligingscontroles van het externe systeem niet te misleiden. Aan de andere kant zullen sommige programma's, als ze geen superuser-rechten krijgen, gewoon niet kunnen werken. Een voorbeeld van zo'n programma is het programma mkdir (zie hoofdstuk 7), dat een nieuwe directory aanmaakt. Het systeem op afstand zou niet toestaan ​​dat de client een nieuwe map aanmaakt omdat de superuser-rechten niet van kracht zijn bij het verwijderen. Het probleem van het maken van directory's op afstand dient als een serieuze reden om de systeemfunctie mkdir te herzien in de richting van het uitbreiden van de mogelijkheden om automatisch alle verbindingen tot stand te brengen die nodig zijn voor de gebruiker. Het is echter nog steeds een veelvoorkomend probleem dat setuid-programma's (zoals het mkdir-programma) superuser-privileges krijgen over externe bestanden. Misschien zou de beste oplossing voor dit probleem zijn om extra kenmerken in te stellen voor bestanden die de toegang tot deze bestanden door externe supergebruikers beschrijven; helaas zou dit veranderingen in de schijfindexstructuur vergen (in termen van het toevoegen van nieuwe velden) en zou het teveel rommel veroorzaken in bestaande systemen.

Als de open subroutine slaagt, laat de lokale bibliotheek een overeenkomstige opmerking hierover achter in een voor de gebruiker toegankelijke structuur die het adres van het netwerkknooppunt, de proces-ID van het satellietproces, de bestandsdescriptor en andere soortgelijke informatie bevat. De lees- en schrijfroutines van de bibliotheek bepalen, op basis van de bestandsdescriptor, of het bestand wordt verwijderd, en zo ja, een bericht naar de satelliet sturen. Het clientproces werkt samen met zijn partner in alle gevallen van toegang tot systeemfuncties waarvoor de services van een externe machine nodig zijn. Als een proces twee bestanden op dezelfde externe machine benadert, gebruikt het één satelliet, maar als de bestanden zich op verschillende machines bevinden, worden er al twee satellieten gebruikt: één op elke machine. Twee satellieten worden ook gebruikt wanneer twee processen toegang krijgen tot een bestand op een externe machine. Door de systeemfunctie via satelliet aan te roepen, genereert het proces een bericht met het functienummer, de naam van het zoekpad en andere noodzakelijke informatie, vergelijkbaar met die in de berichtenstructuur in het systeem met perifere processors.

Het mechanisme voor het uitvoeren van bewerkingen op de huidige map is complexer. Wanneer het proces een map op afstand als de huidige selecteert, stuurt de bibliotheekroutine een bericht naar de satelliet, die de huidige map verandert, en de routine onthoudt dat de map is verwijderd. In alle gevallen waarin de naam van het zoekpad begint met een ander teken dan een schuine streep (/), stuurt de subroutine de naam naar de externe machine, waar het satellietproces het vanuit de huidige directory routeert. Als de huidige directory lokaal is, geeft de routine gewoon de naam van het zoekpad door aan de lokale systeemkernel. De systeem-chroot-functie op een externe map is vergelijkbaar, maar wordt niet opgemerkt door de lokale kernel; strikt genomen kan het proces deze bewerking negeren, omdat alleen de bibliotheek de uitvoering ervan registreert.

Wanneer een proces fork oproept, stuurt de juiste bibliotheekroutine berichten naar elke satelliet. Satellietenprocessen vertakken zich en sturen hun onderliggende ID's naar de bovenliggende client. Het clientproces voert de fork-systeemfunctie uit, die de controle overdraagt ​​​​aan het kind dat het voortbrengt; het lokale kind is in dialoog met het externe satellietkind wiens adressen zijn opgeslagen door de bibliotheekroutine. Deze interpretatie van de vorkfunctie maakt het voor de satellietprocessen gemakkelijker om geopende bestanden en huidige mappen te beheren. Wanneer het proces dat met externe bestanden werkt wordt afgesloten (door de exit-functie aan te roepen), stuurt de subroutine berichten naar al zijn externe satellieten, zodat ze hetzelfde doen wanneer ze het bericht ontvangen. Bepaalde aspecten van de implementatie van de functies van het exec- en exitsysteem worden in de oefeningen besproken.

Het voordeel van een Newcastle-link is dat de toegang van een proces tot externe bestanden transparant wordt (onzichtbaar voor de gebruiker), zonder dat er wijzigingen in de systeemkernel nodig zijn. Deze ontwikkeling heeft echter een aantal nadelen. Allereerst is tijdens de implementatie ervan een afname van de systeemprestaties mogelijk. Door het gebruik van de uitgebreide C-bibliotheek neemt de hoeveelheid geheugen die door elk proces wordt gebruikt toe, zelfs als het proces geen toegang heeft tot externe bestanden; de bibliotheek dupliceert kernelfuncties en vereist meer geheugenruimte. Het vergroten van de omvang van processen verlengt de opstartperiode en kan leiden tot meer strijd om geheugenbronnen, waardoor de voorwaarden worden geschapen voor frequenter ontladen en pagineren van taken. Lokale verzoeken worden langzamer uitgevoerd vanwege de toename van de duur van elke aanroep naar de kernel, en de verwerking van externe verzoeken kan ook worden vertraagd, de kosten om ze over het netwerk te verzenden nemen toe. Aanvullende verwerking van externe verzoeken op gebruikersniveau verhoogt het aantal contextwisselingen, uitlaad- en omwisselbewerkingen. Ten slotte, om toegang te krijgen tot externe bestanden, moeten programma's opnieuw worden gecompileerd met behulp van de nieuwe bibliotheken; oude programma's en geleverde objectmodules kunnen niet zonder externe bestanden werken. Al deze nadelen ontbreken in het systeem dat in de volgende sectie wordt beschreven.

13.3 "TRANSPARANT" GEDISTRIBUEERDE BESTANDSSYSTEMEN

De term "transparante toewijzing" betekent dat gebruikers op de ene machine toegang hebben tot bestanden op een andere machine zonder zich te realiseren dat ze machinegrenzen overschrijden, net zoals ze op hun machine zijn wanneer ze van het ene bestandssysteem naar het andere overschakelen en de aankoppelpunten doorkruisen. De namen waarmee processen verwijzen naar bestanden die zich op externe machines bevinden, zijn vergelijkbaar met de namen van lokale bestanden: ze bevatten geen onderscheidende tekens. In de configuratie getoond in figuur 13.10, is de directory "/ usr / src" die bij machine B hoort "aangekoppeld" in de directory "/ usr / src" die bij machine A hoort. dezelfde systeembroncode, traditioneel te vinden in de "/ usr / src" map. Gebruikers die op machine A draaien, hebben toegang tot bestanden op machine B met behulp van de bekende syntaxis van het schrijven van bestandsnamen (bijvoorbeeld: "/usr/src/cmd/login.c"), en de kernel beslist zelf of het bestand op afstand of lokaal is . Gebruikers die op computer B draaien, hebben toegang tot hun lokale bestanden (niet wetende dat gebruikers van computer A toegang hebben tot dezelfde bestanden), maar hebben op hun beurt geen toegang tot bestanden die zich op computer A bevinden. Natuurlijk zijn er andere opties mogelijk, in in het bijzonder die waarin alle externe systemen aan de root van het lokale systeem zijn gekoppeld, zodat gebruikers toegang hebben tot alle bestanden op alle systemen.

Figuur 13.10. Bestandssystemen na externe koppeling

De overeenkomsten tussen het mounten van lokale bestandssystemen en het toestaan ​​van toegang tot externe bestandssystemen hebben ertoe geleid dat de mount-functie is aangepast aan externe bestandssystemen. In dit geval heeft de kernel een uitgebreide format mount-tabel tot zijn beschikking. Door de mount-functie uit te voeren, organiseert de kernel een netwerkverbinding met een externe machine en slaat informatie op die deze verbinding kenmerkt in de mount-tabel.

Een interessant probleem heeft te maken met padnamen die ".." bevatten. Als een proces de huidige map van een extern bestandssysteem maakt, zal het gebruik van ".."-tekens in de naam waarschijnlijker zijn dat het proces terugkeert naar het lokale bestandssysteem in plaats van toegang te krijgen tot bestanden boven de huidige map. Terugkerend naar figuur 13.10, merk op dat wanneer een proces behorend tot machine A, die eerder de huidige map "/ usr / src / cmd" in het externe bestandssysteem heeft geselecteerd, de opdracht zal uitvoeren

de huidige map is de hoofdmap van machine A, niet van machine B. Het namei-algoritme dat in de kernel van het externe systeem wordt uitgevoerd, controleert na ontvangst van de reeks tekens "..", of het aanroepende proces een agent van de client is proces, en zo ja, stelt in of de client de huidige werkmap behandelt als de root van het externe bestandssysteem.

Communicatie met een externe machine kan twee vormen aannemen: een externe procedure-aanroep of een externe systeemfunctie-aanroep. In de eerste vorm controleert elke kernelprocedure die indexen behandelt om te zien of de index naar een extern bestand verwijst, en zo ja, een verzoek naar de externe machine om de gespecificeerde bewerking uit te voeren. Dit schema past natuurlijk in de abstracte structuur van ondersteuning voor verschillende soorten bestandssystemen, beschreven in het laatste deel van hoofdstuk 5. Zo kan een toegang tot een bestand op afstand de overdracht van verschillende berichten over het netwerk initiëren, waarvan het aantal is bepaald door het aantal impliciete bewerkingen op het bestand, met een overeenkomstige toename van de responstijd op het verzoek, rekening houdend met de in het netwerk aanvaarde wachttijd. Elke set van bewerkingen op afstand omvat ten minste acties voor indexvergrendeling, referentietelling, enz. Om het model te verbeteren, werden verschillende optimalisatieoplossingen voorgesteld met betrekking tot het combineren van verschillende bewerkingen in één query (bericht) en het bufferen van de belangrijkste gegevens (cm. ).

Figuur 13.11. Een extern bestand openen

Overweeg een proces dat een extern bestand "/usr/src/cmd/login.c" opent, waarbij "src" het koppelpunt is. Door de bestandsnaam te ontleden (met behulp van het namei-iget-schema), detecteert de kernel dat het bestand is verwijderd en stuurt een verzoek naar de hostcomputer om de vergrendelde index te krijgen. Nadat het gewenste antwoord is ontvangen, maakt de lokale kernel een kopie van de index in het geheugen die overeenkomt met het externe bestand. Vervolgens controleert de kernel op de benodigde toegangsrechten tot het bestand (om bijvoorbeeld te lezen) door een ander bericht naar de externe machine te sturen. Het open algoritme gaat door in volledige overeenstemming met het plan dat in hoofdstuk 5 is beschreven, en stuurt indien nodig berichten naar de externe machine, totdat het algoritme is voltooid en de index is vrijgegeven. De relatie tussen de kerneldatastructuren na voltooiing van het open algoritme wordt getoond in figuur 13.11.

Als de client de leessysteemfunctie aanroept, vergrendelt de client-kernel de lokale index, geeft een vergrendeling op de externe index uit, een leesverzoek, kopieert de gegevens naar het lokale geheugen, geeft een verzoek om de externe index vrij te maken en bevrijdt de lokale index . Dit schema is consistent met de semantiek van de bestaande uniprocessor-kernel, maar de frequentie van netwerkgebruik (meerdere oproepen naar elke systeemfunctie) vermindert de prestatie van het hele systeem. Om de berichtenstroom op het netwerk te verminderen, kunnen echter meerdere bewerkingen worden gecombineerd in één verzoek. In het voorbeeld met de leesfunctie kan de client de server één algemeen "lees"-verzoek sturen, en de server beslist zelf om de index te pakken en vrij te geven wanneer deze wordt uitgevoerd. Het verminderen van netwerkverkeer kan ook worden bereikt door externe buffers te gebruiken (zoals we hierboven hebben besproken), maar er moet voor worden gezorgd dat de systeembestandsfuncties die deze buffers gebruiken correct worden uitgevoerd.

In de tweede vorm van communicatie met een externe machine (een oproep naar een externe systeemfunctie), detecteert de lokale kernel dat de systeemfunctie gerelateerd is aan een extern bestand en stuurt de parameters gespecificeerd in zijn aanroep naar het externe systeem, dat de functie en retourneert de resultaten naar de client. De clientmachine ontvangt de resultaten van de uitvoering van de functie en verlaat de aanroepstatus. De meeste systeemfuncties kunnen worden uitgevoerd met slechts één netwerkverzoek en het ontvangen van een reactie na een redelijke tijd, maar niet alle functies passen in dit model. Dus, bijvoorbeeld, bij het ontvangen van bepaalde signalen, maakt de kernel een bestand aan voor het proces genaamd "core" (Hoofdstuk 7). Het maken van dit bestand is niet gekoppeld aan een specifieke systeemfunctie, maar voert uiteindelijk verschillende bewerkingen uit, zoals het maken van een bestand, het controleren van machtigingen en het uitvoeren van een reeks schrijfbewerkingen.

In het geval van de open systeemfunctie omvat het verzoek om de functie uit te voeren die naar de externe machine is verzonden, het deel van de bestandsnaam dat overblijft na uitsluiting van de zoekpadnaamcomponenten die het externe bestand onderscheiden, evenals verschillende vlaggen. In het eerdere voorbeeld van het openen van het bestand "/usr/src/cmd/login.c", stuurt de kernel de naam "cmd / login.c" naar de externe machine. Het bericht bevat ook referenties zoals gebruikers- en groepsidentificatiecodes, die nodig zijn om bestandsmachtigingen op een externe computer te verifiëren. Als een reactie wordt ontvangen van de externe machine die aangeeft dat de functie succesvol is geopend, haalt de lokale kernel een vrije index op in het geheugen van de lokale machine en markeert deze als de externe bestandsindex, slaat informatie op over de externe machine en de externe index, en wijst routinematig een nieuw item toe aan de bestandstabel. Vergeleken met de daadwerkelijke index op de externe machine, is de index die eigendom is van de lokale machine formeel en niet in strijd met de configuratie van het model, die in grote lijnen hetzelfde is als de configuratie die wordt gebruikt bij het aanroepen van de externe procedure (Figuur 13.11). Als een functie die door een proces wordt aangeroepen een bestand op afstand benadert door zijn descriptor, weet de lokale kernel uit de (lokale) index dat het bestand op afstand is, formuleert een verzoek dat de aangeroepen functie bevat en stuurt het naar de externe machine. Het verzoek bevat een verwijzing naar de externe index waarmee het satellietproces het externe bestand zelf kan identificeren.

Na het resultaat van het uitvoeren van een systeemfunctie te hebben ontvangen, kan de kernel een beroep doen op de diensten van een speciaal programma om het te verwerken (waarna de kernel klaar zal zijn met werken met de functie), omdat de lokale verwerking van resultaten gebruikt in een uniprocessorsysteem is niet altijd geschikt voor een systeem met meerdere processors. Hierdoor zijn veranderingen in de semantiek van systeemalgoritmen mogelijk, gericht op het bieden van ondersteuning bij het uitvoeren van systeemfuncties op afstand. Tegelijkertijd circuleert er echter een minimale berichtenstroom in het netwerk, waardoor de responstijd van het systeem op inkomende verzoeken minimaal is.

13.4 GEDISTRIBUEERD MODEL ZONDER OVERDRACHT PROCESSEN

Het gebruik van overdrachtsprocessen (satellietprocessen) in een transparant gedistribueerd systeem maakt het gemakkelijker om verwijderde bestanden bij te houden, maar de procestabel van het externe systeem is overbelast met satellietprocessen die het grootste deel van de tijd inactief zijn. In andere schema's worden speciale serverprocessen gebruikt om externe verzoeken te verwerken (zie en). Het externe systeem heeft een set (pool) serverprocessen die het van tijd tot tijd toewijst om binnenkomende externe verzoeken te verwerken. Na het verwerken van het verzoek keert het serverproces terug naar de pool en komt het in een staat die klaar is om andere verzoeken te verwerken. De server slaat de gebruikerscontext tussen twee oproepen niet op, omdat hij verzoeken van meerdere processen tegelijk kan verwerken. Daarom moet elk bericht dat afkomstig is van een cliëntproces informatie bevatten over zijn uitvoeringsomgeving, namelijk: gebruikersidentificatiecodes, huidige directory, signalen, enz. functies.

Wanneer een proces een extern bestand opent, wijst de externe kernel een index toe voor volgende koppelingen naar het bestand. De lokale machine onderhoudt een aangepaste bestandsdescriptortabel, een bestandstabel en een indextabel met een reguliere set records, met een indextabelitem dat de externe machine en de externe index identificeert. In gevallen waarin een systeemfunctie (bijvoorbeeld lezen) een bestandsdescriptor gebruikt, stuurt de kernel een bericht dat verwijst naar de eerder toegewezen externe index en draagt ​​procesgerelateerde informatie over: gebruikersidentificatiecode, maximale bestandsgrootte, enz. de machine heeft een serverproces tot zijn beschikking heeft, neemt de interactie met de client de eerder beschreven vorm aan, maar de verbinding tussen de client en de server wordt alleen tot stand gebracht voor de duur van de systeemfunctie.

Het gebruik van servers in plaats van satellietprocessen kan het beheer van dataverkeer, signalen en externe apparaten bemoeilijken. Grote aantallen verzoeken naar een externe machine bij afwezigheid van een voldoende aantal servers moeten in een wachtrij worden geplaatst. Dit vereist een protocol met een hogere laag dan het protocol dat op het hoofdnetwerk wordt gebruikt. In het satellietmodel daarentegen wordt oververzadiging geëlimineerd omdat alle clientverzoeken synchroon worden verwerkt. Een klant kan maximaal één aanvraag in behandeling hebben.

Het verwerken van signalen die de uitvoering van een systeemfunctie onderbreken is ook gecompliceerd bij het gebruik van servers, aangezien de externe machine moet zoeken naar de juiste server die de uitvoering van de functie bedient. Het is zelfs mogelijk dat door de drukte van alle servers een aanvraag voor een systeemfunctie in behandeling is. Voorwaarden voor het ontstaan ​​van concurrentie doen zich ook voor wanneer de server het resultaat van de systeemfunctie terugstuurt naar het oproepende proces en de server in zijn antwoord het verzenden van een corresponderend signaleringsbericht via het netwerk omvat. Elk bericht moet worden gemarkeerd zodat het externe systeem het kan herkennen en, indien nodig, de serverprocessen kan beëindigen. Bij het gebruik van satellieten wordt het proces dat de vervulling van het verzoek van de klant afhandelt automatisch geïdentificeerd, en in het geval dat er een signaal binnenkomt, is het niet moeilijk om te controleren of het verzoek is verwerkt of niet.

Ten slotte, als een systeemfunctie die door de client wordt aangeroepen, ervoor zorgt dat de server voor onbepaalde tijd pauzeert (bijvoorbeeld bij het lezen van gegevens van een externe terminal), kan de server geen andere verzoeken verwerken om de serverpool vrij te maken. Als meerdere processen tegelijkertijd toegang hebben tot externe apparaten en als het aantal servers van bovenaf wordt beperkt, is er een behoorlijk tastbaar knelpunt. Bij satellieten gebeurt dit niet, aangezien aan elk cliëntproces een satelliet wordt toegewezen. Een ander probleem met het gebruik van servers voor externe apparaten wordt behandeld in oefening 13.14.

Ondanks de voordelen die het gebruik van satellietprocessen biedt, wordt de behoefte aan vrije invoer in de procestabel in de praktijk zo nijpend dat in de meeste gevallen de diensten van serverprocessen nog steeds worden gebruikt om verzoeken op afstand te verwerken.

Figuur 13.12. Conceptueel diagram van interactie met externe bestanden op kernelniveau

13.5 CONCLUSIES

In dit hoofdstuk hebben we drie schema's overwogen voor het werken met bestanden die zich op externe machines bevinden, waarbij externe bestandssystemen worden behandeld als een uitbreiding van de lokale. De architecturale verschillen tussen deze indelingen zijn weergegeven in figuur 13.12. Ze verschillen op hun beurt allemaal van de multiprocessorsystemen die in het vorige hoofdstuk zijn beschreven doordat de processors hier geen fysiek geheugen delen. Een perifeer processorsysteem bestaat uit een nauw gekoppelde set processors die de bestandsbronnen van de centrale processor delen. Een verbinding van het Newcastle-type biedt verborgen ("transparante") toegang tot externe bestanden, maar niet door middel van de kernel van het besturingssysteem, maar door het gebruik van een speciale C-bibliotheek. Om deze reden moeten alle programma's die dit type koppeling willen gebruiken, opnieuw worden gecompileerd, wat in het algemeen een ernstig nadeel van dit schema is. De afstand van een bestand wordt aangegeven met een speciale reeks tekens die de machine beschrijven waarop het bestand zich bevindt, en dit is een andere factor die de overdraagbaarheid van programma's beperkt.

In transparante gedistribueerde systemen wordt een wijziging van de mount-systeemfunctie gebruikt om toegang te krijgen tot externe bestanden. Indexen op het lokale systeem worden gemarkeerd als bestanden op afstand en de lokale kernel stuurt een bericht naar het systeem op afstand waarin de gevraagde systeemfunctie, de parameters en de externe index worden beschreven. Communicatie in een "transparant" gedistribueerd systeem wordt in twee vormen ondersteund: in de vorm van een oproep naar een externe procedure (er wordt een bericht verzonden naar de externe machine met een lijst van bewerkingen die bij de index horen) en in de vorm van een oproep naar een externe systeemfunctie (het bericht beschrijft de gevraagde functie). Het laatste deel van het hoofdstuk bespreekt kwesties met betrekking tot de verwerking van verzoeken op afstand met behulp van satellietprocessen en servers.

13.6 OEFENINGEN

*1. Beschrijf de implementatie van de exit-systeemfunctie in een systeem met perifere processors. Wat is het verschil tussen dit geval en wanneer het proces wordt afgesloten bij ontvangst van een niet-afgevangen signaal? Hoe moet de kernel de inhoud van het geheugen dumpen?

2. Processen kunnen SIGKILL-signalen niet negeren; Leg uit wat er in het perifere systeem gebeurt als het proces zo'n signaal ontvangt.

* 3. Beschrijf de implementatie van de exec-systeemfunctie op een systeem met perifere processors.

*4. Hoe moet de centrale processor processen verdelen over de perifere processors om de totale belasting in evenwicht te houden?

*5. Wat gebeurt er als de perifere processor niet genoeg geheugen heeft om alle processen op te vangen die erop worden overgedragen? Hoe moet het lossen en wisselen van processen in het netwerk gebeuren?

6. Overweeg een systeem waarin verzoeken naar een externe bestandsserver worden verzonden als er een speciaal voorvoegsel in de bestandsnaam wordt gevonden. Laat het proces execl ("/../sftig / bin / sh", "sh", 0); Het uitvoerbare bestand bevindt zich op een externe computer, maar moet op het lokale systeem worden uitgevoerd. Leg uit hoe de externe module wordt gemigreerd naar het lokale systeem.

7. Als de beheerder nieuwe machines moet toevoegen aan een bestaand systeem met een verbinding zoals Newcastle, wat is dan de beste manier om de C-bibliotheekmodules hierover te informeren?

*acht. Tijdens de uitvoering van de exec-functie overschrijft de kernel de adresruimte van het proces, inclusief de bibliotheektabellen die door de Newcastle-link worden gebruikt om links naar externe bestanden te volgen. Na het uitvoeren van de functie moet het proces de mogelijkheid behouden om toegang te krijgen tot deze bestanden via hun oude descriptors. Beschrijf de implementatie van dit punt.

*negen. Zoals weergegeven in paragraaf 13.2, resulteert het aanroepen van de exit-systeemfunctie op systemen met een Newcastle-verbinding in een bericht dat wordt verzonden naar het begeleidende proces, waardoor het laatste wordt gedwongen te beëindigen. Dit gebeurt op het niveau van bibliotheekroutines. Wat gebeurt er wanneer een lokaal proces een signaal ontvangt dat het vertelt om af te sluiten in de kernelmodus?

*tien. In een systeem met een Newcastle-link, waar externe bestanden worden geïdentificeerd door de naam vooraf te laten gaan door een speciaal voorvoegsel, hoe kan een gebruiker, die ".." (oudermap) opgeeft als de bestandsnaamcomponent, het externe koppelpunt doorkruisen?

11. We weten uit hoofdstuk 7 dat verschillende signalen ervoor zorgen dat het proces de inhoud van het geheugen in de huidige directory dumpt. Wat moet er gebeuren als de huidige map van het externe bestandssysteem is? Welk antwoord zou je geven als het systeem een ​​relatie als Newcastle gebruikt?

*12. Welke implicaties voor lokale processen zou het hebben als alle satelliet- of serverprocessen uit het systeem zouden worden verwijderd?

*13. Overweeg hoe u het link-algoritme implementeert in een transparant gedistribueerd systeem, waarvan de parameters twee externe bestandsnamen kunnen zijn, evenals het exec-algoritme, geassocieerd met het uitvoeren van verschillende interne leesbewerkingen. Overweeg twee vormen van communicatie: een externe procedure-aanroep en een externe systeemfunctie-aanroep.

*veertien. Bij toegang tot het apparaat kan het serverproces in de onderbroken toestand komen, waaruit het door het apparaatstuurprogramma wordt verwijderd. Als het aantal servers beperkt is, kan het systeem natuurlijk niet meer voldoen aan de verzoeken van de lokale machine. Bedenk een betrouwbaar schema waarbij niet alle serverprocessen worden onderbroken terwijl wordt gewacht tot apparaatgerelateerde I / O is voltooid. De systeemfunctie wordt niet beëindigd als alle servers bezet zijn.

Figuur 13.13. Terminal Server-configuratie

*15. Wanneer een gebruiker zich aanmeldt bij het systeem, slaat de terminallijndiscipline de informatie op dat de terminal een operatorterminal is die een groep processen leidt. Om deze reden ontvangen alle processen in de groep het onderbrekingssignaal wanneer de gebruiker op de "break"-toets op het toetsenbord van de terminal drukt. Overweeg een systeemconfiguratie waarin alle terminals fysiek zijn verbonden met één machine, maar gebruikersregistratie logisch wordt geïmplementeerd op andere machines (Figuur 13.13). In elk geval creëert het systeem een ​​getty-proces voor de terminal op afstand. Als verzoeken aan een extern systeem worden verwerkt door een set serverprocessen, houd er dan rekening mee dat wanneer de open procedure wordt uitgevoerd, de server stopt met wachten op een verbinding. Wanneer de open-functie is voltooid, gaat de server terug naar de serverpool en verbreekt de verbinding met de terminal. Hoe wordt een onderbrekingssignaal geactiveerd door op de "break"-toets te drukken die naar de adressen van processen in dezelfde groep wordt verzonden?

*16. Geheugen delen is een functie die inherent is aan lokale machines. Logisch gezien kan de toewijzing van een gemeenschappelijk fysiek geheugen (lokaal of op afstand) worden uitgevoerd voor processen die bij verschillende machines horen. Beschrijf de implementatie van dit punt.

* 17. De proces-paging- en paging-algoritmen die in hoofdstuk 9 worden besproken, gaan uit van het gebruik van een lokale pager. Welke wijzigingen moeten er in deze algoritmen worden aangebracht om apparaten voor het op afstand laden te kunnen ondersteunen?

*achttien. Stel dat de externe machine (of het netwerk) een fatale crash ervaart en het lokale netwerklaagprotocol registreert dit feit. Ontwikkel een herstelschema voor een lokaal systeem dat verzoeken doet aan een externe server. Ontwikkel daarnaast een herstelschema voor een serversysteem dat het contact met klanten heeft verloren.

*19. Wanneer een proces een extern bestand benadert, is het mogelijk dat het proces meerdere machines doorkruist om het bestand te zoeken. Neem de naam "/ usr / src / uts / 3b2 / os" als voorbeeld, waarbij "/ usr" de map is die bij machine A hoort, "/ usr / src" het aankoppelpunt is van de hoofdmap van machine B, " / usr / src / uts / 3b2 "is het aankoppelpunt van de root van machine C. Door meerdere machines lopen naar de eindbestemming wordt een multihop genoemd. Als er echter een directe netwerkverbinding is tussen machine A en C, zou het verzenden van gegevens via machine B inefficiënt zijn. Beschrijf de kenmerken van de implementatie van "multishopping" in een systeem met een Newcastle-verbinding en in een "transparant" gedistribueerd systeem.

Momenteel hebben alle IS ontwikkeld voor commerciële doeleinden een gedistribueerde architectuur, wat het gebruik van globale en / of lokale netwerken impliceert.

Historisch gezien was de bestandsserverarchitectuur de eerste die wijdverbreid werd, omdat de logica ervan eenvoudig is en het het gemakkelijkst is om de IS's die al in gebruik zijn, naar een dergelijke architectuur over te brengen. Daarna werd het getransformeerd in een server-client-architectuur, die kan worden geïnterpreteerd als een logisch vervolg. Moderne systemen die in het wereldwijde netwerk INTERNET worden gebruikt, hebben voornamelijk betrekking op de architectuur van gedistribueerde objecten (zie Fig. III‑15 )

IS kan worden voorgesteld dat bestaat uit de volgende componenten (Fig. III-16)

III.03.2. a Bestandsservertoepassingen.

Het is historisch gezien de eerste gedistribueerde architectuur (Fig. III-17). Het is heel eenvoudig georganiseerd: er zijn alleen gegevens op de server en al het andere behoort tot de clientcomputer. Aangezien lokale netwerken vrij goedkoop zijn, en vanwege het feit dat met een dergelijke architectuur de applicatiesoftware autonoom is, wordt een dergelijke architectuur tegenwoordig vaak gebruikt. We kunnen stellen dat dit een variant is van de client-server-architectuur, waarbij alleen databestanden op de server staan. Verschillende personal computers werken alleen samen door middel van een gemeenschappelijk gegevensarchief, daarom zijn programma's die voor één computer zijn geschreven, het gemakkelijkst aan te passen aan een dergelijke architectuur.

Voordelen:

Voordelen van een bestandsserverarchitectuur:

gemak van organisatie;

Is niet in tegenspraak met de noodzakelijke vereisten voor de database om de integriteit en betrouwbaarheid te behouden.

Netwerk congestie;

Onvoorspelbare reactie op een verzoek.

Deze nadelen worden verklaard door het feit dat elk verzoek aan de database leidt tot de overdracht van aanzienlijke hoeveelheden informatie via het netwerk. Om bijvoorbeeld een of meerdere rijen uit tabellen te selecteren, wordt de hele tabel gedownload naar de clientcomputer en selecteert het DBMS daar al. Aanzienlijk netwerkverkeer is vooral beladen met de organisatie van toegang op afstand tot de database.

III.03.2. b Client-servertoepassingen.

In dit geval is er een verdeling van verantwoordelijkheden tussen de server en de client. Afhankelijk van hoe ze zijn gescheiden onderscheiden vet en thin client.

In het thin client-model wordt al het applicatiewerk en databeheer op de server gedaan. De gebruikersinterface in deze systemen "migreert" naar een personal computer, en de softwaretoepassing zelf vervult de functies van een server, d.w.z. voert alle sollicitatieprocessen uit en beheert gegevens. Het thin client-model kan ook worden geïmplementeerd waar clients computers of werkstations zijn. De netwerkapparaten draaien de internetbrowser en de gebruikersinterface die in het systeem is geïmplementeerd.

Hoofd gebrek thin client-modellen - hoge server- en netwerkbelasting. Alle berekeningen worden uitgevoerd op de server en dit kan leiden tot aanzienlijk netwerkverkeer tussen de client en de server. Er zit voldoende rekenkracht in moderne computers, maar die wordt praktisch niet gebruikt in het model/thin client van de bank

Het dikke clientmodel daarentegen gebruikt de verwerkingskracht van lokale machines: de applicatie zelf wordt op de clientcomputer geplaatst. Een voorbeeld van dit type architectuur zijn ATM-systemen, waarbij de ATM de client is en de server de centrale computer die de database met klantrekeningen bedient.

III.03.2. c Client-serverarchitectuur met twee en drie lagen.

Alle hierboven besproken architecturen zijn tweeledig. Ze maken onderscheid tussen het clientniveau en het serverniveau. Strikt genomen bestaat het IC uit drie logische niveaus:

· Gebruikers level;

Toepassingsniveau:

· Gegevenslaag.

Daarom zijn er in een two-tier model, waar slechts twee tiers zijn betrokken, schaalbaarheids- en prestatieproblemen als het thin client-model wordt gekozen, of systeembeheerproblemen als het thick client-model wordt gekozen. Deze problemen kunnen worden vermeden als we een model toepassen dat uit drie niveaus bestaat, waarvan twee servers zijn (Fig. III-21).

Gegevensserver

In feite kunnen de applicatieserver en de dataserver zich op dezelfde machine bevinden, maar ze kunnen niet de functies van elkaar uitvoeren. Het mooie van het drieledige model is dat het applicatie-uitvoering en databeheer logisch van elkaar scheidt.

Tabel III-5 Toepassing van verschillende soorten architecturen

architectuur	Sollicitatie
Two-tier thin client	1 Legacy systemen waarin het niet raadzaam is applicatie-uitvoering en databeheer te scheiden. 2 Rekenintensieve applicaties met weinig databeheer. 3 Applicaties met grote hoeveelheden data, maar weinig rekenkracht.
Dikke client met twee lagen	1 Toepassingen waarbij de gebruiker intensieve dataverwerking nodig heeft, d.w.z. datavisualisatie. 2 Applicaties met een relatief constante set gebruikersfuncties toegepast op een goed beheerde systeemomgeving.
Drie-tier server-client	1 Grote applicaties met cellen en duizenden klanten 2 Applicaties waarin zowel data als verwerkingsmethoden regelmatig veranderen. 3 Applicaties die data uit meerdere bronnen integreren.

Dit model is geschikt voor veel soorten toepassingen, maar het beperkt de IS-ontwikkelaars die moeten beslissen waar ze diensten willen leveren, ondersteuning voor schaalbaarheid moeten bieden en tools moeten ontwikkelen om nieuwe klanten te verbinden.

III.03.2. d Gedistribueerde objectarchitectuur.

Een meer algemene benadering wordt geboden door een gedistribueerde objectarchitectuur, waarvan objecten de belangrijkste componenten zijn. Ze bieden een reeks services via hun interfaces. Andere objecten verzenden verzoeken zonder onderscheid te maken tussen client en server. Objecten kunnen zich op verschillende computers in een netwerk bevinden en communiceren via middleware, vergelijkbaar met de systeembus, waarmee u verschillende apparaten kunt aansluiten en communicatie tussen hardwareapparaten kunt ondersteunen.

…

ODBC-stuurprogrammabeheer

Bestuurder 1

Bestuurder K

DB 1

DB K

Werken met SQL

…

ODBC-architectuur omvat componenten:

1. Aanvraag (bijv. IS). Het voert taken uit: vraagt ​​om een ​​verbinding met de gegevensbron, verzendt SQL-query's naar de gegevensbron, beschrijft het opslaggebied en de indeling voor SQL-query's, behandelt fouten en stelt de gebruiker op de hoogte, voert transacties uit of zet ze terug, vraagt ​​om een ​​verbinding met de databron.

2. Apparaatbeheer. Het laadt stuurprogramma's op aanvraag van applicaties, biedt een enkele interface voor alle applicaties en de ODBC-beheerdersinterface is hetzelfde en ongeacht met welk DBMS de applicatie zal communiceren. De door Microsoft geleverde Driver Manager is een Dynamic Load Library (DLL).

3. Het stuurprogramma is afhankelijk van het DBMS. Een ODBC-stuurprogramma is een Dynamic Link Library (DLL) die ODBC-functies implementeert en samenwerkt met een gegevensbron. Een stuurprogramma is een programma dat een verzoek voor een functie die specifiek is voor een DBMS verwerkt (het kan verzoeken wijzigen in overeenstemming met het DBMS) en het resultaat terugstuurt naar de toepassing. Elk DBMS dat ODBC-technologie ondersteunt, moet applicatieontwikkelaars voorzien van een stuurprogramma voor dat DBMS.

4. De gegevensbron bevat de door de gebruiker opgegeven besturingsinformatie, informatie over de gegevensbron en wordt gebruikt om toegang te krijgen tot een specifiek DBMS. In dit geval worden de middelen van het besturingssysteem en het netwerkplatform gebruikt.

Dynamisch model

Dit model gaat uit van veel aspecten, waarvoor in UML minimaal 5 diagrammen worden gebruikt, zie pp. 2.04.2- 2.04.5.

Denk aan het managementaspect. Het governancemodel is een aanvulling op de structurele modellen.

Hoe de structuur van het systeem ook wordt beschreven, het bestaat uit een reeks structurele eenheden (functies of objecten). Om ze als een geheel te laten functioneren, moeten ze worden bestuurd en er is geen besturingsinformatie in de statische diagrammen. Regelmodellen ontwerpen de controlestroom tussen systemen.

Er zijn twee hoofdtypen besturing in softwaresystemen.

1. Gecentraliseerd beheer.

2. Event-based management.

Centraal beheer kan zijn:

· hiërarchisch- op basis van het "call-return"-principe (zo werken educatieve programma's meestal)

· Verzendermodel die wordt gebruikt voor parallelle systemen.

V verzender modellen er wordt aangenomen dat een van de componenten van het systeem een ​​dispatcher is. Het beheert zowel het opstarten en afsluiten van systemen en de coördinatie van de rest van de processen in het systeem. Processen kunnen parallel aan elkaar lopen. Een proces verwijst naar een programma, subsysteem of procedure die momenteel wordt uitgevoerd. Dit model kan ook worden toegepast in sequentiële systemen, waarbij het besturingsprogramma individuele subsystemen oproept afhankelijk van enkele toestandsvariabelen (via de operator geval).

Evenementmanagement gaat ervan uit dat er geen subroutine is die verantwoordelijk is voor het beheer. De besturing wordt uitgevoerd door externe gebeurtenissen: een muisknop indrukken, een toetsenbord indrukken, sensormetingen wijzigen, timermetingen wijzigen, enz. Elke externe gebeurtenis wordt gecodeerd en in de gebeurteniswachtrij geplaatst. Als een reactie op een gebeurtenis in de wachtrij wordt gegeven, wordt de procedure (subroutine) aangeroepen, die de reactie op deze gebeurtenis uitvoert. De gebeurtenissen waarop het systeem reageert, kunnen zich voordoen in andere subsystemen of in de externe omgeving van het systeem.

Een voorbeeld van dergelijk beheer is de organisatie van applicaties in Windows.

Alle eerder beschreven structurele modellen kunnen worden geïmplementeerd met behulp van gecentraliseerd beheer of op gebeurtenissen gebaseerd beheer.

Gebruikersomgeving

Bij het ontwikkelen van een interfacemodel moet niet alleen rekening worden gehouden met de taken van de ontworpen software, maar ook met de kenmerken van de hersenen die verband houden met de perceptie van informatie.

III.03.4. a Psychofysische kenmerken van een persoon die verband houden met de perceptie en verwerking van informatie.

Het deel van de hersenen, dat conventioneel een waarnemingsprocessor kan worden genoemd, verwerkt voortdurend, zonder de deelname van het bewustzijn, binnenkomende informatie, vergelijkt deze met ervaringen uit het verleden en slaat deze op.

Wanneer een visueel beeld onze aandacht trekt, komt de informatie die voor ons van belang is in het kortetermijngeheugen terecht. Als onze aandacht niet werd getrokken, verdwijnt de informatie in de opslag en wordt vervangen door de volgende delen.

Op elk moment kan de focus van de aandacht op één punt worden gefixeerd, dus als het nodig wordt om meerdere situaties tegelijkertijd te volgen, verschuift de focus van het ene gevolgde object naar het andere. Tegelijkertijd is de aandacht versnipperd en kunnen sommige details over het hoofd worden gezien. Belangrijk is ook dat perceptie grotendeels gebaseerd is op motivatie.

Wanneer je het kader verandert, worden de hersenen een tijdje geblokkeerd: het beheerst een nieuw beeld en benadrukt de belangrijkste details. Dit betekent dat als je een snelle reactie van de gebruiker nodig hebt, je de afbeeldingen niet abrupt moet veranderen.

Het kortetermijngeheugen is de bottleneck in het informatieverwerkingssysteem van een persoon. De capaciteit is 7 ± 2 niet-aangesloten objecten. Niet-opgeëiste informatie wordt daarin niet langer dan 30 seconden bewaard. Om geen belangrijke informatie voor ons te vergeten, herhalen we deze meestal voor onszelf en werken de informatie bij in het kortetermijngeheugen. Bij het ontwerpen van interfaces moet er dus rekening mee worden gehouden dat de overgrote meerderheid het bijvoorbeeld moeilijk vindt om getallen met meer dan vijf cijfers op een ander scherm te onthouden en in te voeren.

Hoewel de capaciteit en opslagtijd van het langetermijngeheugen onbeperkt is, is de toegang tot informatie niet eenvoudig. Het mechanisme voor het extraheren van informatie uit het langetermijngeheugen is associatief van aard. Om het onthouden van informatie te verbeteren, is deze gekoppeld aan de gegevens die al in het geheugen zijn opgeslagen en is deze gemakkelijk te verkrijgen. Omdat toegang tot het langetermijngeheugen moeilijk is, is het raadzaam te verwachten dat de gebruiker de informatie niet onthoudt, maar dat de gebruiker deze zal herkennen.

III.03.4. b Basiscriteria voor het evalueren van interfaces

Talrijke onderzoeken en onderzoeken uitgevoerd door toonaangevende softwareontwikkelaars hebben aangetoond dat gebruikers waarde hechten aan een interface:

1) gemak van beheersing en memorisatie - schat specifiek de tijd van beheersing en de duur van het bewaren van informatie en geheugen;

2) de snelheid waarmee resultaten worden behaald bij gebruik van het systeem, die wordt bepaald door het aantal opdrachten en instellingen dat met de muis is ingevoerd of geselecteerd;

3) subjectieve tevredenheid over de werking van het systeem (gebruiksgemak, vermoeidheid, enz.).

Bovendien komen voor professionele gebruikers die constant met hetzelfde pakket werken het tweede en derde criterium al snel naar voren, en voor niet-professionele gebruikers die periodiek met software werken en relatief eenvoudige taken uitvoeren - het eerste en het derde.

Vanuit dit oogpunt zijn de beste kenmerken voor professionele gebruikers vandaag de dag interfaces met gratis navigatie, en voor niet-professionele gebruikers - directe manipulatie-interfaces. Het is al lang opgevallen dat bij het uitvoeren van een bestandskopieerbewerking, alle andere zaken gelijk blijvend, de meeste professionals shells zoals Far gebruiken, terwijl niet-professionals Windows "slepen en neerzetten" gebruiken.

III.03.4. c Soorten gebruikersinterfaces

De volgende typen gebruikersinterfaces worden onderscheiden:

Primitief

gratis navigatie

Directe manipulatie.

De interface is primitief

Primitief wordt de interface genoemd die de interactie met de gebruiker organiseert en wordt gebruikt in consolemodus. De enige afwijking van het sequentiële proces dat gegevens bieden, is het doorlopen van meerdere sets gegevens.

Menu-interface.

In tegenstelling tot de primitieve interface, kan de gebruiker een bewerking selecteren uit een speciale lijst die door het programma wordt weergegeven. Deze interfaces veronderstellen de implementatie van vele werkscenario's, waarbij de volgorde van acties wordt bepaald door de gebruikers. De boomstructuur van het menu suggereert dat het moeilijk is om een ​​item in menu's met meer dan twee niveaus te vinden.

Paul M. Duval, Stephen M. Mathias III, Andrew Glover. Software bouwen bij elke wijziging (document)

VI Soloviev Strategie en tactiek van concurrentie in de softwaremarkt (document)

Beschrijving - Creatietechnologieën en (document)

Kaner Sam, Folk Jack, Nguyen Kek Yong. Software testen. Fundamentele concepten van bedrijfsapplicatiebeheer (document)

Tamme Louise. Inleiding tot softwaretesten (document)

Antwoorden op GOS op ACS in 2009 (spiekbriefje)

Normen voor een uniform systeem van softwaredocumentatie (Standaard)

n1.doc

11. Architectuur van gedistribueerde systemen

doelen
Het doel van dit hoofdstuk is om de architectuur van gedistribueerde softwaresystemen te bestuderen. Na het lezen van dit hoofdstuk moet u:

• 
  ken de belangrijkste voor- en nadelen van gedistribueerde systemen;
• 
  inzicht hebben in de verschillende benaderingen die worden gebruikt bij de ontwikkeling van client / server-architecturen;
• 
  de verschillen begrijpen tussen client / server-architectuur en gedistribueerde objectarchitectuur;
• 
  ken het concept van een objectverzoekmakelaar en de principes die zijn geïmplementeerd in de CORBA-normen.

Tegenwoordig worden vrijwel alle grote softwaresystemen gedistribueerd. Een gedistribueerd systeem is een systeem waarin de informatieverwerking niet op één computer is geconcentreerd, maar over meerdere computers is verdeeld. Bij het ontwerpen van gedistribueerde systemen, dat veel gemeen heeft met het ontwerp van andere software, zijn er nog een aantal specifieke kenmerken waarmee rekening moet worden gehouden. Sommige hiervan werden al genoemd in de inleiding tot hoofdstuk 10 toen we naar de client / server-architectuur keken, en worden hier in meer detail besproken.

Aangezien gedistribueerde systemen tegenwoordig wijdverbreid zijn, moeten softwareontwikkelaars bekend zijn met de specifieke kenmerken van hun ontwerp. Tot voor kort waren alle grote systemen grotendeels gecentraliseerd en draaiden ze op een enkele hostcomputer (mainframe) met daaraan gekoppelde terminals. De terminals verwerkten praktisch geen informatie - alle berekeningen werden uitgevoerd op de hostmachine. De ontwikkelaars van dergelijke systemen hoefden niet na te denken over de problemen van gedistribueerd computergebruik.

Alle moderne softwaresystemen kunnen worden onderverdeeld in drie brede klassen.
1. Applicatiesoftwaresystemen die zijn ontworpen om slechts op één pc of werkstation te werken. Deze omvatten tekstverwerkers, spreadsheets, grafische systemen en dergelijke.

2. Geïntegreerde systemen die zijn ontworpen om op een enkele processor of op een geïntegreerde groep processors te draaien. Deze omvatten besturingssystemen voor huishoudelijke apparaten, verschillende apparaten, enz.

3. Gedistribueerde systemen waarin software draait op een zwak geïntegreerde groep parallelle processors die via een netwerk met elkaar zijn verbonden. Deze omvatten ATM-systemen die eigendom zijn van een bank, publicatiesystemen, gedeelde softwaresystemen, enz.
Op dit moment zijn er duidelijke grenzen tussen de genoemde klassen van softwaresystemen, die in de toekomst steeds vager zullen worden. In de loop van de tijd, naarmate draadloze hogesnelheidsnetwerken op grote schaal beschikbaar komen, zal het mogelijk worden om apparaten dynamisch te integreren met embedded softwaresystemen, zoals elektronische organizers met meer algemene systemen.

Het boek identificeert zes hoofdkenmerken van gedistribueerde systemen.
1. Middelen delen. Gedistribueerde systemen maken het delen van hardware- en softwarebronnen mogelijk, zoals harde schijven, printers, bestanden, compilers en dergelijke die via een netwerk zijn verbonden. Het is duidelijk dat het delen van bronnen ook mogelijk is in systemen met meerdere gebruikers, maar in dit geval moet de centrale computer verantwoordelijk zijn voor het beschikbaar stellen van bronnen en het beheer ervan.

2. Openheid. Dit is de mogelijkheid om het systeem uit te breiden door nieuwe bronnen toe te voegen. Gedistribueerde systemen zijn open systemen die hardware en software van verschillende fabrikanten met elkaar verbinden.

3. Parallellisme. In gedistribueerde systemen kunnen meerdere processen gelijktijdig op verschillende computers in een netwerk worden uitgevoerd. Deze processen kunnen (maar hoeven niet) met elkaar te interageren terwijl ze worden uitgevoerd.

4. schaalbaarheid. In principe zijn alle gedistribueerde systemen schaalbaar: om aan nieuwe eisen te voldoen, kan het systeem worden uitgebreid met nieuwe computerbronnen. Maar in de praktijk kan de opbouw beperkt blijven tot het netwerk dat de individuele computers in het systeem verbindt. Als er veel nieuwe machines zijn aangesloten, is de netwerkbandbreedte mogelijk niet voldoende.

5. Fout tolerantie. Door de aanwezigheid van meerdere computers en de mogelijkheid om informatie te dupliceren, zijn gedistribueerde systemen bestand tegen bepaalde hardware- en softwarefouten (zie hoofdstuk 18). De meeste gedistribueerde systemen kunnen in de regel ten minste gedeeltelijke functionaliteit ondersteunen in geval van fouten. Een volledige uitval van het systeem treedt alleen op bij netwerkfouten.

6. Transparantie. Deze eigenschap houdt in dat gebruikers volledig transparante toegang tot bronnen krijgen en tegelijkertijd informatie over de verdeling van bronnen in het systeem voor hen verborgen blijft. In veel gevallen helpt specifieke kennis van de inrichting van het systeem de gebruiker echter om de middelen beter te benutten.
Natuurlijk hebben gedistribueerde systemen een aantal nadelen.

Complexiteit. Gedistribueerde systemen zijn complexer dan gecentraliseerde. Het is veel moeilijker om de eigenschappen van gedistribueerde systemen in het algemeen te begrijpen en te evalueren, en ook om deze systemen te testen. Hierbij zijn de systeemprestaties bijvoorbeeld niet afhankelijk van de snelheid van één processor, maar van de netwerkbandbreedte en de snelheid van de verschillende processors. Het verplaatsen van bronnen van het ene deel van het systeem naar het andere kan de systeemprestaties drastisch beïnvloeden.

Veiligheid. Meestal is het systeem toegankelijk vanaf verschillende machines en kunnen berichten op het netwerk worden bekeken of onderschept. Daarom is het in een gedistribueerd systeem veel moeilijker om de beveiliging te handhaven.

Beheersbaarheid. Het systeem kan bestaan ​​uit verschillende typen computers waarop verschillende versies van besturingssystemen kunnen worden geïnstalleerd. Fouten op de ene machine kunnen zich verspreiden naar andere machines met onvoorspelbare gevolgen. Daarom is er veel meer inspanning nodig om het systeem in goede staat te beheren en te houden.

Onvoorspelbaarheid. Zoals alle internetgebruikers weten, is de reactie van gedistribueerde systemen op bepaalde gebeurtenissen onvoorspelbaar en hangt af van de volledige belasting van het systeem, de organisatie en de netwerkbelasting. Aangezien al deze parameters voortdurend kunnen veranderen, kan de tijd die wordt besteed aan de uitvoering van het verzoek van de gebruiker op een of ander moment aanzienlijk variëren.
Bij de bespreking van de voor- en nadelen van gedistribueerde systemen, identificeert het boek een aantal kritieke ontwerpproblemen voor dergelijke systemen (tabel 11.1). Dit hoofdstuk richt zich op gedistribueerde software-architectuur, omdat ik geloof dat dit het belangrijkste punt is in softwareontwikkeling. Raadpleeg voor andere onderwerpen gespecialiseerde boeken over gedistribueerde systemen.
Tabel 11.1. Ontwerpproblemen met gedistribueerde systemen

Het ontwerpprobleem	Beschrijving
Identificatie van bronnen	Bronnen in een gedistribueerd systeem bevinden zich op verschillende computers, dus het systeem voor het benoemen van bronnen moet worden bedacht, zodat gebruikers gemakkelijk toegang hebben tot en verwijzen naar de bronnen die ze nodig hebben. Een voorbeeld is het Uniform Resource Locator (URL)-systeem, dat de adressen van webpagina's definieert. Zonder een gemakkelijk waarneembaar en universeel identificatiesysteem, zullen de meeste bronnen ontoegankelijk zijn voor de gebruikers van het systeem.
communicatie	De universele bruikbaarheid van internet en de efficiënte implementatie van TCP/IP-protocollen op internet voor de meeste gedistribueerde systemen zijn voorbeelden van de meest effectieve manier om communicatie tussen computers te organiseren. Waar echter speciale eisen worden gesteld aan prestaties, betrouwbaarheid, enz., kunnen alternatieve methoden van systeemcommunicatie worden gebruikt.
Kwaliteit van systeemservice	De servicekwaliteit die door het systeem wordt geboden, weerspiegelt de prestaties, bruikbaarheid en betrouwbaarheid ervan. De kwaliteit van de dienstverlening wordt beïnvloed door een aantal factoren: de verdeling van systeemprocessen, toewijzing van middelen, systeem- en netwerkhardware en het aanpassingsvermogen van het systeem.
Software architectuur	Software-architectuur beschrijft de verdeling van systeemfuncties over systeemcomponenten, evenals de verdeling van deze componenten over processors. Als u een hoogwaardige systeemservice wilt behouden, blijkt het kiezen van de juiste architectuur een beslissende factor te zijn.

De uitdaging voor ontwerpers van gedistribueerde systemen is om software of hardware te ontwerpen die alle vereiste kenmerken van een gedistribueerd systeem biedt. Dit vereist kennis van de voor- en nadelen van verschillende gedistribueerde systeemarchitecturen. Twee verwante typen gedistribueerde systeemarchitecturen vallen hier op.
1. Client/server-architectuur. In dit model kan het systeem worden gezien als een reeks services die door servers aan clients worden geleverd. In dergelijke systemen verschillen de servers en clients aanzienlijk van elkaar.

2. Gedistribueerde objectarchitectuur. In dit geval zijn er geen verschillen tussen servers en clients, en kan het systeem worden gezien als een set van op elkaar inwerkende objecten waarvan de locatie er niet echt toe doet. Er is geen onderscheid tussen de dienstverlener en zijn gebruikers.
In een gedistribueerd systeem kunnen verschillende systeemcomponenten in verschillende programmeertalen worden geïmplementeerd en op verschillende soorten processors worden uitgevoerd. Gegevensmodellen, informatiepresentatie en communicatieprotocollen zijn niet noodzakelijk allemaal van hetzelfde type in een gedistribueerd systeem. Daarom is voor gedistribueerde systemen dergelijke software nodig die deze verschillende soorten onderdelen kan beheren en de interactie en uitwisseling van gegevens daartussen kan garanderen. middleware verwijst precies naar deze klasse van software. Het bevindt zich als het ware in het midden tussen verschillende delen van de gedistribueerde componenten van het systeem.

In dit artikel worden de verschillende typen middleware beschreven die Grid Computing kunnen ondersteunen. Dergelijke software bestaat in de regel uit kant-en-klare componenten en vereist geen speciale aanpassingen van de ontwikkelaars. Voorbeelden van middleware zijn programma's voor het beheer van database-interactie, transactiemanagers, gegevensomzetters, communicatie-inspecteurs, enz. Het volgende hoofdstuk beschrijft de structuur van gedistribueerde systemen als een klasse van middleware.

Gedistribueerde systemen worden meestal ontworpen met een objectgeoriënteerde benadering. Deze systemen zijn gemaakt van losjes geïntegreerde delen, die elk rechtstreeks kunnen communiceren met zowel de gebruiker als andere delen van het systeem. Voor zover mogelijk moeten deze onderdelen reageren op onafhankelijke gebeurtenissen. Softwareobjecten die op deze principes zijn gebaseerd, zijn natuurlijke componenten van gedistribueerde systemen. Als je nog niet bekend bent met het concept van objecten, raad ik je aan eerst hoofdstuk 12 te lezen en daarna weer naar dit hoofdstuk terug te keren.

11.1. Multiprocessor-architectuur

Het eenvoudigste gedistribueerde systeem is het multiprocessorsysteem. Het bestaat uit veel verschillende processen die op verschillende processors kunnen (maar niet hoeven) worden uitgevoerd. Dit model wordt vaak gebruikt in grote real-time systemen. Zoals je in hoofdstuk 13 zult leren, verzamelen deze systemen informatie, nemen ze op basis daarvan beslissingen en sturen ze signalen naar een actuator die de omgeving van het systeem verandert. In principe kunnen alle processen met betrekking tot het verzamelen van informatie, het nemen van beslissingen en het besturen van het uitvoerende mechanisme worden uitgevoerd op één processor onder besturing van de taakplanner. Het gebruik van meerdere processors verbetert de systeemprestaties en herstelbaarheid. De verdeling van processen tussen verwerkers kan geherdefinieerd worden (inherent aan kritische systemen) of aangestuurd door een procesmanager.

In afb. 11.1 toont een voorbeeld van dit type systeem. Dit is een vereenvoudigd model van een verkeersmanagementsysteem. Een groep gedistribueerde sensoren verzamelt informatie over het debiet. De verzamelde gegevens worden ter plaatse verwerkt voordat ze naar de controlekamer worden gestuurd. Op basis van de ontvangen informatie nemen operators beslissingen en regelen ze verkeerslichten. In dit voorbeeld zijn er aparte logische processen voor het aansturen van sensoren, controlekamer en verkeerslichten. Dit kunnen afzonderlijke processen zijn of een groep processen. In ons voorbeeld draaien ze op verschillende processors.

Rijst. 11.1. Multiprocessor verkeersregelsysteem
Softwaresystemen die meerdere processen gelijktijdig uitvoeren, worden niet noodzakelijkerwijs gedistribueerd. Als het systeem meer dan één processor heeft, is het niet moeilijk om procesdistributie te implementeren. Bij het maken van softwaresystemen met meerdere processors is het echter niet nodig om alleen uit te gaan van gedistribueerde systemen. Het ontwerpen van dit type systeem volgt in wezen dezelfde benadering als het ontwerpen van real-time systemen, die in hoofdstuk 13 worden besproken.

11.2. Client / server-architectuur

Hoofdstuk 10 heeft het client / server-concept al behandeld. In een client/server-architectuur wordt een softwaretoepassing gemodelleerd als een set services die door servers worden geleverd en een set clients die die services gebruiken. Clients moeten op de hoogte zijn van de beschikbare (beschikbare) servers, hoewel ze mogelijk niet op de hoogte zijn van het bestaan ​​van andere clients. Zoals blijkt uit afb. 11.2, wat een schematisch diagram is van een gedistribueerde client / server-architectuur, clients en servers vertegenwoordigen verschillende processen.


Rijst. 11.2. Client / serversysteem
Een systeem hoeft geen één-op-één relatie te hebben tussen processen en verwerkers. In afb. 11.3 toont de fysieke architectuur van het systeem, dat bestaat uit zes clientmachines en twee servers. Ze voeren de client- en serverprocessen uit die worden getoond in Fig. 11.2. Als ik het over clients en servers heb, bedoel ik in het algemeen logische processen in plaats van fysieke machines die deze processen uitvoeren.

De client / server-systeemarchitectuur moet de logische structuur van de softwaretoepassing die wordt ontwikkeld weerspiegelen. In afb. 11.4 biedt een andere kijk op de softwaretoepassing, gestructureerd in de vorm van drie lagen. De presentatielaag zorgt voor informatie en interactie met gebruikers. De applicatie runlevel implementeert de logica van de applicatie. Alle databasebewerkingen worden uitgevoerd op het niveau van gegevensbeheer. In gecentraliseerde systemen is er geen duidelijke scheiding tussen deze niveaus. Bij het ontwerpen van gedistribueerde systemen is het echter noodzakelijk om deze lagen te scheiden om vervolgens elke laag op verschillende computers te kunnen plaatsen.

De eenvoudigste client/server-architectuur is two-tier, waarbij een applicatie bestaat uit een server (of veel identieke servers) en een groep clients. Er zijn twee soorten van deze architectuur (Figuur 11.5).
1. Thin client-model. In dit model wordt al het applicatiewerk en databeheer op de server gedaan. Op de clientcomputer wordt alleen software met presentatielaag uitgevoerd.

2. Fat client-model. In dit model beheert de server alleen de gegevens. De clientmachine implementeert de werking van de applicatie en de interactie met de systeemgebruiker.


Rijst. 11.3. Client-/servercomputers

Rijst. 11.4. Applicatie software niveaus
Een two-tier thin client is de eenvoudigste manier om bestaande gecentraliseerde systemen (zie hoofdstuk 26) te migreren naar een client/server-architectuur. De gebruikersinterface in deze systemen "migreert" naar een personal computer, en de softwaretoepassing zelf vervult de functies van een server, d.w.z. voert alle sollicitatieprocessen uit en beheert gegevens. Het thin client-model kan ook worden geïmplementeerd waar clients gewone netwerkapparaten zijn in plaats van pc's of werkstations. De netwerkapparaten draaien de internetbrowser en de gebruikersinterface die in het systeem is geïmplementeerd.


Rijst. 11.5. Thin en fat client-modellen
Het grootste nadeel van het thin client-model is de hoge belasting van de server en het netwerk. Alle berekeningen worden uitgevoerd op de server en dit kan resulteren in aanzienlijk netwerkverkeer tussen de client en de server. Er is voldoende rekenkracht in moderne computers, maar die wordt praktisch niet gebruikt in het thin client-model van de bank.

Het dikke clientmodel daarentegen gebruikt de verwerkingskracht van lokale machines: zowel de applicatieruntime als de presentatielaag worden op de clientcomputer geplaatst. De server hier is in wezen een transactieserver die alle databasetransacties beheert. Een voorbeeld van dit type architectuur zijn ATM-systemen waarbij de ATM de client is en de server de centrale computer die de debiteurendatabase bedient.

In afb. 11.6 toont een genetwerkt ATM-systeem. Houd er rekening mee dat de geldautomaten niet rechtstreeks zijn verbonden met de factureringsdatabase, maar via de teleprocessing-monitor. Deze monitor is een tussenpersoon die communiceert met externe klanten en klantverzoeken organiseert in een reeks transacties om met de database te werken. Door sequentiële transacties te gebruiken wanneer er storingen optreden, kan het systeem herstellen zonder gegevensverlies.


Rijst. 11.6. Client-/serversysteem voor ATM-netwerk
Omdat het thick client-model efficiënter is in het uitvoeren van een softwaretoepassing dan het thin client-model, is het moeilijker te beheren. Hier zijn de functies van de app verspreid over veel verschillende machines. De noodzaak om een ​​applicatie te vervangen leidt tot herinstallatie op alle clientcomputers, wat duur is als er honderden clients in het systeem zijn.

De komst van de Java-taal en downloadbare applets heeft de ontwikkeling mogelijk gemaakt van client/server-modellen die ergens tussen thin en thick client-modellen in vallen. Sommige programma's waaruit de toepassing bestaat, kunnen als Java-applets op de clientcomputer worden geladen en zo de server ontlasten. De gebruikersinterface is gebouwd via een webbrowser die Java-applets uitvoert. Webbrowsers van verschillende leveranciers, en zelfs verschillende versies van webbrowsers van dezelfde leverancier, werken echter niet altijd op dezelfde manier. Eerdere versies van browsers op oudere machines voeren mogelijk niet altijd Java-applets uit. Daarom moet deze benadering alleen worden gebruikt als u zeker weet dat alle gebruikers op het systeem Java-compatibele browsers hebben geïnstalleerd.

In een client/server-model met twee niveaus is een belangrijk probleem de plaatsing van drie logische lagen op twee computersystemen: presentatie, toepassingsuitvoering en gegevensbeheer. Daarom heeft dit model vaak schaalbaarheids- en prestatieproblemen als het thin client-model wordt gekozen, of systeembeheerproblemen als het thick client-model wordt gebruikt. Om deze problemen te vermijden, is een alternatieve benadering om het drieledige client/server-architectuurmodel te gebruiken (Figuur 11.7). In deze architectuur komen afzonderlijke processen overeen met de lagen presentatie, applicatie-uitvoering en gegevensbeheer.


Rijst. 11.7. Drieledige client/server-architectuur
De software-architectuur, gebouwd op een drielaags client/server-model, vereist niet dat drie computersystemen op een netwerk zijn aangesloten. Op dezelfde servercomputer kunt u zowel toepassingsuitvoering als gegevensbeheer als afzonderlijke logische servers uitvoeren. Tegelijkertijd, als de systeemvereisten toenemen, zal het relatief eenvoudig zijn om applicatie-uitvoering en databeheer te scheiden en op verschillende processors uit te voeren.

Een banksysteem dat gebruik maakt van internetdiensten kan worden geïmplementeerd met behulp van een drieledige client/server-architectuur. De factureringsdatabase (meestal op de hostcomputer) biedt gegevensbeheerservices, de webserver ondersteunt toepassingsservices zoals geldoverdrachtfaciliteiten, het genereren van rapporten, het betalen van facturen, enz. En de computer van de gebruiker met een internetbrowser is de client. Zoals getoond in afb. 11.8 is het systeem schaalbaar omdat het relatief eenvoudig is om er nieuwe webservers aan toe te voegen naarmate het aantal clients toeneemt.

Door de drielaagse architectuur in dit voorbeeld te gebruiken, wordt de gegevensoverdracht tussen de webserver en de databaseserver geoptimaliseerd. Interoperabiliteit tussen deze systemen hoeft niet gebaseerd te zijn op internetstandaarden; er kunnen snellere, low-level communicatieprotocollen worden gebruikt. Doorgaans wordt de informatie uit de database verwerkt door efficiënte middleware die query's op de database ondersteunt in de gestructureerde SQL-querytaal.

In sommige gevallen kan een drielaags client/server-model worden geconverteerd naar een meerlaags model door extra servers aan het systeem toe te voegen. Gelaagde systemen kunnen ook worden gebruikt waar applicaties toegang moeten hebben tot informatie die zich in verschillende databases bevindt. In dit geval bevindt de federatieve server zich tussen de server waarop de toepassing wordt uitgevoerd en de databaseservers. De federatieve server verzamelt gedistribueerde gegevens en presenteert deze aan de toepassing alsof ze zich in dezelfde database bevinden.


Rijst. 11.8. Gedistribueerde architectuur van het banksysteem met behulp vaninternet-Diensten
Ontwerpers van client/server-architecturen moeten rekening houden met een aantal factoren bij het kiezen van de meest geschikte. Tafel 11.2 geeft een overzicht van de verschillende use-cases voor de client / server-architectuur.
Tabel 11.2. Toepassing van verschillende soorten client / server-architectuur

architectuur	Toepassingen
Two-tier thin client-architectuur	Legacy systemen waarin het onpraktisch is om applicatie-uitvoering en databeheer te scheiden.
	Rekenintensieve toepassingen, zoals compilers, maar met weinig gegevensmanipulatie.
	Applicaties die grote hoeveelheden data (query's) verwerken, maar met weinig rekenwerk in de applicatie zelf
Two-tier dikke client-architectuur	Toepassingen waarbij de gebruiker intensieve gegevensverwerking vereist (bijvoorbeeld gegevensvisualisatie of grote hoeveelheden rekenkracht).
	Toepassingen met een relatief constante set gebruikersfuncties die worden gebruikt in een goed afgestemde systeembeheeromgeving

11.3. Architectuur van gedistribueerde objecten

In het client/server-model van een gedistribueerd systeem zijn er verschillen tussen clients en servers. De client vraagt ​​alleen diensten aan van de server, hq niet van andere clients; servers kunnen functioneren als clients en diensten aanvragen bij andere servers, maar niet bij clients; klanten moeten op de hoogte zijn van de diensten die door specifieke servers worden geleverd en hoe die servers communiceren. Dit model is geweldig voor veel soorten toepassingen, maar beperkt tegelijkertijd de systeemontwikkelaars die moeten beslissen waar ze diensten willen leveren. Ze moeten ook schaalbaarheidsondersteuning bieden en een manier ontwikkelen om clients op gedistribueerde servers in het systeem te integreren.

Een meer algemene benadering bij het ontwerp van gedistribueerde systemen is om het onderscheid tussen client en server te vervagen en de systeemarchitectuur te ontwerpen als een gedistribueerde objectarchitectuur. In deze architectuur (Figuur 11.9) zijn de belangrijkste componenten van het systeem objecten die via hun interfaces een reeks services leveren. Andere objecten roepen deze services aan zonder onderscheid te maken tussen de client (de gebruiker van de service) en de server (de serviceprovider).


Rijst. 11.9. Architectuur van gedistribueerde objecten
Objecten kunnen zich op verschillende computers in het netwerk bevinden en communiceren via middleware. Naar analogie met de systeembus, waarmee u verschillende apparaten kunt aansluiten en de communicatie tussen hardware kunt onderhouden, kan middleware worden gezien als een softwarebus. Het biedt een reeks services waarmee objecten met elkaar kunnen communiceren, ze kunnen toevoegen aan of verwijderen uit het systeem. Middleware wordt een object request broker genoemd. Het is zijn taak om een ​​interface tussen objecten te bieden. Objectquery-makelaars worden besproken in paragraaf 11.4.

Hieronder volgen de belangrijkste voordelen van het architectuurmodel voor gedistribueerde objecten.
Systeemontwerpers kunnen traag beslissingen nemen over waar en hoe diensten worden geleverd. Objecten die services leveren, kunnen overal (knooppunt) in het netwerk worden uitgevoerd. Bijgevolg wordt het onderscheid tussen de dikke en de thin client-modellen irrelevant, aangezien het niet nodig is om vooruit te plannen voor de plaatsing van objecten om de applicatie te laten draaien.

De systeemarchitectuur is open genoeg om indien nodig nieuwe bronnen aan het systeem toe te voegen. In het volgende gedeelte wordt opgemerkt dat de codebusstandaarden voortdurend evolueren, waardoor objecten die in verschillende programmeertalen zijn geschreven, kunnen communiceren en diensten aan elkaar kunnen verlenen.

Flexibiliteit en schaalbaarheid van het systeem. Om systeembelastingen aan te kunnen, kunt u instanties van het systeem maken met dezelfde services, die worden geleverd door verschillende objecten of verschillende instanties (kopieën) van objecten. Naarmate de belasting toeneemt, kunnen nieuwe objecten aan het systeem worden toegevoegd zonder de werking van andere objecten te onderbreken.

Het is mogelijk om het systeem dynamisch te herconfigureren door middel van objecten die op aanvraag in het netwerk migreren. Dienstverlenende objecten kunnen migreren naar dezelfde processor als servicevragende objecten, waardoor de systeemprestaties worden verbeterd.
In het systeemontwerpproces kan gedistribueerde objectarchitectuur op twee manieren worden gebruikt.
1. Als een logisch model waarmee ontwikkelaars het systeem kunnen structureren en plannen. In dit geval wordt de functionaliteit van de applicatie alleen beschreven in termen en combinaties van services. Vervolgens worden manieren ontwikkeld om services te leveren met behulp van meerdere gedistribueerde objecten. Op dit niveau worden in de regel grofkorrelige objecten ontworpen die services bieden die de specifieke kenmerken van een specifiek gebied van de toepassing weerspiegelen. In een boekhoudprogramma voor de detailhandel kunt u bijvoorbeeld objecten opnemen die de status van voorraden bijhouden, interacties met klanten volgen, producten classificeren en meer.

2. Als flexibele benadering van de implementatie van client / server-systemen. In dit geval is het logische systeemmodel een client/server-model, waarin clients en servers zijn geïmplementeerd als gedistribueerde objecten die via de bus samenwerken. Met deze aanpak is het eenvoudig om een ​​systeem te vervangen, bijvoorbeeld een systeem met twee lagen door een systeem met meerdere lagen. In dit geval kunnen noch de server, noch de client in één object worden geïmplementeerd, maar ze kunnen wel uit veel kleine objecten bestaan, die elk een specifieke service bieden.
Een voorbeeld van een systeem dat geschikt is voor een gedistribueerde objectarchitectuur is een systeem voor het verwerken van gegevens die zijn opgeslagen in verschillende databases (Figuur 11.10). In dit voorbeeld kan elke database worden gezien als een object met een interface die alleen-lezen gegevenstoegang biedt. Elk van de integratorobjecten behandelt bepaalde soorten gegevensafhankelijkheden en verzamelt informatie uit databases om te proberen deze afhankelijkheden te traceren.

Visualizer-objecten werken samen met integrator-objecten om gegevens in grafische vorm te presenteren of om rapporten over de geanalyseerde gegevens te genereren. De presentatie van grafische informatie wordt besproken in hoofdstuk 15.


Rijst. 11.10. Systeemarchitectuur voor gedistribueerde gegevensverwerking
Voor dit type toepassing is gedistribueerde objectarchitectuur om drie redenen geschikter dan client/server-architectuur.
1. In deze systemen (in tegenstelling tot bijvoorbeeld het ATM-systeem) is er niet één dienstverlener waarop alle datamanagementdiensten zouden worden geconcentreerd.

2. Het is mogelijk om het aantal beschikbare databases te vergroten zonder de systeemwerking te onderbreken, aangezien elke database slechts een object is. Deze objecten ondersteunen een vereenvoudigde interface die de gegevenstoegang regelt. De beschikbare databases kunnen op verschillende machines worden geplaatst.

3. Door nieuwe integratorobjecten toe te voegen, kunt u nieuwe soorten gegevensafhankelijkheden volgen.
Het belangrijkste nadeel van gedistribueerde objectarchitecturen is dat ze moeilijker te ontwerpen zijn dan client-/serversystemen. Het blijkt dat client-/serversystemen een meer natuurlijke benadering bieden voor het bouwen van gedistribueerde systemen. Het weerspiegelt de relatie tussen mensen waarbij sommige mensen gebruik maken van de diensten van andere mensen die gespecialiseerd zijn in het leveren van specifieke diensten. Het is veel moeilijker om een ​​systeem te ontwerpen volgens de architectuur van gedistribueerde objecten, omdat de software-industrie nog niet voldoende ervaring heeft opgedaan met het ontwerpen en ontwikkelen van grootschalige objecten.

11.4. CORBA

Zoals opgemerkt in de vorige sectie, vereist het implementeren van een gedistribueerde objectarchitectuur middleware (objectquerybrokers) die de communicatie tussen gedistribueerde objecten organiseert. Hier kunnen zich bepaalde problemen voordoen, aangezien objecten in het systeem in verschillende programmeertalen kunnen worden geïmplementeerd, ze op verschillende platforms kunnen draaien en hun namen niet bekend mogen zijn bij alle andere objecten in het systeem. Daarom moet de middleware veel werk doen om een ​​constante interactie tussen objecten te behouden.

Er zijn momenteel twee belangrijke middleware-standaarden om gedistribueerde objectcomputing te ondersteunen.
1. CORBA (Common Object Request Broker Architecture). Het is een set standaarden voor middleware ontwikkeld door de OMG (Object Management Group). OMG is een consortium van hardware- en softwarebedrijven, waaronder Sun, Hewlett-Packard en IBM. CORBA-standaarden definiëren een algemene machineonafhankelijke benadering van gedistribueerde objectcomputing. Veel implementaties van deze standaard zijn ontwikkeld door verschillende fabrikanten. CORBA-standaarden worden ondersteund door het Unix-besturingssysteem en Microsoft-besturingssystemen.

2. DCOM (Distributed Component Object Model). DCOM is een standaard die is ontwikkeld en geïmplementeerd door Microsoft en is geïntegreerd in zijn besturingssystemen. Dit gedistribueerde computermodel is minder veelzijdig dan CORBA en biedt beperktere netwerkmogelijkheden. DCOM is momenteel beperkt tot Microsoft-besturingssystemen.
Hier besloot ik aandacht te besteden aan CORBA-technologie, omdat deze universeler is. Daarnaast denk ik dat het waarschijnlijk is dat CORBA, DCOM en andere technologieën, zoals RMI (Remote Method Invocation, een technologie voor het bouwen van gedistribueerde applicaties in de Java-taal), geleidelijk met elkaar zullen convergeren en deze convergentie zal gebaseerd zijn op normen CORBA. Er is dus geen behoefte aan een andere norm. Verschillende standaarden zullen de verdere ontwikkeling alleen maar belemmeren.

CORBA-normen worden gedefinieerd door de OMG, een groep van meer dan 500 objectgeoriënteerde ontwikkelingsbedrijven. De rol van de OMG is om standaarden te creëren voor objectgeoriënteerde ontwikkeling, niet om specifieke implementaties van die standaarden te bieden. Deze standaarden zijn vrij beschikbaar op de OMG-website. De groep houdt zich niet alleen bezig met CORBA-standaarden, maar definieert ook een breed scala aan andere standaarden, waaronder de UML-modelleringstaal.

De CORBA-weergave van gedistribueerde applicaties wordt weergegeven in figuur 1. 11.11. Dit is een vereenvoudigd diagram van de objectbeheerarchitectuur uit het artikel. Een gedistribueerde applicatie zal naar verwachting uit de volgende componenten bestaan.
1. Applicatieobjecten die voor dit softwareproduct zijn gemaakt en ontwikkeld.

2. Standaardobjecten die door de OMG zijn gedefinieerd voor specifieke taken. Op het moment van schrijven hebben veel professionals facilitaire normen ontwikkeld op het gebied van financiën, verzekeringen, e-commerce, gezondheidszorg en meer.

3. Core CORBA-services die core Grid-computingservices ondersteunen, zoals directory's, beveiligingsbeheer en meer.

4. Horizontale CORBA-voorzieningen zoals gebruikersinterfaces, systeembesturingen, etc. Horizontaal betekent dat veel toepassingen gemeen hebben.


Rijst. 11.11. Kader voor een op standaarden gebaseerde gedistribueerde toepassingCORBA
CORBA-normen beschrijven vier hoofdelementen.
1. Een objectmodel waarin een CORBA-object toestanden inkapselt door middel van duidelijke beschrijvingen in Interface Definition Language (IDL).

2. Object Request Broker (ORB), die verzoeken om bezwaarservices beheert. De ORB plaatst objecten die services leveren, bereidt ze voor op het ontvangen van aanvragen, geeft de aanvraag door aan de service en stuurt de resultaten terug naar het object dat de aanvraag heeft gedaan.

3. Een verzameling objectservices, die kernservices zijn die nodig zijn in veel gedistribueerde toepassingen. Voorbeelden zijn directoryservices, transactieservices en tijdelijke objectondersteuningsservices.

4. Een verzameling gemeenschappelijke componenten gebouwd op het hoogste niveau van basisdiensten. Ze kunnen zowel verticaal zijn, de specifieke kenmerken van een bepaald gebied weerspiegelen, als horizontale universele componenten die in veel softwaretoepassingen worden gebruikt. Deze componenten worden besproken in hoofdstuk 14.
In CORBA kapselt een object attributen en services in zoals een gewoon object. CORBA-objecten moeten echter ook de verschillende interfaces definiëren die de globale attributen en bewerkingen van het object beschrijven. CORBA-objectinterfaces worden gedefinieerd in de IDL-standaard universele interfacebeschrijvingstaal. Als een object services aanvraagt ​​die door andere objecten worden geleverd, krijgt het toegang tot die services via de IDL-interface. CORBA-objecten hebben een unieke identifier genaamd IOR (Interoperable Object Reference). Wanneer een entiteit verzoeken doet aan een dienst die door een andere entiteit wordt geleverd, wordt de IOR-identificatiecode gebruikt.

De object request broker kent de objecten die services aanvragen en hun interfaces. Het organiseert de interactie tussen objecten. Interactieve objecten hoeven niets te weten over de plaatsing van andere objecten of hun implementatie. Omdat de IDL-interface objecten ontkoppelt van de broker, kunt u de implementatie van het object wijzigen zonder andere systeemcomponenten te beïnvloeden.

In afb. 11.12 laat zien hoe objecten ol en o2 interageren via een object request broker. De beller (ol) is gekoppeld aan een IDL-stub die de interface definieert van het object dat de service levert. De oude objectconstructor injecteert bij het aanvragen van een service de aanroepen in zijn objectimplementatie-stub. IDL is een uitbreiding van C ++, dus als u programmeert in C ++, C of Java, is toegang tot de stub eenvoudig. Vertaling van de objectinterfacebeschrijving naar IDL is ook mogelijk voor andere talen, zoals Ada of COBOL. Maar in deze gevallen is passende instrumentele ondersteuning nodig.

Rijst. 11.12. Interactie met objecten met behulp van een objectaanvraagmakelaar
Het object dat de service levert, is gekoppeld aan het IDL-skelet, dat de interface aan de service-implementatie bindt. Met andere woorden, wanneer een service wordt aangeroepen via een interface, vertaalt het IDL-framework de aanroep naar de service, ongeacht de taal die bij de implementatie werd gebruikt. Wanneer een methode of procedure is voltooid, vertaalt het framework de resultaten naar IDL zodat ze beschikbaar zijn voor de beller. Als een object tegelijkertijd services levert aan andere objecten, of services gebruikt die elders worden geleverd, heeft het zowel een IDL-skelet als een IDL-stub nodig. Dit laatste is nodig voor alle gebruikte objecten.

Een objectquerybroker wordt meestal niet geïmplementeerd als afzonderlijke processen, maar als een raamwerk (zie hoofdstuk 14) dat is gekoppeld aan de implementatie van objecten. Daarom moet in een gedistribueerd systeem elke computer waarop objecten worden uitgevoerd, zijn eigen objectverzoekmakelaar hebben die alle lokale aanroepen van objecten afhandelt. Maar als er een verzoek wordt gedaan aan een dienst die wordt geleverd door een externe entiteit, is communicatie tussen makelaars vereist.

Deze situatie wordt geïllustreerd in Fig. 11.13. Als in dit voorbeeld het ol- of o2-object verzoeken verzendt naar de services die worden geleverd door de o3- of o4-objecten, moeten de brokers die aan deze objecten zijn gekoppeld, samenwerken. De CORBA-standaarden ondersteunen broker-broker-communicatie, die brokers toegang geeft tot IDL-interfacebeschrijvingen, en bieden het OMG's Generic Inter-ORB Protocol (GIOP). Dit protocol definieert standaardberichten die makelaars kunnen uitwisselen bij het bellen naar een object op afstand en het overdragen van informatie. In combinatie met het low-level internetprotocol TCP/IP stelt dit protocol makelaars in staat om via internet te communiceren.

De eerste varianten van CORBA werden al in de jaren tachtig ontwikkeld. Eerdere versies van CORBA waren simpelweg gerelateerd aan ondersteuning voor gedistribueerde objecten. In de loop van de tijd zijn de normen echter geëvolueerd, uitgebreider geworden. Net als mechanismen voor gedistribueerde objectcommunicatie, definiëren de CORBA-standaarden nu enkele standaardservices die kunnen worden gebruikt om objectgeoriënteerde toepassingen te ondersteunen.


Rijst. 11.13. Interoperabiliteit tussen objectverzoekmakelaars
CORBA-services zijn hulpmiddelen die in veel gedistribueerde systemen vereist zijn. Deze standaarden definiëren ongeveer 15 gemeenschappelijke services (services). Hier zijn er enkele.
1. Een naamgevingsservice waarmee objecten andere objecten op het netwerk kunnen vinden en ernaar kunnen verwijzen. Een naamgevingsservice is een directoryservice die namen aan objecten toewijst. Objecten via deze service kunnen indien nodig IOR-ID's van andere objecten vinden.

2. Een registratieservice waarmee objecten andere objecten kunnen registreren nadat bepaalde gebeurtenissen hebben plaatsgevonden. Met deze service kunnen objecten worden geregistreerd door hun deelname aan een bepaald evenement, en wanneer dit evenement al heeft plaatsgevonden, wordt dit automatisch geregistreerd door de service.

3. Een transactieservice die atomaire transacties ondersteunt en terugdraait in geval van fouten of storingen. Deze service is een fouttolerante tool (zie hoofdstuk 18) die herstel biedt van fouten tijdens een updatebewerking. Als de acties om een ​​object bij te werken tot fouten of een systeemstoring leiden, kunt u het object altijd terugzetten in de staat waarin het verkeerde voordat de update begon.
Er wordt aangenomen dat CORBA-standaarden interfacedefinities moeten bevatten voor een breed scala aan componenten die kunnen worden gebruikt om gedistribueerde applicaties te bouwen. Deze componenten kunnen verticaal of horizontaal zijn. Verticale componenten zijn specifiek ontworpen voor specifieke toepassingen. Zoals gezegd zijn er veel mensen uit verschillende disciplines betrokken bij het ontwikkelen van definities voor deze componenten. Horizontale componenten zijn veelzijdig, zoals componenten van de gebruikersinterface.

Op het moment van schrijven zijn componentspecificaties ontwikkeld, maar nog niet overeengekomen. Vanuit mijn perspectief is dit waarschijnlijk het zwakste punt van de CORBA-normen, en het kan enkele jaren duren om het punt te bereiken waarop zowel de specificaties als de implementatie van de componenten aanwezig zijn.
BELANGRIJKSTE CONCEPTEN
Alle grote systemen in in verschillende mate worden gedistribueerd, waarbij softwarecomponenten op een netwerkgeïntegreerde groep processors draaien.

Gedistribueerde systemen hebben de volgende kenmerken: gebruik van hulpbronnen, openheid, gelijktijdigheid, schaalbaarheid, fouttolerantie en transparantie.

Client/server systemen worden gedistribueerd. Dergelijke systemen worden gemodelleerd als een reeks services die door een server aan clientprocessen worden geleverd.

In een client / server-systeem bevindt de gebruikersinterface zich aan de clientzijde en wordt gegevensbeheer altijd ondersteund op de gedeelde server. Applicatiefuncties kunnen worden geïmplementeerd op een clientcomputer of op een server.

In een gedistribueerde objectarchitectuur is er geen onderscheid tussen clients en servers. Objecten bieden basisservices die andere objecten kunnen aanroepen. Dezelfde aanpak kan worden gebruikt bij de implementatie van client / server-systemen.

Gedistribueerde objectsystemen moeten middleware hebben die is ontworpen om interacties tussen objecten af ​​te handelen en om objecten aan het systeem toe te voegen of te verwijderen. Conceptueel kan middleware worden gezien als een softwarebus waarmee objecten zijn verbonden.

CORBA-standaarden zijn een reeks standaarden voor middleware die gedistribueerde objectarchitectuur ondersteunen. Deze omvatten definities voor het objectmodel, objectverzoekmakelaar en gedeelde services. Er zijn momenteel verschillende implementaties van de CORBA-normen.
Opdrachten
11.1. Leg uit waarom gedistribueerde systemen altijd beter schaalbaar zijn dan gecentraliseerde. Wat is de waarschijnlijke grens van schaalbaarheid van softwaresystemen?

11.2. Wat is het belangrijkste verschil tussen dikke en dunne clientmodellen bij client-/serverontwikkeling? Leg uit waarom het gebruik van Java als implementatietaal de verschillen tussen deze modellen afvlakt?

11.3. Op basis van het toepassingsmodel getoond in Fig. 11.4, overweeg dan de mogelijke uitdagingen waarmee u te maken kunt krijgen bij het converteren van een mainframe-zorgsysteem uit de jaren 80 naar een client/server-architectuursysteem.

11.4. Client / server gedistribueerde systemen zijn ontwikkeld sinds de jaren tachtig, maar pas recent zijn dergelijke gedistribueerde objectsystemen geïmplementeerd. Geef drie redenen waarom dit is gebeurd.

11.5. Leg uit waarom het gebruik van gedistribueerde objecten met een objectquerybroker de implementatie van schaalbare client-/serversystemen vereenvoudigt. Illustreer je antwoord met een voorbeeld.

11.6. Hoe wordt IDL gebruikt om communicatie te ondersteunen tussen objecten die in verschillende programmeertalen zijn geïmplementeerd? Leg uit waarom deze aanpak prestatieproblemen kan veroorzaken als er radicale verschillen zijn tussen de talen die worden gebruikt om de objecten te implementeren.

11.7. Welke basishulpmiddelen moet een objectquery-makelaar bieden?

11.8. Het kan worden aangetoond dat de ontwikkeling van CORBA-normen voor horizontale en verticale componenten de concurrentie beperkt. Als ze al zijn gemaakt en aangepast, ontmoedigt het kleinere bedrijven om betere componenten te ontwikkelen. Bespreek de rol van standaardisatie bij het ondersteunen of beperken van concurrentie op de softwaremarkt.

Volgens de bekende expert op het gebied van informatica E. Tanenbaum is er geen algemeen aanvaarde en tegelijkertijd strikte definitie van een gedistribueerd systeem. Sommige geesten beweren dat gedistribueerd zo is computersysteem, waarbij een storing van een computer, waarvan gebruikers het bestaan ​​niet eens vermoedden, leidt tot de beëindiging van al hun werk. Een aanzienlijk deel van de gedistribueerde computersystemen voldoet helaas aan deze definitie, maar formeel verwijst het alleen naar systemen met een uniek kwetsbaarheidspunt ( single point of failure).

Bij het definiëren van een gedistribueerd systeem ligt de nadruk vaak op de verdeling van zijn functies over meerdere computers. Met deze benadering wordt elke gedistribueerd computersysteem waarbij de gegevensverwerking is verdeeld over twee of meer computers. Op basis van de definitie van E. Tanenbaum kan een wat nauwer gedistribueerd systeem worden gedefinieerd als een reeks onafhankelijke computers die zijn verbonden door communicatiekanalen, die, vanuit het oogpunt van een gebruiker van bepaalde software, eruitzien als één geheel.

Deze benadering voor het definiëren van een gedistribueerd systeem heeft zijn nadelen. Alles wat bijvoorbeeld in zo'n gedistribueerd systeem wordt gebruikt software zou op een enkele computer kunnen werken, maar vanuit het oogpunt van de bovenstaande definitie zal een dergelijk systeem niet langer worden gedistribueerd. Daarom zou het concept van een gedistribueerd systeem waarschijnlijk gebaseerd moeten zijn op de analyse van de software die een dergelijk systeem vormt.

Beschouw als basis voor het beschrijven van de interactie van twee entiteiten het algemene model van client-server-interactie, waarbij een van de partijen (de client) de uitwisseling van gegevens initieert door een verzoek naar de andere partij (de server) te sturen. De server verwerkt het verzoek en stuurt, indien nodig, een reactie naar de client (Fig. 1.1).

Rijst. 1.1.

Interactie binnen het raamwerk van het client-servermodel kan ofwel synchroon zijn, wanneer de cliënt wacht tot de server zijn verzoek verwerkt, ofwel asynchroon, waarbij de cliënt een verzoek naar de server stuurt en de uitvoering voortzet zonder te wachten op het verzoek van de server. antwoord. Het client-servermodel kan worden gebruikt als basis voor het beschrijven van verschillende interacties. Voor deze cursus is de interactie van de samenstellende delen van de software die een gedistribueerd systeem vormen van belang.

Rijst. 1.2.

Overweeg een bepaalde typische toepassing die, in overeenstemming met moderne concepten, kan worden onderverdeeld in de volgende logische niveaus (Fig. 1.2): gebruikersomgeving(PI), applicatielogica (LP) en datatoegang (DD), werken met de database (DB). De systeemgebruiker communiceert ermee via de gebruikersinterface, de database slaat gegevens op die het applicatiedomein beschrijven, en de applicatielogicalaag implementeert alle algoritmen die verband houden met gebied.

Aangezien in de praktijk verschillende gebruikers van het systeem gewoonlijk geïnteresseerd zijn in toegang tot dezelfde gegevens, is de eenvoudigste scheiding van de functies van een dergelijk systeem tussen verschillende computers de scheiding van de logische lagen van de toepassing tussen één servergedeelte van de toepassing , die verantwoordelijk is voor de toegang tot de gegevens, en de client-onderdelen die zich op verschillende computers bevinden en de gebruikersinterface implementeren. Applicatielogica kan worden toegewezen aan de server, clients of onderling worden gedeeld (Figuur 1.3).

Rijst. 1.3.

De architectuur van applicaties die op dit principe zijn gebouwd, wordt client-server of two-tier genoemd. In de praktijk worden dergelijke systemen vaak niet geclassificeerd als gedistribueerd, maar formeel kunnen ze worden beschouwd als de eenvoudigste vertegenwoordigers van gedistribueerde systemen.

De ontwikkeling van de client-server-architectuur is een architectuur met drie niveaus, waarin de gebruikersinterface, applicatielogica en gegevenstoegang zijn gescheiden in onafhankelijke componenten van het systeem die op onafhankelijke computers kunnen werken (Fig. 1.4).

Rijst. 1.4.

Het verzoek van de gebruiker in dergelijke systemen wordt achtereenvolgens verwerkt door het clientgedeelte van het systeem, de logische applicatieserver en de databaseserver. Een gedistribueerd systeem wordt echter meestal begrepen als een systeem met een complexere architectuur dan een systeem met drie niveaus.

(Sitemateriaal http://se.math.spbu.ru)

Invoering.

Tegenwoordig worden vrijwel alle grote softwaresystemen gedistribueerd. Gedistribueerd systeem- een systeem waarin de informatieverwerking niet op één computer is geconcentreerd, maar over meerdere computers is verdeeld. Bij het ontwerp van gedistribueerde systemen, dat veel gemeen heeft met softwareontwerp in het algemeen, zijn er nog enkele details waarmee rekening moet worden gehouden.

Er zijn zes hoofdkenmerken van gedistribueerde systemen.

1. Middelen delen. Gedistribueerde systemen maken het delen van zowel hardware (harde schijven, printers) als software (bestanden, compilers) mogelijk.
2. Openheid.Het is de mogelijkheid om het systeem uit te breiden door nieuwe bronnen toe te voegen.
3. Parallellisme.In gedistribueerde systemen kunnen meerdere processen gelijktijdig op verschillende computers in het netwerk worden uitgevoerd. Deze processen kunnen interageren terwijl ze worden uitgevoerd.
4. schaalbaarheid . Onder schaalbaarheid de mogelijkheid om nieuwe eigenschappen en methoden toe te voegen wordt begrepen.
5. Fout tolerantie. De aanwezigheid van meerdere computers maakt duplicatie van informatie en weerstand tegen sommige hardware- en softwarefouten mogelijk. Gedistribueerde systemen kunnen gedeeltelijke functionaliteit ondersteunen in geval van fouten. Een volledige storing van het systeem treedt alleen op bij netwerkfouten.
6. Transparantie.Gebruikers krijgen volledige toegang tot de bronnen in het systeem, terwijl tegelijkertijd informatie over de verdeling van bronnen door het systeem voor hen wordt verborgen.

Gedistribueerde systemen hebben ook een aantal nadelen.

1. Complexiteit... Het is veel moeilijker om de eigenschappen van gedistribueerde systemen in het algemeen te begrijpen en te evalueren, en ze zijn moeilijker te ontwerpen, testen en onderhouden. Ook zijn de systeemprestaties afhankelijk van de snelheid van het netwerk en niet van individuele processors. Hertoewijzing van middelen kan de snelheid van het systeem aanzienlijk veranderen.
2. Veiligheid... Doorgaans is het systeem toegankelijk vanaf verschillende machines, berichten op het netwerk kunnen worden gecontroleerd en onderschept. Daarom is het in een gedistribueerd systeem veel moeilijker om de beveiliging te handhaven.
3. Beheersbaarheid... Het systeem kan bestaan ​​uit verschillende typen computers waarop verschillende versies van besturingssystemen kunnen worden geïnstalleerd. Fouten op de ene machine kunnen zich op een onvoorspelbare manier voortplanten naar andere machines.
4. Onvoorspelbaarheid ... De reactie van gedistribueerde systemen op sommige gebeurtenissen is onvoorspelbaar en hangt af van de volledige belasting van het systeem, de organisatie en de netwerkbelasting. Aangezien deze parameters voortdurend kunnen veranderen, kan de reactietijd op het verzoek daarom aanzienlijk verschillen van de tijd.

Aan deze tekortkomingen kun je zien dat er bij het ontwerpen van gedistribueerde systemen een aantal problemen ontstaan ​​waarmee ontwikkelaars rekening moeten houden.

1. Identificatie van bronnen ... Bronnen in gedistribueerde systemen bevinden zich op verschillende computers, dus het systeem voor het benoemen van bronnen moet worden bedacht, zodat gebruikers gemakkelijk toegang hebben tot en verwijzen naar de bronnen die ze nodig hebben. Een voorbeeld is het URL-systeem (Uniform Resource Locator), dat de namen van webpagina's definieert.
2. Communicatie... De universele bruikbaarheid van internet en de efficiënte implementatie van TCP/IP-protocollen op internet voor de meeste gedistribueerde systemen zijn voorbeelden van de meest effectieve manier om communicatie tussen computers te organiseren. In sommige gevallen waar speciale prestaties of betrouwbaarheid vereist zijn, is het echter mogelijk om gespecialiseerde tools te gebruiken.
3. Kwaliteit van systeemservice ... Deze parameter geeft prestaties, status en betrouwbaarheid weer. Een aantal factoren is van invloed op de kwaliteit van de dienstverlening: de verdeling van processen, middelen, hardware en het aanpassingsvermogen van het systeem.
4. Software architectuur ... De software-architectuur beschrijft de verdeling van systeemfuncties over de componenten van het systeem, evenals de verdeling van deze componenten over de processors. Als u een systeemservice van hoge kwaliteit wilt behouden, is het kiezen van de juiste architectuur van cruciaal belang.

De uitdaging voor ontwerpers van gedistribueerde systemen is om software en hardware te ontwerpen om alle vereiste kenmerken van een gedistribueerd systeem te bieden. Dit vereist kennis van de voor- en nadelen van verschillende gedistribueerde systeemarchitecturen. Er zijn drie soorten gedistribueerde systeemarchitecturen.

1. Client / server-architectuur ... In dit model kan het systeem worden gezien als een reeks services die door servers aan clients worden geleverd. In dergelijke systemen verschillen de servers en clients aanzienlijk van elkaar.
2. Architectuur met drie niveaus ... In dit model levert de server niet rechtstreeks diensten aan klanten, maar via de business logic server.

Er is meer dan eens gezegd over de eerste twee modellen, laten we dieper ingaan op de derde.

1. Architectuur van gedistribueerde objecten ... In dit geval zijn er geen verschillen tussen servers en clients, en kan het systeem worden gezien als een set van op elkaar inwerkende objecten waarvan de locatie er niet echt toe doet. Er is geen onderscheid tussen de dienstverlener en zijn gebruikers.

Deze architectuur wordt tegenwoordig veel gebruikt en wordt ook wel webservices-architectuur. Een webservice is een applicatie die toegankelijk is via internet en een aantal diensten aanbiedt, waarvan de vorm onafhankelijk is van de provider (aangezien het universele gegevensformaat - XML ​​wordt gebruikt) en het bedieningsplatform. Momenteel zijn er drie verschillende technologieën die het concept van gedistribueerde objectsystemen ondersteunen. Dit zijn EJB-, CORBA- en DCOM-technologieën.

Eerst een paar woorden over wat XML in het algemeen is. XML is een generiek gegevensformaat dat wordt gebruikt om webservices te leveren. Webservices zijn gebaseerd op open standaarden en protocollen: SOAP, UDDI en WSDL.

1. ZEEP ( Het Simple Object Access Protocol, ontwikkeld door het W3C, definieert een formaat voor verzoeken aan webservices. Berichten tussen een webservice en zijn gebruiker worden verpakt in zogenaamde SOAP-enveloppen (ook wel XML-enveloppen genoemd). Het bericht zelf kan ofwel een verzoek bevatten om een ​​actie uit te voeren, ofwel een reactie - het resultaat van deze actie.
2. WSDL (Web Service Description Language).De webservice-interface wordt beschreven in WSDL-documenten (en WSDL is een subset van XML). Voordat een service wordt geïmplementeerd, stelt de ontwikkelaar de beschrijving op in WSDL-taal, specificeert hij het adres van de webservice, ondersteunde protocollen, een lijst met toegestane bewerkingen en verzoek- en antwoordformaten.
3. UDDI (universele beschrijving, ontdekking en integratie) - Internet Web Services-zoekprotocol ( http://www.uddi.org/). Het is een bedrijfsregister waar webserviceproviders services registreren en ontwikkelaars de services vinden die ze in hun applicaties moeten opnemen.

Uit het gesprek lijkt het misschien alsof webservices de beste en onbetwiste oplossing zijn, en de enige vraag is de keuze van ontwikkelingstools. Dat is het echter niet. Er is een alternatief voor webservices, het Semantic Web, waar WWW-maker Tim Berners-Lee het vijf jaar geleden over had.

Als het doel van webservices is om de communicatie tussen applicaties te vergemakkelijken, dan is het Semantic Web ontworpen om een ​​veel complexer probleem op te lossen: metadatamechanismen gebruiken om de efficiëntie van de informatie die op het web te vinden is, te vergroten. Dit kan door de documentgeoriënteerde benadering te verlaten ten gunste van de objectgeoriënteerde.

Bibliografie

1. SomervilleI. Software-engineering.
2. Dranitsa A. Java versus .NET. - "Computer", # 516.
3. Internetbronnen.