Az Argus programozási nyelv

Elosztott programokkal kapcsolatos fogalmak

Felügyelők

Az Argusban elosztott alkalmazásokat egy vagy több felügyelő segítségével implementálhatunk. A felügyelő absztrakció az adatabsztrakció egy formája, de különbözik a clusterek által támogatott adatabsztrakciótól (utóbbi a CLU része). Általánosan megfogalmazva egy adatabsztrakció műveletek egy halmazából és objektumok egy halmazából áll. A felügyelő példányok objektumok és handlerjeik a műveleteik. A felügyelő absztrakció hasonló a Simula és Smalltalk-80 nyelvekben megtalálható adatabsztrakcióhoz; a felügyelők az osztályokat reprezentáló objektumokhoz hasonlóak.

A felügyelő (guardian) adatobjektumokat tartalmaz, amelyek a beburkolt erőforrás állapotát írják le. Ezek kívülről közvetlenül nem érhetők el, csak belső processzek által. Ha történik egy eljáráshívás, akkor létrejön egy processz, amely az eljárásnak megfelelő tevékenységet végrehatja. A processzeknek egy másik formája is létezik, amelyet háttér processznek nevezünk. Ez nem közvetlenül függ a hívásoktól, tehát nem hívásra generálódik, hanem állandóan végrehajtás alatt áll. Ilyen lehet például a nyomtatási sorból a következő nyomtatandót elővevő és kinyomtató processz (míg a sort feltöltő processz hívásra generálódó típusú lenne).

Egy node egy fizikai helyen található, több processzora is lehet. Egy felügyelő példány egyetlen node-hoz tartozik, de egy node-nak több felügyelője is lehet. A felügyelő egy vagy több erőforráshoz (adatok vagy eszközök) vezérli a hozzáférést. Az erőforrás használatához műveleteket biztosít, ezeket handler-eknek nevezzük. A felügyelő valójában adatobjektumok halmazából, és az adatokat manipuláló folyamatokból áll. Általában több folyamat fut párhuzamosan a felügyelőben: minden handler-hívás kiszolgálásához új folyamat jön létre, explicit módon is hozhatók létre folyamatok, és lehetnek folyamatok, amelyek a felügyelő háttértevékenységét végzik.

A handlereket csak másik guardian hívhatja. Az eljárás hívások megvalósítása egy üzenet alapú kommunikációs mechanizmuson nyugszik. Az argumentumok érték szerint kerülnek átadásra, biztosítva a beburkoltság követelményét. Az üzenet összeállításáról és továbbításáról az Argus implementációja gondoskodik. Így például egy guardian meghívásához nem kell arról információval rendelkeznünk, hogy fizikailag a hívandó mely csomóponton helyezkedik el, tehát nem a mi feladatunk az üzenet útvonalának megállapítása sem. A felügyelő adatobjektumai lokálisak: ezeket egy másik felügyelőben futó folyamat nem érheti el közvetlenül. Ezzel ellentétben a felügyelők globális objektumok: több, különböző felügyelőkben futó folyamat osztozhat ugyanazon a felügyelőn. Az a folyamat, amelynek van egy az adott felügyelőre vonatkozó referenciája, hívhatja a felügyelő handlerjeit, és ezek már elérhetik a felügyelőn belüli adatobjektumokat. A handler-hívások lehetővé teszik a hozzáférést a felügyelő lokális adataihoz, de az adatok kezelését a felügyelő vezérli.

Amikor egy node felmondja a szolgálatot, akkor azt mondjuk, hogy elesett. Az elesés egyetlen "tiszta" hiba, nem hibák komplikált, szövevényes sorozata. A felügyelő túléli node-jának eleséseit (tetszőlegesen nagy valószínűséggel). A felügyelő állapotát stabil és bizonytalan objektumok határozzák meg. Amikor a felügyelő node-ja elesik, az esés idején futó folyamatok és a bizonytalan objektumok elvesznek, de a felügyelő stabil objektumai túlélik az esést. A felügyelő node-jának visszaállítása érdekében egy speciális visszaállító folyamatot futtat, ami a stabil objektumokból előállítja a bizonytalan objektumokat. Mivel a bizonytalan objektumok elveszhetnek, általában csak redundáns adatokat tartalmaznak, a rendszer teljesítményét javítandó (például egy adatbázis indexét). Az alkalmazás perzisztens állapotát a stabil objektumoknak kell leírniuk.

