Jini és Grid rendszerek együttműködése

Póta Szabolcs, Kuntner Krisztián, Juhász Zoltán

Veszprémi Egyetem, Információs Rendszerek Tanszék

{pota, kuntner, juhasz}@irt.vein.hu

Absztrakt Az új generációs Grid technológiák egyre inkább a szolgáltatás-orientált programozás irányába mutatnak. Az iparban lassan de facto szabvánnyá váló Web Services technológia lehetővé teszi földrajzilag elosztott heterogén rendszereken futó Web alapú szolgáltatások együttműködését. Ezt az architektúrát veszi alapul a jelenleg kialakulóban lévő Open Grid Services Architecture (OGSA) szabvány is, amely a Web Service és a hagyományos Grid technológiák ötvözésére törekszik. Egy másik bíztató alternatíva a Jini technológia alkalmazása, amely hatékony eszköz elosztott dinamikus objektum-orientált rendszerek létrehozására. Bár a Jini alapú elosztott rendszerek számos előnnyel rendelkeznek, mégis gyakran éri őket bírálat amiatt, hogy homogén (Java) programozási környezetet feltételeznek, ami nagyméretű Grid rendszerek esetében nem megvalósítható. Cikkünkben rávilágítunk azokra a Jini technológiában rejlő lehetőségekre, amelyek lehetővé teszik a már meglévő Grid rendszerekkel való együttműködést, úgy mint protokoll-függetlenség, nem Java alapú szolgáltatások illetve kliensek Jini rendszerbe való integrálása. Emellett vázoljuk azokat a Jini programozási módszereket, amelyekkel ezek egyszerűen megvalósíthatók.

1. Bevezetés

Manapság egyre közismertebbé válnak a különféle Grid technológiák és az egyes tudományterületeken való alkalmazásaik [1példa1] is rendre bizonyítják, hogy a Grid rendszerek nyújtotta lehetőségek új alternatívákat nyitnak a nagy teljesítményű számítások terén. Ennek megfelelően a hangsúly sem azon van már, hogy feltárjuk a Grid lehetőségeit és előnyeit, hanem azon, hogy egy olyan jól működő implementációt tudjunk létrehozni, amely kielégíti azokat a követelményeket, amelyek alapján egy elosztott rendszert Gridnek nevezhetünk. Ezen követelmények közé tartozik például, hogy a felhasználó valóban egyetlen, jól definiált interfészen keresztül férhessen hozzá ahhoz a hatalmas számítási kapacitáshoz és erőforráshoz, amit a Grid nyújt. A Grid infrastruktúrája szinte teljes mértékben maradjon rejtve, hisz a felhasználó számára csupán a Grid nyújtotta szolgáltatások a lényegesek és nem az, hogy a különféle folyamatok miként zajlanak valójában.

Ez a szolgáltatás-orientált megközelítés ma még nem jellemző a Grid rendszerekre. A valóság azt mutatja, hogy sokszor rendkívül nagy erőfeszítést követel meg egy Grid rendszer kiépítése és üzemeltetése, nem beszélve azokról a bonyodalmakról, amelyek két eltérő Grid infrastruktúra összekapcsolásakor lépnek fel. Ugyanúgy, ahogy az Internet fejlődésének korai szakaszában, a Grid világban is szükség van szabványokra, amelyek lehetővé teszik, hogy az elszigetelt, kisebb-nagyobb Grid szerveződések összekapcsolódhassanak. Ezt a célt tűzte ki a manapság egyre közismertebbé váló Web Services technológia [22], amelyben nagy hangsúlyt kap a szabványos együttműködés, az, hogy a számos különböző programozási nyelven és platformon elkészített webes szolgáltatás egy XML-re épített protokoll (SOAP) segítségével szabadon kommunikálhasson egymással. Bár megoszlanak a vélemények arról, hogy ez a technológia egy az egyben alkalmazható lenne Grid rendszerek megvalósítására [3hivatkozás: OGSA3], mégis jól látszik, hogy a szolgáltatás-orientáltság és az együttműködés a mai Grid kutatások két fő hajtóereje.

