A "Network Objects" a GNOME középső neve. Hát így működnek.
A CORBA a "Common Object Request Broker Architecture" rövidítése. Idézet az Open Management Group (OMG, ez a testület tartja karban a CORBA szabványát) Mi az a CORBA? című dokumentumából:
A "Common Object Request Broker Architecture", röviden CORBA, az Object Management Group válasza a ma elérhető, gyorsan szaporodó hardver- és szoftvertermékek közötti interoperabilitás iránt felmerülő igényre. Egyszerűbben megfogalmazva, a CORBA segítségével az alkalmazások kommunikálni tudnak egymással függetlenül attól, hogy hol találhatók helyileg, vagy hogy ki tervezte őket(...)
Az (ORB) az a középső réteg, ami létrehozza a kliens-szerver viszonyokat az objektumok között. Az ORB segítségével a kliens számára teljesen transzparens módon meghívhatja a szerver objektum egy metódusát, annak tudta nélkül, hogy a szerver a kliens gépén vagy a hálózaton van. A hívást az ORB kezeli, az ő felelőssége találni egy olyan objektumot, ami eleget tud tenni a kérésnek, átadni neki a paramétereket, meghívni a metódust, majd visszaadni a kliensnek az eredményt. A kliensnek nem kell törődnie az objektum helyével, a programozási nyelvvel, amiben azt megírták, az operációs renszerrel, amin fut, vagy bármi mással, ami nem része az objektum interfészének. Ezzel a mechanizmussal, az ORB különböző gépeken, heterogén elosztott környezetben futó alkalmazások interoperabilitását teszi lehetővé, és zökkenőmentesen összeköt több különböző objektumból álló rendszert.
A kliens-szerver alkalmazások írása tipikusan az a terület, ahol a programozók vagy a saját elképzelésük szerint, vagy valamilyen elfogadott szabványos protokollt felhasználva valósítják meg a kommunikációt az eszközök között. A protokoll definíciója függ a felhasznált nyelvtől, a hálózati átviteli közegtől és egy tucat más dologtól. Az ORB-ok leegyszerűsítik ezt a folyamatot. Egy ORB felhasználásával, a protokollt az alkalmazás interfészen keresztül, egy egyszer megvalósított nyelv-független specifikáció, az IDL (Interface Description Language), segítségével definiálod. Mitöbb, az ORB-ok flexibilisebbek. Lehetővé teszik, hogy a programozó minden az épülő rendszert alkotó komponens számára a legmegfelelőbb operációs rendszert, futási környezetet, sőt, programozási nyelvet válassza. Ennél fontosabb, hogy az ORB-ok lehetővé teszik a már meglévő komponensek felhasználását. Egy ORB alapú megoldásban, a fejlesztők egyszerűen lemodellezik a saját gyártmányú komponenst, ugyanannak az IDL-nek a segítségével, amivel új objektumokat írnak, utána írnak egy "wrappert", ami fordítja a hívásokat a szabványos felület és a saját interfész között.
OK, elég a rizsából. Itt van Todd magyarázata:
Emlékszel az RPC-re? Tudod, a Remote Procedure Call-okra? A Sun használta ezeket az NFS és a NIS alapjául. A Microsoft a Distributed Computing Environement RPC szabványát használta fel, amikor megalkotta a DCOM-ot.
Szóval, a remote procedure call (távoli eljárás hívás) igazából nagyon egyszerű. Először is valamilyen szabványos módon definiálnod kell az eljárást. Hogy miből áll egy eljárás definíciója? Benne kell legyen az eljárás neve, az argumentumok, amiket elfogad és az eredmények, amiket visszaad. Ezek után megcsinálod a kliens oldalt, ez mondja meg a klienseknek, hogy hogyan adják át az argumentumokat és milyen formában kapják vissza az eredményeket, majd felépíted a szerver oldalt, ami elfogadja az argumentumokat és visszaadja az eredményeket.
Ezzel a modellel egészen komoly rendszereket építhetsz fel. Vedd pl. a szabványos UNIX fájlrendszer interfészét, konvertáld át RPC-vé, és tessék, megkapod az NFS-t. Felhívom a figyelmedet, hogy amíg a ki- és bemenetekkel szabványos formában dobálózunk, addig a kliens ami meghívja az eljárást és a szerver oldal, ami kiszolgálja azt, lehetnek különböző nyelven írva, futhatnak más gépen, más operációs rendszer alatt, vagy más hardveren. Ettől király az RPC.
Azonban, ahogyan az eljárás alapú programozás ideje lejárni látszik (C, Perl) és helyet ad az objektum-orientált programozásnak (Objective C, Java, C++), igazán valami többre van szükséged, mint az RPC eljárásai. Valami olyan kell, ami támogatja az objektumokat: objektumok létrehozását, objektumok adat részeinek elérését, objektumok metódusainak futtatását, objektumok megsemmisítését. Itt lép színre a CORBA: gondolhatsz úgy a CORBA-ra mint a következő generációs RPC-re, amelyet kibővítettek, hogy támogassa az objektum-orientált programozást. RPC-vel a következőt használnád:
void foo(int bar); void baz(){return(-1);}e helyett CORBA-val a következő a felállás:
interface bubba{ void foo(in int bar); void baz() raises (InValidContext); }Mi ebből a tanulság? A CORBA segítségével nyelv- és helyfüggetlenül objektum-orientált interfészeket írhatsz a szoftverkomponensek közé. Egyszerűen tök jó!
Itt meg szeretném határozni a CORBA első pillantásra kicsit furcsa terminológiáját, hogy mindenki érthesse, legalább felületesen, hogy mik is ezek a CORBA komponensek. Tehát itt jönnek a nem egyértelmű CORBA szakkifejezések:
Object Request Broker - (vagy ORB). Az ORB az a középső réteg, ami a kliens és a szerver között csücsül, és lehetővé teszi közöttük az egyszerű kommunikációt. Az ORB igazából egy fogalom, testet ölthet osztott programkönyvtár vagy külső futtatható állomány képében. Az ORB a felelős a kliens és a szerver közötti párbeszéd felépítéséért, lebontásáért, a "marshaling" és az "unmarshaling-ért", és a párbeszéd alatt forgalmazott üzenetek átviteléért.
Object Adaptor - (vagy OA) Az Object Adaptor adja a csatornát, amin keresztül egy objektum szerver (pl. a gnome panel) az Object Request Broker-rel (ORBit) kommunikál.
GIOP/IIOP - CORBA takes all of these object-oriented language-isms and handles carrying them between object-oriented software components (marshaling, transporting, and demarshaling). 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. Az IIOP a GIOP Internetre alkalmazott változata, elméletileg futtathatnád a GIOP-ot más protokoll fölött, mint az IP, akkor valami másnak hívnák. Én nem tudom elképzelni, miért akarna valaki ilyet. 8^) Ha valaha bármilyen más változata a GIOP-nak fontos szerephez jutna, biztos vagyok benne, hogy az ORBit támogatná. (jó analógia, ha az IIOP-ra ugy gondolsz, mint a HTML-re, a GIOP-re meg úgy, mint az SGML-re.)
Valójában a CORBA-nak két része van. Az a rész, amiről már írtam, ami arról szól, hogy hogyan csinálj objektumosított RPC-t, hogyan "marshal"-ozd az argumentumokat, hogyan írjál IDL fájlokat, hogyan működik a GIOP, stb... és a "CORBA Szolgáltatások". A CORBA-ra épülnek bizonyos szolgáltatások, amik megkönnyítik az osztott objektum-orientált programozást.
Valószínűleg ezek közül a "naming service", azaz a névfeloldás, a legfontosabb. Pl. mondjuk, hogy egy helyesírás-ellenőrző szolgáltatásra vágyó program vagy. Egy igazán aranyos dolog, amit megtehetsz (ha elég jó CORBA implementációt használsz) az, hogy szólsz az ORB-nak: "Hé! Helyesírás ellenőrző szolgáltatásra van szükségem. Keress nekem ilyet!". Az ORB ezek után a "naming service"-t hívja segítségül, és megnézi, hogy milyen helyesírást szolgáltató objektumok vannak beregisztrálva. Amikor talált egyet, akkor visszaszól a hívó programnak, hogy "A helyesírás-ellenőrző szolgáltatás a #867-5309 számon található." Erre felhívod a 867-5309-at és csiribí-csiribá, ott a helyesírás-ellenőrző szolgáltatás. Lehet, hogy egy osztott könyvtárat töltött be és küldhetsz egyenes függvényhívásokat, de az is lehet, hogy a mongol nyilvános helyesírás-ellenőrző szolgáltatást használod, amit a Mongol FreeBSD felhasználók csoportja oszt meg az Interneten IIOP-n keresztül. Nem tudod, és leszámítva a kis késleltetést, amit a mongol körút okozhat, nem is érdekel. Király, nem?
A "naming service" lehetővé teszi, hogy az objektumok későbbi használatra beregisztrálják magukat. Vannak más CORBA szolgáltatások is, többek között tranzakció szolgáltatás, biztonsági szolgáltatás, idő szolgáltatás és "viszony szolgáltatás" ami vagy az, amire gondolsz, vagy nem. Az én 1997 márciusi CORBA szolgáltatásokat leíró (CORBAservices) dokumentumomban 14 darab van.
A CORBAservices specifikációjának egy példányát megtalálod az OMG weblapján a http://www.omg.org/corba/csindx.htm címen. Ha úgy érzed, hogy neked ezek közül bármelyiket implementálnod kell, vedd fel a kapcsolatot az ORBit fejlesztőivel, biztosan örülni fognak a segítségednek. (Lásd ORBit)
Az OMG most fejleszti a CORBA 3.0-ás verzióját. Jelenleg a GNOME a 2.2-es CORBA-t használja, fogalmam sincs, hogy mi lesz, ha kijön a 3.0-ás.
Jó kiindulópont Linas Vepstas CORBA oldala a http://linas.org/linux/corba.html oldalon.
Mivel úgy tűnik, sokakat érdekelnek a CORBA és a COM közötti különbségek, megemlítem a következő oldalt is: http://www.research.att.com/~ymwang/papers/HTML/DCOMnCORBA/S.html, "DCOM and CORBA Side by Side, Step by Step, and Layer by Layer".
Végül, a St. Louis-i Washington University TAO projektjéről is ejtsünk pár szót. Az ottani csoport Dr. Douglas Schmidt vezetésével kifejlesztett egy saját ORB-ot, a TAO-t. Sok hasznos információt találhatsz a CORBA-ról az ő weblapjukon is: http://siesta.cs.wustl.edu/~schmidt/corba.html. Ha már úgyis arra jársz, nézd meg az ACE és a TAO lapokat is, mert nagyon jók.
A CORBA adja a GNOME komponens alapú architektúráját. Hasonló szerepet játszik a GNOME-ban mint a COM/DCOM a win32-es rendszerekben.
A kezdetek kezdetén, a GNOME-os fejlesztők az ILU-t szerették volna használni. Az ILU-nak sok előnye volt, például több nyelvet támogatott, de a Xerox hozzáállása miatt nem lehetett felhasználni a GNOME-ban: az ILU nem szabad szoftver, és a GNOME csapatnak nem sikerült a Xerox-ot meggyőzni arról, hogy változtasson a licencelésen. Mivel a GNOME nem használhat nem szabad szoftvert, az ILU-hoz fűződő terveket végleg el kellett vetni.
A GNOME fejlesztők ekkor a MICO-t vették szemügyre. A MICO azért volt vonzó, mert van "Object Adaptor"-a, IIOP kompatíbilis és GPL-es. Hátránya, hogy nem támogat a C++-on kívül más nyelvet és egyszerűen hihetetlen mennyiségű memóriát használ.
Mivel még mindig elégedetlenek voltak, a fejlesztők elhatározták, hogy megvalósítják a saját ORB-jukat, így született az ORBit.
Az ORBit-ot többnyelvűre tervezték, az ILU példája bizonyítja, hogy ez megvalósítható. Jelenleg ugyan csak a C-t támogatja, de ez a jövőben változni fog (De komolyan! Ez még egy nagyon, nagyon új projekt, ezért támogatja csak a C-t). Támogatja még a GIOP/IIOP-ot is, azt az OMG CORBA protokollt, ami lehetővé teszi a különböző ORB-ok kommunikációját.
Végül, az ORBit-ot magas teljesítményűre tervezték. Ez azt jelenti, hogy kevés memóriát használ, és e mellett gyors is. Erre vonatkozóan az ORBit sok ötletet merít a Flick-ből. Elliot Lee, az ORBit projekt szülőatyja elgondolása szerint, a CORBA specifikációk betartása mellett, a CORBA függvényhívás idejét közelíteni lehet a szokványos osztott programkönyvtáras függvényhívás idejéhez, persze amennyiben a CORBA szolgáltatás helyben megtalálható. Hát meglátjuk.
A nagy igazság az, hogy a MICO használhatatlan volt, túl sok memóriát foglalt, csak C++-t támogatott stb. Csak a GNOME ORBit megjelenésével kezdhettük el igazán használni a GNOME-ban a CORBA-t.
(Ez a rész szó szerint Miguel de Icaza-tól származik, a fő-GNOME-ostól.)
A CORBA-t különböző környezetekben fogjuk használni. A Bonobo nevű interfész és programkönyvtár-rutingyűjtemény segítségével egyszerűsödnek és integrálódnak az alkalmazások:
Komponensek: Vannak előre megírt programkönyvtárak/kiszolgálók, amik bármelyik alkalmazás által használható szolgáltatásokat nyújtanak, ilyen a helyesírás-ellenőrzés, a naptár szolgáltatás és más nem grafikus szolgáltatások.
Alkalmazás-beágyazás és helybeni aktiválás: A Bonobo egy interfész-gyűjtemény, ami a jelenleg meghatározás alatt álló alkalmazás-beágyazást és helybeni aktiválást szolgáltatja. A Bonobo interfészek az OLE2 és OpenDoc interfészeket mintázzák.
GNOME-os Alkalmazások mint szolgáltatók: A GNOME-os alkalmazások exportálni fogják CORBA-n keresztül a funkcióikat, így bárki felhasználhatja ezeket. Ez lehetővé teszi a GNOME-os munkafelület szkriptelését, mivel bármilyen CORBA-t használó alkalmazás vagy szkript nyelv meghívhatja a GNOME kiszolgáló metódusait (pl. egy PERL szkript segítségével távolról elindíthatsz egy táblázatkezelőt és rajzolhatsz bele grafikont vagy készíthetsz "sales report"-ot). Vannak akik ezt "Automatizálás"-nak hívják. A COM-tól eltérően a CORBA-s megoldásnál ez teljesen transzparens a szerver írója számára.
Újrafelhasználható kontrollok: A Bonobo interfészek egy másik része az újrafelhasználható kontrollokkal foglalkozik. Ezek hasonlítanak a Sun JavaBeans-hez vagy a Microsoft Active-X-hez.
A Bonobo nem rövidítés. A bonobók a csimpánzok kevésbé mogorva rokonai.