A felügyelőket felügyelő-definíciókkal valósíthatjuk meg. Ezek megadják:

Akciók

Egy Argus alkalmazás elosztott adatait meg lehet osztani párhuzamosan futó folyamatok között. Egy folyamat megpróbálhat megvizsgálni és tetszőleges számú közbülső állapoton keresztül a jelenlegi állapotból új állapotba transzformálni néhány objektumot. A párhuzamos folyamatok közötti interakciók következtében az adatok inkonzisztens állapotba kerülhetnek. Hardver hibák (például nodeok elesése) következhetnek be egy folyamat futása közben, további lehetőséget teremtve arra, hogy az adatok inkonzisztens közbülső állapotban maradjanak. Hogy a konzisztens adatokkal dolgozó alkalmazásokat támogassuk, az Argus megengedi, hogy a folyamatok atomiak legyenek. Az Argus ún. action-öket biztosít a konkurencia és a rendszerösszeomlás problémájának megoldására. Az action-ök ui. rendelkeznek a következő két tulajdonsággal:

Az atomi folyamatot akciónak nevezzük. Az akciók mind sorbarendezhetőség, mind visszaállíthatóság szempontjából atomiak. Sorbarendezhetőségen azt értjük, hogy több konkurens akció együttes hatása ugyanaz, mintha valamilyen szekvenciális sorrendben hajtottuk volna végre őket, annak ellenére, hogy párhuzamosan futnak. A visszaállíthatóság azt jelenti, hogy az akció hatása "mindent vagy semmit:" vagy az akció által végrehajtott összes változtatás megtörténik az adott adaton, vagy semmilyen változtatás nem lesz. Az összes változtatását elvégző akció sikeresen fejeződik be; az ellenkező esetben az akció abortál, a módosított objektumokat előző állapotukba állítjuk vissza.

Nézzük meg, hogyan lehetne ezt a két tulajdonságot megvalósítani! A szerializálhatóság az osztott objektumhoz való hozzáférések szinkronizálásával biztosítható, míg az atomicitáshoz valahogy vissza kell tudnunk állítani egy megelőző állapotot. Ezeket a tevékenységeket az atomi objektumok segítségével oldjuk meg. Ezek ugyanúgy, mint a szokásos objektumok müveleteket biztosítanak állapotuk módisítására, azonban a műveleteikkel szinkronizálják a felhasználó tevékenységeket és biztosítják abortálás esetén az megelőző állapot visszaállítását. Az Argus több beépített atomi objektumot tartalmaz, mint pl. atomi vektor, atomi rekord. Ugyanakkor lehetőséget nyújt felhasználói atomi objektumok létrehozására is (így esetleges nagyobb konkurencia lehetőséget biztosíthatunk, mint az előre meghatározott típusok használata esetén).

A szinkronizáció lock-ok segítségével történik. Minden az atomi objektumra vonatkozó műveletet olvasónak vagy írónak tekintünk. Azon művelet, amely módosítja az objektumot író, s minden más művelet olvasó. Az olvasó műveletnek, hogy végrehajtódhasson egy olvasó-lock-ot kell szereznie az objektumra, s hasonlóan az írónak író-lock-ot. Ezen lock addig vonatkozik az objektumra, amíg az eljárás terminál, vagy hibával abortál (lényeges tehát az, hogy a lock élettartama nem az objektumhoz való hozzáféréstől függ, hanem az eljárás befejeződésétől). Író-lock és olvasó-lock egymást kizárják. Egy objektumra olvasó-lock-ból több is kiadható, azonban író-lock-ból csak egy. Mivel lock csak az eljárás végrehajtása után szabadul fel, ezért az eljárások teljesítik a kétfázisú protokollt, amely azt jelenti, hogy az első unlock (ilyen itt nincs) után újabb lock nem adható ki. A szerializálhatóságot ezek után kétfázisúság biztosítja.