A jelen cikkben bemutatott Jini technológia [4] szintén a szolgáltatás központúságra és protokollfüggetlenségre épít, és éppen ennek köszönheti, hogy a mai kor kihívásainak megfelelő Grid rendszerek megvalósításának igen bíztató alternatívája lett. Bár a Jini technológia bizonyítottan rendkívül hatékony eszköz robosztus és dinamikus objektum-orientált elosztott rendszerek építésére, mégsem feltételezhetjük, hogy a rá épülő rendszerek a világban jelenlevő számos más technológiától elszigetelten működhetnek. A továbbiakban körüljárjuk azokat a Jini technológiában rejlő lehetőségeket, amelyek lehetővé teszik más Grid, illetve szolgáltatás-orientált technológiákkal való együttműködést.

2. A proxy programozási paradigma

Egy Jini szolgáltatást mindig az őt helyettesítő (innen az angol elnevezés is) ún. proxy objektumon keresztül tudunk elérni. Mikor egy szolgáltatás belép a Jini közösségbe saját proxy objektumát beregisztrálja egy vagy több Lookup szolgáltatásnál. Ezután a kliens, aki egy szolgáltatást keres, az ismert szolgáltatás interfész alapján a Lookup szolgáltatással kikeresteti a megfelelő szolgáltatást reprezentáló proxy objektumot. A kliens tehát a meghatározott interfésszel rendelkező szolgáltatással a proxyn keresztül tudja felvenni a kapcsolatot, méghozzá úgy, hogy meghívja azt a szolgáltatásmetódust, amelyre szüksége van. A Jini szolgáltatás és kliens kapcsolatát, valamint a proxy objektum vándorlását mutatja az 1. ábra.

Ennek a programozási módszernek köszönhetően a Jini képes arra, hogy a felhasználó elől teljesen mértékben elrejtse a távoli szolgáltatással való kommunikációt, illetve arra, hogy a különböző protokollok segítségével kommunikáló, heterogén szolgáltatásokat egységes Java objektumokkal helyettesítse. Bár ez a fajta protokollfüggetlenség képezi az alapját a más rendszerekkel való együttműködésnek, és mint láttuk ez a megoldás a (Java) kliensek szemszögéből rendkívül elegáns, a rendszertervezők számára azonban még akadnak megválaszolandó kérdések. Először is miként regisztrálja be proxy objektumát egy nem Jini és talán nem is Java nyelven írt szolgáltatás? Továbbá, hogyan tud hozzáférni egy távoli szolgáltatáshoz egy nem Java nyelven íródott kliens, aki például szeretné kihasználni a Jini infrastruktúrát, de maga nem érti a Jini "nyelvet"? Ezeket a kérdéseket tárgyalják a további fejezetek.

3. Nem Jini szolgáltatások integrálása

Miként az előző fejezetben láttuk, ahhoz, hogy egy szolgáltatás bekapcsolódhasson egy Jini közösségbe, ismernie kell az úgynevezett Jini csatlakozási protokollt (join protocol). Ez a protokoll inkább viselkedési, mint adatforgalmi protokoll. Miután a szolgáltatás felfedezte a megfelelő Lookup szolgáltatást, azaz megszerezte annak proxy objektumát, a megfelelő távoli metódushívásokkal (Java Remote Method Invocation, RMI) beregisztrálja saját proxyját. Ezek után a Lookup szolgáltatás meghatározott (rövid) időre elhelyezi a proxyt saját tárában és arra kötelezi a szolgáltatást, hogy ezen idő lejártakor erősítse meg, hogy kéri-e a proxy további tárolását. Ha a szolgáltatás nem válaszol, a Lookup szolgáltatás automatikusan törli a proxy objektumot. Ezt a mechanizmust nevezzük a Jiniben leasing-nek, vagy magyarul bérletkezelésnek, ennek köszönheti egyfajta öngyógyító képességét, hisz a nem működő komponensek egy kis idő elteltével kikerülnek a rendszerből és erről az érdekelt felek távoli események formájában értesítést kapnak.

