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.
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.
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.
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.
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.
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.
[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