Az atomicitás biztosítása verziók felhasználásával történik. Egy nem lock-olt objektum állapota egy bázis verzióban van eltárolva. Amennyiben egy objektumot megváltoztatunk, akkor nem közvetlenül a bázis verziót írjuk fölül, hanem egy másolat készül róla a memóriába és a változtatásokat ezen fognak végbemenni. Ha az eljárás sikeresen terminált, akkor ezen átmeneti másolat lesz a bázis változat s egy stabil tárolóeszközön kerül tárolásra, amennyiben az objektum stabil volt. Ha az eljárás abortál, akkor a másolatot eldobjuk.

Mielőtt egy akció sikeresen befejeződne, a módosított, stabil objektumok új állapota megbízható tárolóba íródik: olyan tárolóba, amely nagy valószínűséggel túléli az eleséseket. Az Argus kétfázisú protokollt használ sikeres befejeződéskor, ez biztosítja, hogy vagy az akció összes módosítása megtörténik, vagy egyik módosítás sem. Ha egy stabil objektum módosítása után, de még az új állapot stabil tárolóba írása előtt a rendszer elesik, az akció abortálni fog.

Ezen eszközök segítségével az Argusnál a következők történnek egy rendszerösszeomlás esetén (időrendben):

  1. megsemmisülnek az illó objektumok, valamint a processzek
  2. (miután megszűnt a hiba oka) az Argus visszaállítja a guardian kódját
  3. a stabil tárolóeszközről felépíti a stabil objektumot
  4. lefut a guardian által meghatározott visszaállító eljárás (recovery process), amely helyreállítja az illó objektumokat
  5. a guardian eljáráshívás fogadására és processz indításra kész állapotba kerül.

Beágyazott akciók

Az Argusban lehetőség van akciók egymásba ágyazására: egy akció több al-akcióból állhat. Az al-akciók csökkenthetik a hibák hatókörét és lehetővé teszik az akción belüli párhuzamosítást. Egy akció tetszőleges számú al-akciót tartalmazhat, egyesek csak szekvenciálisan, mások párhuzamosan is végrehajthatók. Ez a szerkezet az akción kívülről nem látható; a külső akció még mindig atomi. Az al-akciók az ugyanabban a szülőben szereplő más al-akciókra nézve atomiak. Így az al-akciók egymással párhuzamosan futtathatók.

Az egyes al-akciók egymástól függetlenül fejeződhetnek be sikeresen, illetve abortálhatnak, egy al-akció abortálása nem jelenti feltétlenül szülőjének abortálását. Az al-akció sikeres befejeződése viszont a szülőjétől függ: ha egy al-akció sikeresen fejeződik be, de szülője abortál, akkor ő is abortálni fog.

Egymásba ágyazott akciók fájának gyökerét főakció-nak hívjuk. A főakcióknak nincs szülőjük; ha egyszer már sikeresen befejeződtek, akkor nem abortálnak. Mivel egy al-akció hatását szülője abortálásával vissza lehet vonni, a sikeres befejeződéskor használt kétfázisú protokollt csak főakciók befejeződésekor használjuk.

Egy Argus akció (például egy handler hívás) objektumokat adhat vissza normális visszatéréskor, vagy abortálás előtt egy kivétellel. A sorbarendezhetőség megsértését elkerülendő a következő szabályt kell használni: egy abortáló al-akció nem adhat vissza vele párhuzamosan futó akcióval közös adatterületről származó információt.

Atomi objektumok, atomi típusok