Tehát mindaddig amíg a szolgáltatás Java nyelven íródott, a megfelelő Jini osztályok felhasználásával a csatlakozási protokoll könnyen követhető. A probléma akkor jelentkezik, ha például a Jini osztályok nem állnak rendelkezésre, mert tegyük fel egy korlátozott Java képességgel rendelkező műszerről van szó, vagy esetleg a szolgáltatás más programozási nyelven íródott. Ahhoz, hogy ezek a szolgáltatások is csatlakozni tudjanak szükségük lesz egy olyan speciális Jini szolgáltatásra, amely elvégzi helyettük a csatlakozási protokoll lépéseit. Nevezzük ezt a szolgáltatást a továbbiakban JoinManager szolgáltatásnak. A 2. ábra már a módosított architektúrát mutatja.

Az egyszerűség kedvéért a továbbiakban feltételezzük, hogy a nem Jini szolgáltatás egy Web vagy CORBA szolgáltatás (a továbbiakban idegen szolgáltatás), de természetesen más szolgáltatások is ugyanúgy helyettesíthetők. A 2. ábrán a nem Jini komponenseket szürkével jelöltük, valamint a Jini közösség határát a szaggatott terület jelzi. Az idegen szolgáltatás kapcsolódási folyamatában talán a legérdekesebb a proxy osztály, illetve objektum generálása. Tudjuk, hogy mindenképpen szükség van egy Java proxy objektumra, hogy az idegen szolgáltatás megjelenhessen a Jini közösségben. A JoinManager feladata csupán annyi lesz, hogy a generált proxy osztályt a megfelelő kezdeti paraméterekkel példányosítsa és onnantól úgy kezelje, mintha az saját proxy objektuma lenne, beregisztrálja és kezelje a bérletét. A proxy osztály generálása Web vagy CORBA szolgáltatások esetén szinte automatikusan elvégezhető, hisz a rendelkezésre álló, programozási nyelv független interfész leíró WSDL vagy CORBA IDL állományokból a megfelelő eszközökkel Java interfész generálható. A proxy osztály ezután egy olyan Java osztály lesz, amely a generált Java interfészt implementálja és az egyes metódushívások alkalmával a megfelelő protokoll segítségével (pl. SOAP, IIOP, TCP/IP) felveszi a kapcsolatot a távoli idegen szolgáltatással. Természetesen a kliens, aki a metódusokat meghívja, az egészből mit sem lát.

A proxy objektum generálásának folyamatánál még egy fontos momentumot nem említettünk, mégpedig azt, hogy mi is az a kezdeti paraméter, amire a proxy osztály példányosításakor szükség van. Ez pedig nem más, mint az idegen szolgáltatásra vonatkozó referencia, aminek segítségével a tetszőleges helyre került proxy képes megtalálni a szolgáltatást. Míg pusztán Jini szolgáltatásokról beszélünk, ez a referencia automatikusan bekerül a proxy objektumba az RMI alrétegnek köszönhetően, ez tartalmazza a távoli szolgáltatás IP címét illetve a port számot, ahol figyel az érkező hívásokra. Idegen szolgáltatások esetében azonban már nem ilyen egyszerű a helyzet, ilyenkor külön meg kell szereznünk a távoli metódushívással vagy más módon elérhető szolgáltatás referenciáját és a JoinManager rendelkezésére kell bocsátani. Ezek a referenciák tipikusan egy Lookup szolgáltatáshoz hasonló tárban, az úgynevezett Registry-ben foglalnak helyet. CORBA esetén ez a referencia az úgynevezett Interoperable Reference (IOR), míg Web szolgáltatások esetén egy URL cím. Ezeket a referenciákat (ami tulajdonképpen egy-egy sztring) használja a proxy, amikor kapcsolatba szeretne lépni a távoli szolgáltatással.

Ezzel tehát sikerült elkészíteni azt a proxy objektumot, amivel az idegen szolgáltatás már meg tud jelenni a Jini közösségben a JoinManager közvetítése segítségével, és a Java kliensek ugyanúgy kommunikálhatnak vele, mintha Jini szolgáltatás lenne.

4. Nem Jini kliensek integrálása

