1 / 37

A CORBA

A CORBA. Rudics Attila 541. Bevezetés. Probléma: A nagy számítógépes hálózati rendszerek heterogenitása - különféle architektúrájú számítógépek -különféle operációs rendszerek -változatos rendszeren futó alkalmazások

vesna
Download Presentation

A CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A CORBA Rudics Attila 541

  2. Bevezetés Probléma: A nagy számítógépes hálózati rendszerek heterogenitása -különféle architektúrájú számítógépek -különféle operációs rendszerek -változatos rendszeren futó alkalmazások A megoldás:Az elosztott rendszerek különféle komponensei működésének összehangolására, összekapcsolására

  3. Elosztott objektum-orientált rendszerek (Distributed Object Computig) és alkalmazások: Okai: -Az alkalmazás által használt adatok elosztottak: (az adatok több számítógépen léteznek , távolról hozzáférünk az adatokhoz,helyi tárolás nem megengedett) -A feldolgozáselosztott (kihasználása a többprocesszoros paralel feldolgozásnak és a különböző rendszerek által nyújtott egyedi jellemzők előnyeinek ) -Az alkalmazás felhasználói elosztottak(Minden egyes felhasználó az alkalmazásnak csak egy kis részét futtatja a saját számítógépén )

  4. Lokális Elosztott Kommunikáció Gyors Lassú Hibalehetőség Összes objektum egyszerre Hálózat által szétválasztott objektumok külön Konkurens hozzáférés Csak többszálúság segítségével Biztosított Biztonságos Igen Nem Az elosztott rendszerek jellemzői

  5. Kezdet, elsô probálkozások. Az RPC (RemoteProcedure Call) vagy távoli eljáráshívás -Kliens – Szerver kapcsolat lebonyolitása , ezek: * lehetnek különbözõ nyelven írva * futhatnak más gépen *futhatnak más operációs rendszer alatt *futhatnak más hardveren Nagy hátránya, hogy nem támogatja az objektum-orientált programozást

  6. OMG A probléma megoldására megalakult az Object Management Group (OMG) -> kidolgozza a heterogén elosztott objektum-orientált rendszerekkel kapcsolatos alapvető fontosságú szabványokat. - legfontosabb szabványosítási területe az OMA (Object Management Architecture) objektumkezelési architektúra -OMG válasza a ma elérhetõ, gyorsan szaporodó hardver- és szoftvertermékek közötti interoperabilitás iránt felmerülõ igényre a CORBA (Common Object Request Broker Architecture )

  7. Corba Definíciók: -A CORBA (Common Object Request Broker Architekture) egy fejlesztési metodológia az elosztott távközlési szoftverek fejlesztéséhez. -A CORBA szabvány definiál egy olyan kommunikációs mechanizmust, amely lehetővé teszi hálózaton elosztott objektumoknak egymás metódusainak hívását, egymás szolgáltatásainak igénybevételét.

  8. A CORBA jellemzői: -platformfüggetlen -gyártófüggetlen: *Nyílt szabvány *OMG tesztjein, megkaphatják a szabványnak-megfelelõ (CORBA-conformant) tanusítványt -nyelvfüggetlen -helyfüggetlen

  9. CORBA alapfogalmak * A CORBA objektum egy olyan absztrakt entítás, amely képes a kliensektõl érkezõ kérések megválaszolására. Minden CORBA objektumnak vagy egy jól definiált felülete (interface). * A kliens egy program amely kéréseket intéz egy CORBA objektumhoz. Maga a kliens fogalom relatív, mert tud szerverként is viselkedni. * A szerver egy program amely megvalósít egy vagy több CORBA objektumot. Az objektum életciklusa független az õt megvalósító szerver életciklusától -> perzisztens objektumok használatára.

  10. CORBA alapfogalmak * Egy kérés (request) : egy CORBA objektum egy mûveletének a meghívása. * Az objektum referencia egy CORBA objektumot azonosít a kliens számára. A referencia átlátszó (opaque), azaz a kliens semmi mást nem tud tenni vele, mint felhasználni egy kérés elküldéséhez. * A servant (TODO) egy olyan entitás a szerver programban, amely egy vagy több CORBA objektum valósít meg (incarnate).

  11. A Corba Komponensei: - ORB (Object Request Broker) az a középsõ réteg, ami a kliens és a szerver között lehetõvé teszi az egyszerû kommunikációt. - OMG IDL(Interface Definition Language) interfészleíró nyelv • Az OMG IDL interfészleíró nyelvnek más programozási nyelvekre történő leképezése - Kliens- és szervercsonkok szerkezete (mind a dinamikus, mind a statikus metódushívási modellben) - DII (Dinamic Invocation Interface)Dinamikus metódushívási interfész. - SII : Statikus metódushívási interfész. - DSI (Dinamic Skeletron Interface) Dinamikus szerveroldali-csonk interfész.

  12. A Corba Komponensei: - IR(Interface repository) Interfészgyűjtemény Run-time adatbázis a szerver oldali objektumok IDL definícióját tartalmazza - Implementation repository Implementációgyűjtemény A szerver oldali implementációk tárolása. - OA (Object Adaptor ) Objektumadapterek:megadja a csatornát, amin keresztül egy objektum szerver az Object Request Broker-rel (ORB) kommunikál. - BOA(Basic Object Adaptor):Alapvető szolgáltatásokat nyújtó objektumadapter. - ORB szoftverek együttműködési protokolljai .Ha a két szoftverkomponens két külön helyen van, akkor az adatátvitel a GIOP protokol segítségével valósul meg(ESIOP DCE-alapú). Az IIOP a GIOP Internetre alkalmazott változata, ez TCP/IP-alapú.

  13. A Corba Komponensei:

  14. A Corba Komponensei:

  15. Az ORB(Object Request Broker) -elosztott szolgáltatás -eljuttatja a kérést a távoli objektumhoz -megkeresi a távoli objektumot a hálózaton -továbbítja a kérést az objektumhoz -megvárja az eredményeket, és azt visszaküldi a kliensnek.

  16. Az ORB(Object Request Broker) -egy programozás nyelvtől független megvalósítást biztosít a kérések számára -a feladatát a legtranszparensebb módon végzi : -kliens elől eltakarja az célobjektum elhelyezkedését és implementációját. -A metódushívást végrehajtó kliensnek nem kell tudnia az elérni kívánt objektum állapotáról(aktív vagy éppen perzisztens) -A kliens nem ismeri az ORB által a metódushívás közvetítésére használt módszereket. -az egyazon folyamaton belüli, és azonos programozási nyelven implementált objektumok metódusainak hívása helyi metódushívási mechanizmusaival történik.

  17. Az ORB(Object Request Broker) -a különböző folyamatok közötti metódushívás általában a TCP/IP protokollcsalád valamely transzportprotokolljával történik -Az ORB feladata a távoli(és helyi) objektumreferenciák kezelése -egyedi objektumazonosítót (IOR) hoz létre egy CORBA objektum létrehozásakor -Az alkalmazások ezeket az objektumazonosítókat adják tovább más alkalmazásoknak

  18. Az IDL(Interface Definition Language ) -Az objektumok által biztosított szolgáltatások az interfészük révén van megadva, és ezek az interfészek az OMG által meghatározott IDL-n vannak leírva -az interfész-ek tartalmazzák az objektumok metódusainak és adattagjainak a specifikációját valamint egyes elemek típusára vonatkozó információkat Pl. // Hello.idlinterface Hello{void say_hello();};

  19. Az IDL(Interface Definition Language ) -deklaratív nyelv-> nem alkalmas számításokra -csakis a kommunikációs felületek definiálhatóak benne -programozási nyelvektől független -heterogén számítógépes környezetekben kedvező. -nyelvi leképezések használata,létezése(Java ,C++) -az IDL definícióka fileokban tárolodnak

  20. Az IDL főbb elemei Interfészek -definiálják az objektumok távolról hívható metódusait, attribútumait -implementáció nincs!! -tuljadonképpen mûveleti szignatúrák gyûjteménye -Az OMG IDL lehetőséget nyújt interfészek közötti öröklési relációk leírására is,támogatja a többszörös öröklődést -egyenértékûek más IDL típusokkal

  21. Az IDL főbb elemei Modulok -az IDL névtartomány hierarchikus kiterjesztésének támogatása miatt fontos. -egy adott nevű modulban definiált azonosítókra más modulokból a modul nevével minősítve hivatkozhatunk Konstansok -állandó értékeket rögzíthetünk az IDL specifikációs fájlban. Adattípusok -specifikálják az interfészekben levő metódusok paramétereinek típusát, visszatérési értékük típusát, illetve az általuk kiváltható kivételek jellemzőit.

  22. Az IDL főbb elemei Műveletek -definiálják az egyes IDL interfészelemek egy-egy etódusát,szignatúráját (mi az illető metódus neve, milyen típusú paraméterei vannak, milyen a visszatérési értéke, milyen kivételeket vált ki.) - Az egyes műveletek paramétereihez definiálva van az illető paraméterek átadási módja is.Ezek lehetnek: -Klienstől a szerver felé történő paraméterátadás. (in) -Szervertől a kliens felé történő paraméterátadás. (out) -Mindkét irány egyszerre (a híváskor a klienstől a szerver felé, majd visszatér éskor a szervertől a kliens felé). (Inout)

  23. Az IDL más elemei: Beépített típusok(short,long,unsigned short, unsigned long,float, double,char,octet(1b),string és boolean Elnevezett típusok (Typedef) Felsorolási típusok (Enum) Direkt szorzat típusok (struktúrák) (Struct) Unió típusok (Union)-Ezeknek diszkriminátora van Tömb típusok (Vector,Matrix) Szekvencia típusok(Sequence) Attributumok - a CORBA objektum állapotának egy része melyet az interfészen keresztül lekérdezni/módosítani lehet

  24. Az IDL más elemei: Öröklődés -Az interfészek örökölhetnek egymástól -lehetőségünk van olyan IDL műveleteket definiálni, melyek bármilyen típusú interfésszel működnek(Object) -A NIL létezése Az Any típus -bármely más IDL típus értékét képes tárolni -típusinformációt is magában hordoz -a nyelvi leképezés határozza meg ,hogy egy any értékét hogyan lehet beállítani és kiolvasni

  25. IDL leképezése programozási nyelvekre -szükség van a specifikációs és az implementációs eszköz közötti kapcsolat megteremtésére -a kapcsolatot az IDL nyelvnek a különféle programozási nyelvekre történő leképezését tartalmazó szabványok teremtik meg -Szabványositások: -adattípusainak a leképezését az illető programozási nyelv szabványosított adattípusaira -A kliens- és a szervercsonkok szerkezetét. -CORBA objektumok implementációjának számos más részletét

  26. CORBA sematikus Müködése -az interfészt az IDL fordító dolgozza fel, és létrehozza az adott interfésznek megfelelő stub és skeleton osztályokat -a stub objektum pontosan az IDL-ben megadott interfészt valósítja meg; ez tekinthető a távoli szerver objektum lokális helyettesítő példányának ;ezzel fog kommunikálni a kliens -a skeleton mentesíti a szerver objektumot a CORBA-specifikus részletek ismerete alól ; tartalmazza mindazt a funkcionalitást, amely a hálózaton keresztül (az ORB közvetítésével) érkező kérések vételével, a paraméterek deszerializálásával, valamint az eredmény szerializálásával és elküldésével kapcsolatos

  27. CORBA sematikus Müködése

  28. Az Interface Repository(IR) Interfészgyüjtemény -futás idejü hozzáférés az interfészgyüjteményhez -az IDL definiciok formáját tartalmazza:objektumok, metodusok leirását, paramétereit -Az IR-t általában egy, a CORBA szoftverhez adott szerverprogram valósítja meg -az ORB ennek az adatbázisnak a segítségével tudhatja meg azt, hogy a meghívott metódus milyen típusú paramétereket vár -a tárolt adatok futás közben kicserélhetők, törölhetők

  29. Az implementációgyűjtemény -a rendszerben levő CORBA objektumokról tartalmaz információkat (például azt, hogy az illető objektumok hogyan érhetők el, hol vannak tárolva, illetve hogyan lehet őket aktivizálni, ha valamikor szükség lesz rájuk). -minden elkészült CORBA objektumimplementáció jellemzőit bejegyzik ebbe az implementációgyűjteménybe -a CORBA objektumok klienseit, nem kell az implementációgyűjteménybe bejegyezni, csak ha maguk nem definiálnak új CORBA objektumokat szerver feladatokat is ellátva.

  30. DII és a DSI -akkor használjuk ha fordítási időben nem ismerjük a használni kívánt CORBA objektumok felületét -A DII(Dynamic Invocation Interface –Dinamikus hivásí felület) használatához meg kell adnunk a célobjektumot, a meghívni kívánt művelet nevét, a paraméterek típusát és értékét, valamint a művelet által kiváltható kívételek típusát;ezeket az adatokat vagy az Interface Repository-ból szerezhetjük meg, vagy bekérhetjük a felhasználótól stb. Miután megadtuk az adatokat, utasítjuk az ORB-t a kérés elküldésére, a válasz megérkezte után pedig feldolgozhatjuk az eredményt. -a paramétereket és a visszatérési értéket is any típusként kell kezelni

  31. DII és a DSI -A DII-nek szerver oldali párja, a DSI (Dynamic Skeleton Interface). A DSI úgy mûködik, hogy a programozó megadhat egy speciális függvényt, a DIR-t (Dynamic Implementation Routine), melyet az ORB meghív, ha az adott objektumhoz kérés érkezik. A DIR megkapja a mûvelet nevét és általános formában a paramétereket. Feladata a mûvelet eredményének és az kimenõ paraméterek értékének kiszámítása. A DII-t és a DSI-t azért fontos, mert sok olyan szoftver, amely a CORBA-t illeszti egy adott programozási nyelvhez, ezt a két szolgáltatást használja az illesztés megvalósításához.

  32. OA - objektumadapterek -a szerverobjektumok az objektumadapteren keresztül tartják a kapcsolatot az ORB-vel -a szerveroldali alkalmazások elérhetik az ORB szolgáltatásait -a BOA adapter(Basic Object Adapter) *Objektumreferenciák generálása és értelmezése *Objektumimplementációk bejegyzése az implementációgyűjteménybe *Objektumimplementációk aktiválása és deaktiválása -BOA adapteren kívül léteznek egyéb objektumadapterek is

  33. OA - objektumadapterek -egy implementáció aktiválása -egy objektum aktiválása -BOA objektumadapterek négy alapvető implementáció, illetve objektumaktiválási módot támogatnak : *Több objektumnak közös szerver alapú stratégia *Objektumonkénti önálló szerver alapú stratégia *Metódushívásonkénti önálló szerver alapú stratégia *Perzisztens szerver alapú stratégia

  34. A CORBA objektumok ősosztálya -CORBA::Object -interface Object { ImplementationDef get_implementation(); InterfaceDef get_interface(); boolean is_nil(); Object duplicate(); void release(); boolean isá(in string a_típus_logikaiázonosítója); boolean nonéxistent(); boolean iséquivalent(in Object másikóbjektum_referenciája); unsigned long hash(in unsigned long maximum); Status create_request(in Context ctx, in Identifier művelet, in NVList paraméterlista, inout NamedValue visszatérésiíerték, out Request kérés, in Flags kérés_jellemzők); }

  35. ORB szoftverek együttműködésének megszervezése -Az elején nem volt szabvány -> sok baj -A CORBA szabvány 2.0 változatától kezdődően definiáltak két ORB együttműködési protokollt: - az általános együttműködési protokollt(GIOP) -a DCE alapú együttműködési protokollt(DCE/ESIOP ) -Az ORB implementációk általában a GIOP(General Interoperability Protocol ) protokollnak a TCP/IP összeköttetés-alapú transzport protokoll feletti implementációját támogatják, az ún. IIOP protokollt (ez az Internet-alapú ORB együttműködési protokoll)

  36. A CORBA szolgáltatások -Az alkalmazásfejlesztés megkönnyítésére az OMG definiált néhány szolgáltatást (CORBAServices), melyeket a CORBA-t használó programok igénybe vehetnek. Ezeknek a szolgáltatásoknak a felülete OMG IDL-ben van megadva. -A fontosabb szolgáltatások a következõk: Naming Service - Ennek segítségével a CORBA objektumoknak nevet adhatunk, és név szerint kereshetünk köztük. (Telefonkönyv) Trader Service - A Naming Service általánosítása. Az objektumokhoz tulajdonságokat rendelhetünk, és ez alapján kereshetünk köztük. (Yellow Pages) Event Service - Osztott rendszerünket eseményvezérelten mûködtethetjük. Transaction Service - Osztott tranzakciókat hozhatunk létre segítségével. Lifecycle Service - CORBA Objektumainkat perzisztenssé tehetjük

More Related