Az akciók atomicitása a köztük megosztott adat objektumok atomiságával biztosított. Az osztott objektumokat úgy kell implementálni, hogy az őket használó akciók atomiak legyenek. Az atomicitást támogató objektumokat atomi objektumoknak nevezzük. Az atomi objektumok biztosítják az akciók atomicitásához szükséges szinkronizációt és visszaállíthatóságot. Atomi típus az a típus, amelynek az objektumai atomiak. Vannak objektumok, amelyeknek nem kell atomiaknak lenniük: például azok az objektumok, amelyek egyetlen folyamat számára lokálisak. Mivel az atomicitáshoz szükséges szinkronizáció és visszaállíthatóság költséges lehet, nem követeljük meg minden típus atomiságát. (Például az Argus tartalmazza a CLU beépített mutable típusait, ezek nem atomiak.) Nem szabad azonban elfelejteni, hogy atomi akciók közös objektuma csak atomi lehet.

Az Argus tartalmaz beépített atomi típusokat és típusgenerátorokat. A beépített skalár típusok (null, node, bool, char, int, real, és string) atomiak. Paraméteres típusok szintén lehetnek atomiak. Egy típusgenerátor példánya általában csak akkor atomi, ha minden aktuális típus-paramétere atomi. A beépített immutable típusgenerátorok (sequence, struct, és oneof) atomiak, ha paraméterük típusa atomi. Ezeken kívül az Argus tartalmaz három mutable atomi típusgenerátort: atomic_array, atomic_record, és atomic_variant. Ezek műveletei majdnem megegyeznek a CLU array, record és variant típusainak műveleteivel. A felhasználó is definiálhatja saját atomi típusait.

A beépített mutable típusgenerátorok megvalósításának alapja egy egyszerű zárolási modell. Kétféle zár létezik: olvasási zár és írási zár. Amikor egy akció egy atomi objektum egy műveletét hívja, az implementáció elhelyez egy megfelelő típusú zárt az adott objektumon: írási zárt, ha a művelet módosít objektumot, olvasási zárt, ha olvassa azt. A beépített típusok megengednek több olvasót egyszerre, de íróból csak egyet. Ha szükséges, akkor az akció vár addig, amíg megkaphatja a megfelelő zárat. Amikor egy objektumra írási zár kerül, a rendszer először készít róla egy másolatot, és akció által hívott műveletek ezt a változatot használják. Ha végül az akció sikeresen befejeződik, ez a változat marad meg, és a régi törlődik. Amikor egy al-akció befejeződik, akkor zárait szülője kapja meg. Ha egy főakció fejeződik be, akkor zárai törlődnek, és az akció hatása más akciók számára is érzékelhető lesz. Ha az akció abortál, akkor zárai, és az objektum új változói törlődnek, a régi változat marad fenn.

Az S al-akció zárolási mechanizmusának szabályai, X objektumon:

Precízebben, egy akció kaphat olvasási zárat egy objektumra, ha az összes akció, amelynek írási zára van az objektumon, a kérvényező akció őse. Egy akció kaphat írási zárat egy objektumra, ha minden akció, amelynek (olvasási vagy írási) zára van az objektumra, egy ős. Ha egy al-akció sikeresen befejeződik, a zárait a szülője örökli, és a befejeződött akció változata az objektumról felülírja szülőjének változatát; ha egy al-akció abortál, akkor zárai, és változatai törlődnek. Mivel az Argus garantálja, hogy szülő akciók sohasem futnak gyermekeikkel, ezek a szabályok biztosítják, hogy egyidejűleg futó akciók sohasem rendelkeznek egyszerre írási zárral ugyanarra az objektumra.

Egy al-akció ősei önmaga, szülője, szülőjének szülője, és így tovább; egy al-akció leszármazottja szülőinek. Egy al-akció valóban befejeződik, ha ő és minden őse, a főakciót is beleértve, sikeresen befejeződik. Egy al-akció egy befejezett leszármazottja egy ősének, ha az al-akció és minden közbülső akció befejeződött. A főakció sikeres befejeződésekor a kétfázisú protokoll használata biztosítja az összes, az akció és befejeződött leszármazottai által módosított objektum új változata a stabil tárolóba kerüljön. Amikor az új változatok bekerültek a stabil tárolóba, a régi változatok törlődnek.