Jelen pillanatban tehát egy közvetítő szolgáltatás és egy megfelelően elkészített proxy objektum segítségével bármilyen szolgáltatást csatlakoztatni tudunk a Jini közösséghez. Ebben a fejezetben azt vizsgáljuk meg, hogy mi történik olyankor, ha a kliens nem képes megszerezni és/vagy értelmezni a proxy objektumot.

Ez a probléma a különféle, hálózati kommunikációra képes kézi eszközök (PDA, mobiltelefon, stb.) gyors elterjedésével hamar középpontba került, ugyanis azok korlátozott kapacitása illetve erőforrása miatt még nem képesek a Jini programok futtatására, ugyanakkor ezen eszközök kizárása a Jini közösségből hatalmas felhasználói tábor elvesztését jelentené. Erre megoldásul

Ennek megoldására szintén egy helyettesítő architektúrát dolgoztak ki, az úgynevezett Surrogate architektúrát [5hivatkozás5]. Ennek lényege, hogy a korlátozott képességű, vagy egyszerűen csak más nyelven íródott kliens helyett egy teljes értékű Jini kliens végzi el a Lookup szolgáltatás felfedezését, illetve a kívánt proxy kikeresését, sőt még a Java metódushívásokat is. Ez a helyettesítő kliens az idegen kliens parancsára végzi a feladatát egy úgynevezett Surrogate Host futtatási környezeten belül. Az idegen kliensnek csupán annyi dolga van, hogy valamilyen előre meghatározott módon felfedezze a futtatási környezetet (pl. UDP broadcast, Bluetooth stb.), majd a szintén előre meghatározott üzenetküldéses protokoll segítségével arra kérje a futtatási környezetet, hogy töltse le a helyettesítő kliensét (akár az eszközről, akár egy URL címről). A futtatási környezet ezután elindítja a helyettesítő klienst, amely aztán felveszi a kapcsolatot az idegen klienssel. A Surrogate architektúra vázlatát a 3. ábra mutatja.

Természetesen felmerülhet a kérdés, hogy például egy CORBA kliens, aki egy CORBA szolgáltatással akarja felvenni a kapcsolatot, miért használja a Jini közösséget. A válasz talán az lehet, hogy mind a kliens, mind a szolgáltatás korábbi fejlesztések eredménye, ám ugyanakkor szeretnék kihasználni a Jini nyújtotta lehetőségeket is, mint a spontán felfedezés, bérletkezelés, távoli események, tranzakció-kezelés. Esetleg egy adott platformra optimalizált kliens előnyt jelenthet a felhasználó számára, de ugyanakkor szeretne a Jini közösséghez is csatlakozni.

5. Összegzés

A cikkben ismertettük annak lehetőségeit, hogy milyen módszerekkel lehet nem Jini szolgáltatásokat vagy klienseket a Jini közösséghez csatlakoztatni. Jól látható, hogy a Jini valóban egy nyitott rendszer és ennek előnye nem csupán abban áll, hogy a már meglévő technológiákkal képes biztosítani az együttműködést, hanem abban is, hogy képes lépést tartani az elkövetkezendő technológiai fejlődéssel, ami hosszú távú életben maradásának elengedhetetlen feltétele. Reményeink szerint a Java nyelv elterjedésével a Jini is egyre nagyobb teret tud majd meghódítani az elosztott és Grid rendszerek világában, és a Jini technológiára épülő Grid megoldások bizonyítottan jól működő megoldások lesznek.

6. Irodalom

[1] Grid Enebling Technologies, Sectoral report from the Grid Enabling Technologies study within the ENACTS project, http://www.enacts.org

[2] World Wide Web Consortium, Web Services Activity, http://www.w3.org/2002/ws

[3] The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. I. Foster, C. Kesselman, J. Nick, S. Tuecke, Open Grid Service Infrastructure WG, Global Grid Forum, June 22, 2002.

[4] Jini Technology Core Platform Specification, http://www.sun.com/jini/specs.

[5] Jini Technology Surrogate Architecture Specification, http://surrogate.jini.org/specs.html