A felhasználó által definiált atomi típusok lehetnek párhuzamosabbak, mint a beépített atomi típusok. Egy felhasználó által definiált atomi típusnak több követelménynek kell eleget tenni. Először is helyes szinkronizációt kell biztosítania, hogy műveleteinek párhuzamos hívásai ne interferáljanak, és a műveleteit hívó akciók sorbarendezhetőek legyenek. Másodszor, visszaállító akciókat kell biztosítania, hogy az abortált akcióknak ne legyen hatása. Végül, biztosítania kell, hogy a valóban befejeződő akciók által az objektumokon végrehajtott változtatások helyesen a stabil tárolóba kerüljenek. A beépített atomi típusok és a mutex típusgenerátor, hasznos segítség a feladatok megoldásához.

Beágyazott főakciók

Al-akciók más akciókba ágyazása mellett néha hasznos lehet, egy akción belül új főakciót kezdeni. Egy ilyen beágyazott főakciónak, az al-akciókkal ellentétben, nincsenek a "szülőjével" kapcsolatos privilégiumai; például nem tudja olvasni a szülője által módosított atomi objektumot. Továbbá befejeződése relatív a szülőjének befejeződéséhez; az ő változata a stabil tárolóba íródik, zárai törlődnek, akárcsak a normál főakciók esetén.

Az Argus minden meghívott guardian eljárást, a hívó al-akciójaként futtat. Így garantáljuk, hogy amennyiben az eljárás sikeresen lefutott és a guardian választ adott, akkor a hívás pontosan egyszer megtörtént, amennyiben pedig az eljárás abortált, akkor garantáljuk, hogy a hívás ténylegesen nem történt meg (olyan, mintha nem történt volna hívás). A subaction alkalmazása által a hívó és hívott guardian külön van választva, amely biztosítja, hogy minden külön eljárás csak egy guardian-en fut. Így nem jöhet létre az az anomália, hogy egy tevékenység egyszerre abortál és terminál két különböző guardian-en. Ezen felül az is fennáll, hogy a hívó és a hívott közvetlenül nem függ a másik állapotától.

Így az Argusban egy számítás elindul, mint egy topaction, vagy egy olyan action, amelynek nincs szülője. A számítás továbbterjed eljáráshívások által más guardian-ekre, ahol azok subaction-ökként fognak végrehajtódni. Amennyiben a topaction terminál, akkor történik az összes változtatás felírása a stabil tárolóeszközökre. Ha ez nem sikerül, akkor a topactiont abortáltnak tekintjük, ellenkező esetben pedig garantált, hogy a számítás helyesen végrehajtódott.

Távoli eljáráshívások

Egy felügyelőben futó akció olyan feladatokat is erdeményezhet, melyet egy másik felügyelőben kell végrehajtani,mégpedi annak kezelőjének hívásával. Egy akciónak lehetősége van másik felügyelő létrehozására,annak konstruktora (creator) meghívásával.A kezelők és konstruktorok meghívását együttesen távoli hívásnak nevezzük.A távoli hívások hasonlóak a lokális hívásokhoz: például a hívó folyamat várakozik a meghívott eljárás visszatérésére.Azonban nagyon sok mindenben különböznek is a távoli hívások a lokálisaktól.

Előszőr is a távoli hívások esetében a paraméterek átadása érték szerint történik(14. section) nem pedig megosztással.Ezzel biztosítjuk azt hogy a felügyelö lokális objektumai lokálisak maradnak akkor is ha értékük paraméter- ként vagy visszatérési értékként kerül átadásra a távoli hívás során másik felügyelő számára.Az egyedüli objektumok melyek megosztással kerülnek átadásra távoli hívások esetén is azok a globális objektumok: a felügyeleők,kezelők, (handlers),konstruktorok(creators) és a node-ok.

Másrészt minden távoli hívásnak lehetősége van a failure és az unavailable kivételek meghívására.(nem úgy mint a CLU-ban ahol csak néhány eljárás hívhatja ezeket:Appendix IV).A failure előfordulása azt jelzi hogy kicsi annak a valószínűsége hogy a hívás valaha is sikerüljön, így nincs lehetőség a jövőben a hívás megismétlésére.Az unavailable viszont azt jelnti,hogy a hívás sikerrel járhat ha újra probáljuk a jövőben de kicsi annak esélye, hogy ha most rögtön probáljuk akkor sikeres lesz. Például a failure akkor forulhat elő ha lehetetlen továbbítani az eredményt, vagy a hívás argumentumait(section 14):unavailable pedig például akkor fordulhat elő, ha a meghívott felügyelő összeomlott, vagy a hálózat megszakadt.

Harmadrészt pedig egy handler vagy egy creator csak akció belsejéből hívható meg,és a hívás úgy viselkedik mint a hívó akció egy al-akciója.Ez biztosítja azt hogy a hívás csak legfeljebb egyszer hajtódik végre: vagy a távoli hívás sikeresen véget ér, és elvégzi amit kell, vagy abortál és ekkor az összes módosítás elvégezetlen marad.Noha a távoli hívás hatása legfeljebb egyszeri,a rendszernek lehet többször is probálkoznia kell vele: ez az amiért a távoli hívások csak akciókon belül hajthatók végre.

Átvihető típusok

A távoli hívások argumentumai és ereményei érték szerint adódnak át.Ez azt je- lenti hogy az argumentum és eredmény objektumokat másolnunk kell, hogy új objektumokat kaphassunk.Azonban nem minden objektum másolható így : azokat melyeket lehet hívjuk átvihető objektumoknak,és ezek típusát pedig átvihető típusnak.Csakis átvihető objektumok használhatóak távoli hívások argumentumaként, illetve értékeként.Ezen felül,az image objektumok csakis átvihető objektumokat tartalmazhatnak.

A paraméterezhető típusok valamely példánya lehet átvihető,egy másik pedig nem az: példaképpen, a beépített típus-generátorok csak abban az esetben átvihetőek,ha a paramétereik is átvihetőek.Míg a konstruktorok,handler-ek, minig átvihetőek,addig az eljárás és iterátor típusok sosem azok.

A felhasználónak lehetősége van új átviehtő típusok kreálására.Minden T átvihető típusra, a T kűlső reprezentációjának definiálva kell lennie: ez írja le,hogy a T mely objektumai lesznek átvihetőek.Minden cluster mely egy átvihető típust definiál,tartalmaznia kell 2 eljárást,az encode illetve a decode nevű eljárást,melyek a T típus objektumait tranzormálják a külső reprenetációból illetve -ba.

Árva akciók

Árva akciónak nevezzük azt az akciót,mely néhány ősét elvesztette,vagy a helyes eredménye egy kapcsolódó akciónak megsemmisült.Árva akciók az Argusban öszze- omlás vagy közvetlen abort hatására jöhetnek létre.Például, ha egy szülő akció abortál,az aktív leszármazotjai, melyeket hátrahagyott, árva akciókká válnak.Összeomlások szintén ezt okozhatják:ha egy felügyelő összeomlik,minden aktív akció melynek öse az osszeomlott felügyelő volt,és minden akció mely az összeomlott felügyelőben kapcsolatban volt,árva akcióvá válik.Mindazonáltal, ha van egy leszármazottunk mely árva akció,nem vonja magaután szükségszerűen, 5hogy az őse is árva akció: ahogy már korábban is leírtuk,az akciók egymástól függetlenül commit-álhatják, vagy abortálhatják az alckióikat.

Az Argus progrmaozóknak nem nagyon kell árva akciókkal foglalkozniuk.Az Argus biztosítja hogy az árva akciók abortáljanak mielőtt ellentmondó adatokat láthatnának.Minden távoli hívást mely valamiért abortált, a rendszer újra pró- bálja,még akkor is ha valamilyen hiba folytán a hívó akció árva akcióvá vált. Az árva akciók minig abortálnak.Vagy avortálhatnak önként,vagy a futtató rendszer kényszeríti erre őket:az az árva akció mely a kritikus szakaszban van, nem kényszeríthető abortálásra a rendszer által,kivéve ha ami összeomlik az egy felügyelő.Másrészt pedig a rendszer bátoríthat egy akciót az abortálásra,mégpedig úgy hogy a távoli hívásukkal az unavailabe signalt hívja.

Holtpontok

Az Argus akcióji holtopnba is juthatnak.Ha például egy A akció várakozik egy zárra melyet a B akció birtokol,és a B pedig egyre melyet az A,akkor A és B holtpontba kerülnek.Az egyes implementációk tartalmazhatnak holtpont felder- ítést illetve annak elkerülését,nem kell hogy tartalmazzák.Ez azért van így mert a holtpontok felderítése nehéz feladat olyan nyelvben, ahol a felhaszná- ló definiálhat atomi típusokat,mivel ilyenkor nem mindig egyértelmű, hogy az egyes akciók hol is várakoznak egymásra.Ha egy implementáció tartlmaz holtpont felismerést,akkor csak a holtpontok megtörésére képes,az akciók abortálásával,illetve a felügyelők összeomlaszásával.

Környezet

Az Argus környezet bítosíja a programok teljes statikus ellenörzését.Lehetövé teszi számunkra a külön-külön való fordíthatóságot,és a felügyelők független- ségét.

A könyvtár

Az Argus moduljai a könyvárak alapján kerülnek fordításra,amely a külső azonsosítokhoz rendel jelentést,és lehetővé teszi a modulokon keresztüli típus ellenőrzést.Az Argus könyvtár a típus információkat tartalmaz az ab- sztrakciókról: minden absztrakcióról a könyvtárban szerepel egy azt leíró egység,másnéven DU (description unit), mely magát az absztrakciót írja le, és annak implementációját.MInden DU-nak egyedi neve van,és ezen nevek teremtik meg az alapját a típus ellenőrzésnek.

A felügyelők képeinek(image) függetlensége

Egy felügyeleő által futatott kód valamely felügyelő képből jön.Egy felügyelő kép minden olyan kódot tartalmaz,amelyek a felügyelő lokális müködéséhez szük- ségesek: minden eljárás,iterátor,vagy cluster melyet a felügyelő használ,mind benne lesznek annak képében.Minden kezelő(handler) hívás melyet a felügyelő hajt végre,a hívptt felügyelőben hajtódik végre,abban amelyik a kódot tartal- mazza.Ezáltal a felügyelők függetlenek azon felügyelőkől melyeket hívnak,és így egy felügyelő implementációját megváltoztathatjuk anélkül, hogy annak klienseire ez hatással lenne.

Felügyelők létrehozása

Amikor egy új felügyelőt hozunk létre,ki kell választanunk azt a képet,amely a kód futtatását fogja biztosítani ezen új felügyelőnek.Ezért minden felügye- lőnek van egy őhozzája rendelt létrehozó környezete,amely specifikálja a ké- peket azon másik felügyelők számára melyek létrehozhatják őt.Egy létrehozási környezet egy összekapcsolása tulajdonképpen a felügyelő tipusnának és azon információnak, amely arra használható, hogy melyik image a megfelelő az egyes node-ok számára.A nagyobb rugalmasság elérése érdekében,ezen információk összeköthetőek különböző konstruktor objektumokkal.

A katalógus

Valamilyen módon a felügyelőknek meg kell találniuk másik felügyelőket is, hogy használhassák azok szolgáltatásait.Egy felügyelőnek általában rendelkez- ésére állnak azon felügyelőkre való hivatkozások, melyeket ő hozott létre. Ha egy felügyelő meg tud hívni valamely szerver felügyelőt,képes arra hogy megtanulja azon felügyelőket is melyeket ezen szerver tud,mivel a fel- ügyelők átadhatók a távoli hívásokban.Ezen felül az Argus egy beépített alrendszert biztosít melyet minden felügyelő ismer.Ezen alrendszer neve kata- lógus.A katalógus egy atomi összekötését bizosítja a neveknek és az átvihető objektumoknak.Például mikor egy új felügyelőt hozunk létre,akkor ezt betehet- jük a katalógusba valamilyen ismert névvel,melyen keresztül őt később másik felügyelők megtalálhatják majd.Mivel még csak kiséretezgetünk különböző in- terfaceekkel a katalógushoz,még nem tudtunk ide betenni egy interface specifikációt.