Diplomaterv. Horváth Ádám Gábor. Ráth István, doktorandusz

Átírás

1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Fejlesztőeszközök integrációja Eclipse környezetben Diplomaterv Horváth Ádám Gábor Konzulens: Ráth István, doktorandusz 2009.

2 Szeretnék köszönetet mondani konzulensemnek, Ráth Istvánnak állandó segítségéért, ötleteiért és észrevételeiért. Köszönet illeti Jósvai Esztert a munkaszervezéssel kapcsolatos tanácsaiért, és Schmidt Andrást, aki segített az ideális munkakörülmények megteremtésében.

3 Nyilatkozat Alulírott Horváth Ádám Gábor, a Budapesti Műszaki és Gazdaságtudományi Egyetem műszaki informatika szakos hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Horváth Ádám Gábor

4 Kivonat Szoftverfejlesztés során sokféle, specifikus eszközt használunk, melyek a munkát könnyebbé teszik. Az igénybe vett eszközök több szempontból is heterogének, más-más a felhasználói felületük, különböző adatformátumokat használnak, sőt elképzelhető hogy az eszköz nem is a saját gépünkön fut, csak távolról szeretnénk igénybe venni a szolgáltatásait. Ennek diverzitásnak a leküzdése, a fejlesztői kontextusváltások számának redukálása hatékonyabbá teheti a fejlesztést, vagyis egy-egy fejlesztési projektben kulcskérdéssé válhat. Az eszközökre az Eclipse fejlesztői környezet komponenseiként is tekinthetünk. Egy vállalati infrastruktúrán egy-egy Eclipse példány fut minden fejlesztői gépen. Ebben az esetben az eszközök különbségeinek leküzdése jelentheti azt is, hogy ezen gépek fejlesztői környezetének szolgáltatásait szeretnénk egységesen elérni egy központi, vezérlő gépről. A szolgáltatásokhoz való egységes hozzáférésnek köszönhetően így lehetővé válhat fejlesztési folyamatok végrehajtása. A szoftverfejlesztés folyamat-alapú megközelítése nem új keletű, hiszen számos módszertant (Rational Unified Process, Extreme Programming) ismerünk fejlesztési folyamatok levezénylésére. Ezek végrehajtásának támogatására azonban csak mostanában jelennek meg technológiák (például az IBM Jazz Platform). A SENSORIA (Software Engineering fot Service-Oriented Overlay Computers) Európai Uniós FP6 kutatási projektben egy olyan keretrendszert alkottunk meg, amely lehetővé teszi lokális és munkámnak köszönhetően távoli Eclipse környezetben elérhető eszközök egységes programozói felületen történő elérését. Ehhez a keretrendszerhez a JBoss jbpm munkafolyamat-végrehajtó motort illesztettem, melynek segítségével lehetőségünk nyílik az eszközök felett magasszintű folyamatok definiálására, így akár fejlesztési folyamatok végrehajtása is elérhető közelségbe kerül. A diplomatervben a folyamatvezérelt eszközintegrációs keretrendszer architektúráját és a megvalósítás során általam elkészített részeket mutatom be. A diplomatervben mintapéldául szolgál a DIANA (Distributed, Equipment Independent Environment for Distributed Avionic Applications) Európai Uniós projektben elkészített szoftverfejlesztési folyamat, melynek keretrendszerben történő megvalósítását szintén részletesen bemutatom. 4

5 Abstract During software development, a number of specific tools are used, which make development easier. Tools are heterogeneus in a number of aspects: they have all kinds of user interfaces, use different data representations, and might not even run on one s own machine, thus one only wants to access their services remotely. Dealing with this kind of diversity, and reducing the number of developer context switches can help make development more efficient, thus becoming a key aspect of software development projects. Specifically, development tools can be thought of as different components of the Eclipse integrated development environment. In a distributed enterprise infrastructure, there might be several Eclipse instances running on different developer machines. In this case, overcoming differences of tools could mean making the services of these development environments accessible from a single, supervisor machine. By having uniform access to these services, the execution of a software development process on this infrastructure might be possible. The process-oriented view of software development is not a new approach, since a number of methodologies (Rational Unified Process, Extreme Programming) exist for conducting software development processes. Technologies like IBM Jazz which support the execution of such a processes have only recently started to emerge. In the SENSORIA (Software Engineering fot Service-Oriented Overlay Computers) European Union FP6 Research Project, we have developed a framework, that can provide uniform programmatic access to local and with my contributions remote tools accessible from the Eclipse environment. I connected the JBoss jbpm worklfow execution engine to this framework, thus making it possible to define high level processes that invoke the integrated tools, which makes the execution of software development processes also possible. In my master s thesis, I present the architecture of the process-driven tool integration framework as well as my contributions to its implementation. In a case study, I also present a software development process developed in the DIANA European Union Research Project and its realization using the tool integration framework. 5

6 Tartalomjegyzék 1. Bevezető 9 2. Motivációs esettanulmány: a DIANA fejlesztési folyamat Az MDA (Model Driven Architecture) ismertetése Demonstrációs példa: a modellvezérelt DIANA fejlesztői környezet Az összerendelési folyamat lépéseinek ismertetése Modellek importálása (Import PIM and Platform Description) Adattípusok megfeleltetése (Data Type Mapping) Típus kódolások megválasztása (Encoding Mapping) Kommunikációs interfész megválasztása (Interface Type Mapping) Alkalmazás típusának kiválasztása (Application Type Mapping) Modulok közötti üzenetek összerendelése (Inter-Module Message Mapping) Partíciók definiálása (Partition creation) A rendszer állapotleíró táblázaténak elkészítése (System HM Table Creation) Használt AIDA szolgáltatások kijelölése (Service Inclusion) Kompatibilis partíciók kijelölése Alkalmazások elhelyezésének megállapítása (Application Allocation) Kommunikációs csatornák megállapítása (Communication Channel Allocation) Eszközintegráció megjelenése a példában A példa tanulságai A workflow-alapú eszközintegrációs rendszer Bevezetés: state of the art eszközintegráció ismertetése OLE Automation Web szolgáltatások és a BPEL A SENSORIA Development Environment keretrendszer Az IBM Jazz Platform

7 Összegzés Az eszközintegrációs keretrendszer modellje Az eszközintegráció értelmezése a diplomatervben Felhasznált technológiák A SENSORIA Development Environment, mint eszközintegrációs platform Az Eclipse integrált fejlesztőkörnyezet A SENSORIA keretrendszer részletes leírása Az IBM Jazz Platform Bevezető Architektúra A Jazz Platform alapvető komponensei A Repository komponens használata A Jazz Repository hasznosítása dokumentumkezelőként Implementációs eredmények A rendszer kiegészítéseinek ismertetése A SENSORIA rendszer hiányosságai Távoli elérés (remoting) előkészületek A munkafolyamat-végrehajtó környezet kiválasztása Áttekintés: a bővített rendszer felépítése Remoting implementáció Előkészületek Az R-OSGi ismertetése Az R-OSGi felhasználása az implementációban Összefoglalás Munkafolyamat-végrehajtó rendszer illesztése a SENSORIA rendszerhez A jpdl nyelv sajátosságai A jpdl csomóponttíupsok Folyamatok definiálása jpdl nyelven A jpdl nyelv és a SENSORIA keretrendszer összekapcsolása A DIANA szoftverfejlesztési folyamat átültetése a bővített keretrendszerbe A DIANA folyamat végrehajtásához szükséges csatolók A DIANA szerkesztő csatolása a keretrendszerhez A DIANA folyamat jpdl reprezentációja

8 6.4. A DIANA folyamat jpdl leírásának végrehajtása Távoli eljáráshívás, dokumentumkezelés a folyamatban A tárolási (storage) modell kialakítása Jazz szolgáltatások a tárolási modell tartalmának elérésére A tároló szolgáltatásainak felhasználása a DIANA folyamatban Összefoglalás Eredmények A példa tanulságai, kitekintés A Jazz alapú dokumentumkezelő bővítési lehetőségei A jpdl nyelv domain-specifikus kiterjesztése Elosztott eszközintegráció a folyamat modellben További modellezési nyelvek használata

9 1. fejezet Bevezető Napjaink szoftverfejlesztési folyamatainak, különösen a komplex üzleti szoftverek esetén, általános jellemzője a sokféle, összetett tevékenység. Ezeket több, különböző eszközzel végzik, amelyek általában egy specifikus területre (modellezés, modell-ellenőrzés, kód generálás, tesztelés) fókuszálnak. A fejlesztői programok gyakran igen bonyolultak, felhasználói felületük nem egységes, és a munkafázisok közötti váltás sokkal időigényesebb, mintha egy egységes rendszerbe integrálva használnánk az eszközeinket. Egy további, ma már általános elvárás, hogy a fejlesztési munkát egy jól definiált, követhető, ellenőrizhető módszertan alapján szervezetten végezzük. A fentiek alapján elmondhatjuk, hogy a szoftverfejlesztés mára olyan összetett tevékenységgé vált, mint a műszaki tudomány számtalan területén megjelenő gyártási folyamatok. Ez a gyártási tevékenység a vállalati infrastruktúrán történik, amely jellemzően igen heterogén, mind a szoftver, mind a hardver konfigurációk tekintetében. A ma gyakorlatának fontos, központi jelentőségű problémája ezen sokféleség összehangolt, hatékony működtetése. Ennek eléréséhez több probléma megoldása szükséges. Egyrészt meg kell oldani az egyes folyamatokban szereplő résztvevők és eszközeik közötti adatáramlást (adatintegrációt), amely még ma is komoly kihívást jelent a sokféle szoftverből álló eszközpaletta miatt. Másrészt biztosítani kell, hogy a fejlesztési folyamat precízen tervezhető legyen, és azt is, hogy a tényleges végrehajtás minél pontosabban kövesse ezt a tervet. Az üzleti informatika világában népszerű megoldás a folyamat modellezés alapú munkaszervezés (business process modeling). A technika lényege, hogy a vállalat üzleti tevékenységét magas szintű modellekkel írjuk le, melyek érthetőek az üzleti döntéshozók számára is, így a tevékenység irányítása ideális esetben a legmegfelelőbb kezekbe kerülhet. Azonban egy modell csak annyit ér, amennyit végre is hajtanak belőle, azaz ez a módszer akkor válik hatékonnyá, ha biztosítani tudjuk, hogy a valódi szereplők kövessék a modell által előírtakat. A ma népszerű üzleti szoftverek kínálnak ilyen megoldásokat, azonban egy ilyen rendszer bevezetése drága, nem utolsósorban amiatt, hogy gyakran a vállalat 9

10 szoftvereinek költséges adaptációját igényli. Mégis, a tapasztalatok szerint megéri a befektetés, hiszen ezek a rendszerek mára már széles körben elterjedtek. A szoftverfejlesztésben ez a megközelítés mindmáig csak igen korlátozott mértékben jelent meg. Manapság jelennek meg azok a kollaborációs keretrendszerek (pl. IBM Jazz), amelyek igyekeznek meríteni az üzleti folyamat modellezés tapasztalataiból a fejlesztők munkájának koordinációját segítő szolgáltatások kialakításakor. Diplomatervem legfontosabb célja az, hogy ezt az ötletet kidolgozva bemutassak egy olyan rendszert, amely képes a fejlesztők munkájának hatékony összehangolására, a workflow modellezés technikájának alapjain. Az általam kidolgozott rendszer a SENSORIA Európai Uniós FP6 kutatási programban kidolgozott, elsősorban Eclipse alapú fejlesztőeszközök integrációját célzó keretrendszerre épít. A mai szolgáltatásintegrációs technológiák ilyen térű alkalmazásának két fő problémája a következő: integrációs nehézségek fontos probléma a különféle szolgáltatások integrált, a fejlesztői környezetből könnyen elérhető használata. Ez azt jelenti, hogy a sokféle fejlesztőeszköz, még akkor is, ha egy egységes integrált fejlesztőkörnyezetben működik (pl. Eclipse alapú eszközök), integrációs problémát jelent a sokféle adatformátum, és a gyakran hiányzó, az alapfunkciókat egy egységes felületen elérhetővé tevő programozói interfészek miatt. kommunikációs nehézségek amennyiben az eszközintegráció fogalmát kiterjesztjük az egyszerű felhasználó munkaállomásán túlmutató, elosztott vállalati infrastruktúrára, gyakori problémába ütközünk: biztosítani kell az egyes szolgáltatások hálózaton keresztüli elérését. Ehhez általában, az előző pontban említett interfész megvalósításán túl szükséges egy megfelelő hálózati csatoló kifejlesztése is, amely a modern, könnyen használható technológiák (pl. Web Services) ellenére is gyakran drága, egyedi megoldást igényel. A SENSORIA projektben egy modern, szolgáltatás-orientált elvű integrációs környezetet fejlesztettünk ki, amely egyrészt lehetőséget biztosít az egyes eszközök alapvető funkcióinak egy egységes programozói felületen történő megjelenítésére, valamint kifejlesztettem ennek kiterjesztését a hálózati környezetre, amely lehetővé teszi ezen funkciók transzparens hálózati megjelenítését és invokációját. A SENSORIA rendszerre építve, a program-alapú eszközintegráció és az üzleti folyamat modellezés technikáit összekapcsolva, kidolgoztam egy módszert arra, hogy a rendszerben megjelenő fejlesztőeszközök között precíz, munkafolyamati modell-alapú munkaszervezést valósítsunk meg. Az általam javasolt módszer alapja a JBoss jbpm (Business Process Management) végrehajtó rendszer, és a hozzá tartozó, általam kiterjesztett jpdl (Process Definition Language) leíró nyelv. A jpdl nyelven leírt fejlesztési munkafolyamatokat az általam kifejlesztett rendszer képes a fejlesztők munkaállomásaiból, és a vállalat szervereiből álló infrastruktúrán végrehajtani. 10

11 Az általam kidolgozott rendszer működését a DIANA Európai Uniós FP6 kutatási programban kidolgozott, beágyazott szoftverek modellvezérelt fejlesztését leíró fejlesztési folyamat workflow-alapú megvalósításán mutatom be. A vállalati infrastruktúrán történő, kollaboratív fejlesztés során az előállított adatok (például tervezési dokumentumok, programkód) általában a fejlesztők számára központilag elérhetőek. Erre a feladatra leggyakrabban verziókezelő rendszereket használnak (Subversion, Concurrent Versions System), melyek bizonyos metaadatokat (verziószám, módosítás ideje) is tárolni képesek. Jellemző azonban, hogy ezek a dokumentumok nem önállóak, hanem például egy fejlesztési folyamat különböző stádiumaiban (tervezés, fejlesztés, tesztelés) ugyanahhoz a funkcionalitáshoz kapcsolódnak ilyen jellegű metaadatok megadására azonban ezekben a rendszerekben nincsen lehetőség. Ha a különféle dokumentumok között a metaadatok szintjén kapcsolatokat, hivatkozásokat tudnánk létrehozni, az a fejlesztési folyamat jobb követhetőségét eredményezné, hiszen lehetséges lenne egy követelmény (használati eset, use-case) leírását, az annak megfelelő tervezési dokumentumokat, az ezekhez tartozó teszteket és programkódot egymásnak megfeleltetni. Egy ilyen rendszerhez célszerű magasszintű támogatást kialakítani a különféle dokumentumtípusok definiálására, és az ezek által tartalmazott metaadatok megadására. Az fent említett példában a DIANA folyamathoz kidolgoztam egy dokumentumkezelő megoldást, amely támogatja a folyamat különböző dokumentumai közötti referenciák megadását. A megoldás az IBM Jazz Platform adattárolási, és adatmodell-tervezési mechanizmusát használja fel. A diplomatervben leírt eredmények a SENSORIA kutatási programban kidolgozott rendszer legújabb változatának részét képezik, valamint felhasználásra kerülnek a MOGENTES Európai Uniós FP7 kutatási projektben. 11

12 2. fejezet Motivációs esettanulmány: a DIANA fejlesztési folyamat Ebben a fejezetben bemutatok egy szoftverfejlesztési folyamatot, és a fejlesztési folymat végrehajtását támogató eszközkészletet. A folyamat megismerésének célja kettős: egyrészt motivációs példaként szolgál, vagyis ezen keresztül szeretnék rávilágítani a fejlesztési folyamatok végrehajtásával kapcsolatosan felmerülő problémákra. Másfelől a bemutatott fejlesztési folyamat esettanulmányként is szolgál, melyen a későbbiekben demonstrálom a felvázolt problémákra megoldást adó, általam elkészített rendszer felhasználását és további lehetőségeit a 6. fejezetben. A DIANA Európai Uniós projekt [1] repülőgépek vezérlőszoftverének kialakításával foglalkozik. A projekt során kidolgozásra került egy szoftverfejlesztési folyamat [3], amely modell-vezérelt tervezésre (Modell Driven Engineering) alapozva teszi lehetővé ezeknek a speciális, beágyazott szoftvereknek a tervezését. A modellvezérelt tervezés alapja a modellvezérelt architektúra alkalmazása a szoftverfejlesztés során. Maga a folyamat meglehetősen komplex, és mivel a példa szempontjából a felépítés teljes ismerete nem szükséges, ezért ennek bemutatásával csak a szükséges mértékben foglalkozom Az MDA (Model Driven Architecture) ismertetése A modellvezérelt architektúra, amint azt a 2.1. ábra mutatja, különválasztja a fejlesztendő alkalmazás platform-független, és platform-specifikus elemeit. A fejlesztés során előállítjuk a rendszer platformfüggetlen modelljét valamilyen alkalmazási terület (domain) specifikus nyelven. A platformfüggő rendszer modellje a platform-függetlenéből modell-transzformáció segítségével származtatható, melyhez segítségül használjuk a platform leírását (modelljét). A platform-specifikus modellből származtatható kódgenerálás segítségével maga a kész alkalmazás, vagy annak váza. A modellvezérelt-architektúra által javasolt tervezési módszer lényege tehát az, hogy a platform- 12

13 2.1. ábra. Modell-vezérelt architektúra (Model-Driven Architecture), forrás: [30] független részeket a platform-függőektől külön modellezzük, és amennyire csak lehet, programkód kézi írása helyett automatikus transzformációra, illetve kódgenerálásra hagyatkozunk Demonstrációs példa: a modellvezérelt DIANA fejlesztői környezet A DIANA projektben kidolgoztak egy modellvezérelt szoftverfejlesztési folyamatot megvalósító környezetet, amelynek célplatformja az AIDA szoftver architektúra (Architecture for Independent Distributed Avionics, bővebben lásd: [3]). A megalkotott szoftverfejlesztési folyamatot egy eszközökből álló lánc támogatja a követelmények felvételétől egészen a kódgenerálásig. Ennek a fejlesztési folyamatnak egy kis részlete, és az azt támogató eszközkészlet például szolgál, amelyen keresztül bemutatom a dolgozat koncepcionális és implementációs eredményeit. A tárgyalt folyamat a platform-független modellből a platform-függő modell előállításának támogatását írja le, vagyis ez egy modelltranszformációt előkészítő, segítő lépés. A folyamat során a fejlesztő a platform-független modell elemeit rendeli össze a platformon létező fogalmakkal. Ez idegen szóval a PIM/PSM mapping, vagyis a platform-független és platform-függő részek összerendelése. A felhasználó által elvégzett összerendelés egy modelltranszformációs lépést készít elő. A transzformáció végeredménye egy olyan platform-specifikus modell, amely lehetővé teszi a kész rendszer szimuláció- 13

14 ját a DIANA eszközkészlet többi elemének segítségével, illetve a kész szoftver kódgenerálását végző komponens alapvető bemenete. A folyamat két bemenő adatforrásból dolgozik, melyek közül az egyik egy, a követelményekből származtatott platform-független modell. A konkrét esetben egy domain-specifikus (grafikus) modellezési nyelven megalkotott, magasszintű modellről van szó, amely tartalmazza a rendszerünkben majdan elérhető szolgáltatások (job-ok) kapcsolatát a különféle szenzorokkal és beavatkozókkal, valamint leírja a szolgáltatások egymás közötti kommunikációját, azaz, hogy melyik szolgáltatás melyik másiknak küld üzenetet (2.2. ábra). Ez a platform-független modell tehát a kész rendszer szoftver komponenseit határozza meg, és a közöttük folyó kommunikációra összpontosít ábra. Példa a komponensek kommunikációját leíró dokumentumra, forrás: [4] A példaként választott folyamat másik bemenetét egy platform leíró modell (Platform Definition Model) adja, amely jelen esetben az AIDA platformot írja le. A platformnak a példa szempontjából lényeges tulajdonsága, hogy a kész szoftverben a különböző komponenseket (jobokat) izoláltan, úgynevezett partíciókban képes futtatni, és ha a komponens ezt támogatja, akkor képes egyik partícióból a 14

15 másikba áthelyezni. Ennek a lehetőségnek akkor van jelentősége, ha a partícióban, vagy azon belül egy komponensben hiba következik be, hiszen a komponens migrációja lehetővé teszi, hogy a kieső szolgáltatás minimális hatással legyen a többi szolgáltatás működésére. Az egyes partíciók közötti üzenetváltás dedikált kommunikációs csatornákon zajlik, amelyeket az AIDA keretrendszer központilag kezel. A felhasználó a például szolgáló folyamat során egy speciális eszköz segítségével a platform-független, tervezett rendszer viselkedését leíró modell elemeihez (például komponensek avagy jobok, adattípusok, kommunikáció) több lépésben platform-függő fogalmakat (például partíció, tényleges kommunikációs csatornák, a platform által támogatott adattípusok) rendel. A kézi összerendelési lépések mellett automatizált, számítógép által végzett lépések is megjelennek. A folyamat lépéseinek hatékony végrehajtása érdekében a lépéseket támogató eszközök mindegyike az Eclipse[9] rendszerben, űrlapok kitöltésével valósul meg. A fejlesztő munkájának segítése érdekében egy olyan szemléltető képernyő is készült, amely a folyamat lépésein megfelelő sorrendben történő haladást segíti. (Ennek a képernyőnek egy részletét mutatja a 2.4. ábra.) A példa célja tehát egy tipikus, modern technológiákra támaszkodó szoftverfejlesztési folyamat és a hozzá kapcsolódó integrált eszköz-rendszer bemutatása, amellyel egyre gyakrabban találkozhatunk az iparban. A következő két fejezetben a folyamat egyes lépéseit támogató eszközöket, valamint a folyamatban az eszközintegráció szempontjából lényeges tulajdonságokat mutatom be részletesen Az összerendelési folyamat lépéseinek ismertetése A például szolgáló folyamat lépéseit mutatják a 2.3. ábra sárga dobozai. A folyamat végrehajtását támogató eszközben is megtalálható a fenti folyamat áttekintését segítő elem, amelynek egy részletét a 2.4. ábra mutatja. A 2.4. ábrán jól látszik, hogy az eszköz a folyamat során elvégzett lépések követésére is képes. Az eszköz zölddel jelöli az elkészült feladatokat, sárgával a félkész feladatokat, pirossal azokat, amelyekre ugyan megnyitottuk a lépés elvégzéséhez szükséges szerkesztőt, de azon még munkát nem végeztünk, végül pedig szürkével jelöli azokat a feladatokat, amelyekhez tartozó szerkesztőfelületet még meg sem nyitottuk. Az egyes feladatokhoz tartozó speciális szerkesztőt a dobozokra duplán kattintva nyithatjuk meg. A következőkben a folyamat egyes lépéseihez használt szerkesztőket ismertetem Modellek importálása (Import PIM and Platform Description) A legelső szükséges lépés, amelynek során a platform leírását, és a platform-független modellt kijelöljük. Ezek a modellek szolgáltatják a lépések zömének bemenetét. Az importálás fájlból történik, a hozzá tartozó képernyőt a 2.5. ábra mutatja. 15

16 2.3. ábra. A példaként választott folyamat ábrája, forrás:[4] Adattípusok megfeleltetése (Data Type Mapping) Ennek a lépésnek a során a platform-független modellben lévő adattípusoknak megfeleltetünk egy olyan típust, amely a célplatformon létezik. Az adattípusok összerendelését az eszköz a 2.6. ábrán látható szerkesztőfelülettel támogatja. A szerkesztő bal felső sarkában a platform-független adattípusok közül tudunk választani egyet, majd a tőle jobbra lévő listából kiválaszthatjuk a megfeleltetni kívánt platformbeli adattípust. Az összerendelés rögzítéséhez az Add marking gombot kell megnyomni, melynek hatására az összerendelés megjelenik az alsó listában, a platform-független típus pedig eltűnik a bal felső listáról. 16

17 2.4. ábra. A példafolyamat áttekintését szolgáló képernyő a fejlesztést támogató eszközben Típus kódolások megválasztása (Encoding Mapping) Ez a feladat az előző részhez nagyon hasonló. Most a típusleképzést tovább kell specializálnunk, ezúttal a platformon létező típus kódolását (például hogy milyen hosszú egész szám ábrázolást választunk) kell meghatároznunk. A feladathoz tartozó szerkesztőfelület a 2.7. ábrán látható, és kezelése megegyezik az előzőével Kommunikációs interfész megválasztása (Interface Type Mapping) A következő lépésben definiálhatjuk, hogy az egyes modulok milyen programozói interfészt használnak a kommunikáció megvalósítására. Az AIDA köztes réteg üzenetküldési felülete mellett lehetőség van kijelölni az AIRINC653 szabványos architektúra kommunikációs felületét, mely főleg régebbi, öröklött alkalmazásoknál jellemző. A szerkesztőfelületet a 2.8. ábra mutatja. 17

18 2.5. ábra. Modellek importálását mutató képernyő 2.6. ábra. Adattípusok összerendelése 18

19 2.7. ábra. Típus kódolásának kiválasztását segítő szerkesztő 2.8. ábra. Kommunikációs interfészek meghatározását támogató szerkesztő Alkalmazás típusának kiválasztása (Application Type Mapping) Ebben a lépésben az egyes modulok célplatformját állíthatjuk be. Alapvetően kétféle választásunk lehet: az alkalmazás vagy kihasználja az AIDA architektúra szolgáltatásait, vagy nem (non-aida típus). Az utóbbi lehetőség öröklött, régi alkalmazások használatát teszi lehetővé, amelyek például közvetlenül használják az operációs rendszer erőforrásait. A szerkesztő felületét a 2.9. ábra mutatja. 19

20 2.9. ábra. Alkalmazás típusának kiválasztását segítő szerkesztő Modulok közötti üzenetek összerendelése (Inter-Module Message Mapping) Ebben a lépésben a modulok egymás között elküldött és fogadott üzeneteit rendelhetjük egymáshoz. Egy importált platform-független modell egy modulnak tekinthető, melyben a modulon kívülre küldött, illetve a kívülről érkező üzenetek explicit le vannak írva. Több importált modul esetén az egyes modulok által küldött, és mások által fogadott üzenetek rendelhetők össze a ábra szerinti képernyő segítségével. Hasonlóan a típusok összerendeléséhez itt is a két felső listában választunk ki egy-egy elemet, amelyek megfelelnek egymásnak ábra. Modulok közötti üzenetek összerendelését támogató szerkesztő képe 20

21 Partíciók definiálása (Partition creation) Ebben a lépésben definiáljuk a partíciókat, amelyekben a modulok futni fognak. Partíciót a képernyő alján található űrlap segítségével hozhatunk létre. A partíciók létrehozását a ábra képe szerinti felületen tehetjük meg ábra. Partíciók létrehozását támogató szerkesztőfelület A rendszer állapotleíró táblázaténak elkészítése (System HM Table Creation) Ebben a lépésben a rendszerben esetlegesen fellépő hibákat definiálhatjuk a rendszer különböző állapotaiban. A hiba kontextusát is meg kell adnunk, amely lehet modul, alkalmazás, vagy folyamat szintű. A definiált hibajelenségek a rendszerünk állapotleíró (health monitor) táblázatába kerülnek. A hibajelenség felvételekor először ki kell választanunk a bal oldali listából azt a rendszerállapotot, amelyben a hiba bekövetkezhet. A beviteli felületet a ábra mutatja Használt AIDA szolgáltatások kijelölése (Service Inclusion) Ennek a lépésnek a során jelölhetjük ki, hogy a platform-független modell egyes moduljai (job-jai) milyen, az AIDA-ban elérhető szolgáltatásokat használhatnak. A beállító képernyőt a ábra mutatja. 21

22 2.12. ábra. Hibajelenségek definiálását segítő képernyő ábra. Felhasznált AIDA szolgáltatások megadása a szerkesztővel Kompatibilis partíciók kijelölése az egyes alkalmazásokhoz (Application Compatibility Mapping) E lépés során platform-független modellben definiált alkalmazásokhoz hozzárendelhetjük azokat az AI- DA partíciókat, amelyekben futhatnak. A lépést támogató képernyőt mutatja a ábra. 22

23 2.14. ábra. Partíciók alkalmazásokhoz rendelését támogató képernyő Alkalmazások elhelyezésének megállapítása (Application Allocation) Ebben a lépésben az eddig bevitt adatok alapján a rendszer kiszámítja a lehetséges összerendeléseket a partíciók és a platform-független modellben definiált feladatoknak (joboknak) megfelelő alkalmazások között. A ábra egy olyan futás eredményét mutatja, ahol több megfelelő konfiguráció is létezik ábra. Alkalmazások partíciókhoz rendelésének eredményei 23

24 Kommunikációs csatornák megállapítása (Communication Channel Allocation) Amennyiben létezik és, az előző képernyőn kiválasztottunk egy, a bevitt adatoknak megfelelő alkalmazás allokációt, úgy következhet az utolsó lépés. Ennek során megállapításra kerülnek, hogy milyen partíciók közötti kommunikációs csatornákra van szükség az adott allokáció mellett. Erre mutat példát a ábra ábra. Kommunikációs csatornák megállapítása a folyamat végén 2.4. Eszközintegráció megjelenése a példában Az előző fejezetben megismertünk egy fejlesztési folyamatot, és egy, a támogatására készült fejlesztőeszközt. A megismert fejlesztőeszköz a folyamat lépéseit támogató eszközöket Eclipse környezetben foglalja egybe, vagyis nem kell külön programot indítani a lépések elvégzéséhez, hanem egy közös grafikus felületen jelennek meg az egyes szerkesztők. A közvetlen fejlesztői akciót igénylő szerkesztők mellett a alfejezetben megjelenik egy automatikus analízis eszköz, amely a fejlesztési folyamat többi lépésénél használt szerkesztőjével összhangban, grafikus felületen keresztül hívható meg. Az ehhez hasonló, automatikus számítások végrehajtása (kódgenerálás, tesztek futtatása), és integrált felületen történő elérése tipikus igény napjaink szoftverfejlesztési folyamataiban. A 2.4. ábra képe alapján, a rendszernek része egy olyan modul, amely a fejlesztési lépések helyes végrehajtásáért felel, ami fontos többletet nyújt az eszközök puszta grafikus megjelenítéséhez képest. A példabeli eszközök közös modell felett dolgoznak: egyrészt az importált modelleket olvassák, másrészt pedig az összerendeléseket egy külön modellben tárolják el, tehát minden eszköz ugyanazokat a 24

25 dokumentumokat használja fel. Amennyiben a fejlesztési folyamatot több fejlesztő hajtaná végre, úgy szükséges ezeket a dokumentumokat valamilyen verziókezelő rendszerben tárolni, ezzel lehetővé téve a közös munkát A példa tanulságai A példában látható eszközintegráció specifikusan a DIANA folyamathoz készült el, és a grafikus integrációra, valamint az adatintegrációra fókuszál. A fejlesztési folyamat lépéseinek helyes sorrendben történő végrehajtását célzó logika és felhasználói felület (2.4. ábra) szintén egyedi fejlesztés eredménye, specifikusan a DIANA folyamathoz készült. A DIANA folyamatban felmerülő integrációs problémák és megoldásuk alapján kihívást jelent egy olyan rendszer megalkotása, amely: általánosságban képes megoldani egy fejlesztési folyamatban használatos eszközök felhasználói (fejlesztői) és programozói elérését. képes biztosítani egy fejlesztési folyamat lépéseinek megfelelő sorrendben történő végrehajtását egy magasszintű folyamatmodell alapján. képes a fejlesztési folyamat elosztott végrehajtására, vagyis képes több felhasználó (fejlesztő) bevonására, különböző hosztokon elérhető eszközök felhasználására, és a folyamat során előálló dokumentumok kezelésére. A 3. fejezetben javaslatot teszek egy olyan keretrendszerre, amely általánosabban oldja meg az eszközintegráció problémáját. A keretrendszer alacsonyabb szinten, szolgáltatásokhoz biztosít egységes hozzáférést, akár hálózaton keresztül is, illetve az így elérhető eszközök felett képes folyamatokat végrehajtani. A folyamatvégrehajtás gondolata a DIANA eszközkészletében is megjelenik (a már sokat említett 2.4. ábra a bizonyíték erre). A DIANA folyamat átültetését a részben általam implementált keretrendszerbe a 6. fejezet írja le részletesen. Az általam implementált komponensek technikai részleteit az 5. fejezet tárgyalja, míg az implementációhoz felhasznált technológiákat részletesen a 4. fejezet ismerteti. 25

26 3. fejezet A workflow-alapú eszközintegrációs rendszer 3.1. Bevezetés: state of the art eszközintegráció ismertetése Ebben a fejezetben először néhány létező, általános eszközintegrációs megoldást fogok ismertetni, majd a megismert technikák tulajdonságai alapján meghatározom annak keretrendszernek a fő jellemzőit, amely a 2. fejezetben felvetett problémák megoldására alkalmas, és amelyet a 3.2. alfejezetben részletesen bemutatok OLE Automation Az OLE Automation technológia [2] a Microsoft Windows operációs rendszereken lehetővé teszi, hogy bizonyos támogatott programnyelveken (például Visual Basic, C++, JavaScript) olyan programokat írhassunk, amelyek futásidőben tudják meghatározni, hogy egy adott COM (Component Object Model) komponensnek melyik függvényét hívják meg. A szolgáltatást nyújtó komponenst automation szervernek, az igénybe vevőt automation kliensnek nevezik. Ahhoz hogy egy komponens szolgáltatásai így igénybe vehetők legyenek, utólag, vagy fejlesztés közben meg kell tervezni a programozott elérés interfészét. Az ilyen módszerrel hívható függvények listáját, és az elérhető adattagokat a komponens írója általában dokumentációban, vagy típuskönyvtárak (type library) formájában szolgáltatja. A technológia segítségével a bonyolult COM programozói interfész ismerete nélkül használhatunk szolgáltatásokat, például a Microsoft Office-nak vannak a technológia segítségével igénybe vehető részei [24]. Az OLE Automation szolgáltatások integrációjára operációs rendszer szinten nyújt megoldást. A szolgáltatások folyamatba szervezése a kliensben programozottan, alacsony szinten történik. 26

27 Web szolgáltatások és a BPEL A Web szolgáltatás (Web Services) (bővebben: [37]) fogalma olyan szoftver rendszert takar, amely szolgáltatások hálózaton keresztül történő megosztására, és a szolgáltatást nyújtó komponens meghívására biztosít lehetőséget. A technológia a szolgáltatások leírására egy programnyelvtől független, XML alapú leírónyelvet, a WSDL-t (Web Services Definition Language, lásd [36]) használja, amely leírás alapján a szolgáltatás interfésze leképezhető egy konkrét programnyelvre. A web szolgáltatások leírását és keresését támogató könyvtárszolgáltatás az UDDI (Universal Description Discovery and Integration, [23]). A web szolgáltatások használatát vázlatosan mutatja be a 3.1. ábra ábra. Web szolgáltatások használata A leíró fájl hálózaton keresztül hozzáférhető, így a szolgáltatás programnyelv-specifikus leíró interfésze és a felhasznált komplex típusok leképzése akár fejlesztés közben előállíthatóak, és használhatóak. A szolgáltatás meghívása szintén hálózaton keresztül SOAP (Simple Object Access Protocol, [35]) üzeneteken keresztül történik. Ilyenkor a nyelv-specifikus típusokat ismét nyelvfüggetlenné kell alakítani, hogy a hívás paramétereit, és a visszaérési értéket a hálózaton át tudjuk vinni, és a szolgáltatást nyújtó oldalon az implementációs nyelvnek megfelelő típusokká tudjuk alakítani. A web szolgáltatások folyamatba szervezéséhez használhatunk hagyományos programozási nyelveket (Java, C#), de ennél magasabb szintű támogatást kapunk, ha a BPEL (Business Process Execution Language) folyamatleíró nyelvet [38] használjuk, amely kifejezetten web szolgáltatások munkafolyamatba szervezésére terveztek. Ehhez a nyelvhez számos, az egyszerű szövegesnél magasabb szintű, modell-alapú szerkesztő is elérhető (például: [25], [7]). Web szolgáltatások jellemzően nagyvállalati környezetben használatosak, komoly előnyük a platform-függetlenség, ez viszont a szolgáltatások hívásánál komoly árat (kommunikációs többlet) jelenthet, a küldött és fogadott üzeneteket ugyanis a köztes, programozási nyelvtől független reprezentációba kell leképezni. 27

28 A SENSORIA Development Environment keretrendszer A SENSORIA (Software ENgineering for Service-ORIented overlay computers)[32] egy Európai Uniós kutatási projekt, melynek keretein belül kifejlesztésre került egy Eclipse fejlesztői környezetbe épülő eszközintegrációs keretrendszer. Ez a SENSORIA Development Environment (SDE)[31], amely mivel a Java alapokon nyugvó Eclipse környezetre épül bármilyen platformon használható. Az SDE rendszer eszközintegrációs megközelítésében egy eszköznek egy Java osztály formájában elkészített szolgáltatás felel meg. A szolgáltatás tényleges funkcionalitást nyújtó része lehet akár egy parancssori program, melyet a szolgáltatás csak burkol, vagy lehet teljesen Java nyelven implementálva. Szolgáltatások dinamikus definiálásához a rendszer az Eclipse plugin mechanizmusát használja. A szolgáltatások elérésére az SDE primitív felhasználói felületet biztosít, melyen keresztül a szolgáltatások a felhasználó által meghívhatóak. Az SDE lehetőséget biztosít továbbá a szolgáltatások JavaScript nyelven történő meghívására is, így lehetővé teszi primitív folyamatok megalkotását. Az SDE-ben rendelkezésünkre áll egy objektumtároló is, amelynek segítségével adatokat oszthatunk meg a szolgáltatások között ezek az adatok azonban a környezet leállításával elvesznek, vagyis nem perzisztensen kerülnek tárolásra. Az SDE rendszer kifejezetten eszközintegrációra kialakított környezet, amely lokálisan teszi lehetővé az eszközök integrációját. A keretrendszer részletes bemutatása a 4.1. alfejezetben olvasható Az IBM Jazz Platform Az IBM Jazz Platform[12] szintén az Eclipse technológiára épülő, kliens-szerver architektúrájú rendszer. A Jazz Platform is kifejezetten eszközintegrációra kidolgozott technológia, amely a szerver oldalon az SDE rendszerhez hasonlóan az Eclipse plugin mechanizmusára építve teszi lehetőve szolgáltatások és adatmodellek definiálását. A szerver oldalon definiált szolgáltatások távoli hosztról is elérhetőek. A Jazz Platformban lehetőségünk van komplex, objektum-orientált adatmodellek leírására, mely adatmodellek példányait a Jazz rendszer képes relációs adatbáziskezelő segítségével perzisztensen eltárolni. Az eszközök integrációjának ez a fajta megközelítése hasonlít az SDE megközelítéséhez: a szolgáltatást nyújtó implementáció lehet teljesen saját Java logika, vagy bármilyen Java technológiával burkolt, akár natív implementáció. A Jazz rendszer nem tartalmaz olyan technikát, amely az eszközökből folyamatok szervezését támogatná. A Jazz rendszert részletesebben a 4.2. alfejezet mutatja be Összegzés A felsorolt és ismertetett eszközintegrációs kísérletek láttán elmondható, hogy manapság a szoftverfejlesztési folyamatok támogatására kialakított eszközintegrációs technika friss területnek számít. Az 28

29 általános célú integrációs technológiák (mint az OLE Automation, vagy a 4.1. alfejezetben részletesen bemutatott SENSORIA rendszer) jellemző gyengesége, hogy nem létezik hozzá kifejezetten munkafolyamatok leírását támogató munkafolyamat-leíró nyelv, és ehhez tartozó végrehajtó rendszer, a munkafolyamat kézi programozása pedig meglehetősen nehézkes. Szoftverfejlesztési folyamatok támogatásához, vagy (fél)automatikus végrehajtásához egy munkafolyamat-végrehajtó rendszer egyértelműen előnyös. Ha fejlesztési folyamatról beszélünk, akkor mindenképp szükséges a fejlesztőeszközök egységes eléréséhez egy bővíthető fejlesztői környezet, amelyben a különböző eszközök magas szinten, grafikusan is integrálhatóak. Egy általános, szolgáltatásokat integráló keretrendszer kialakításához elegendő lenne egy primitív, a szolgáltatások hívását biztosító grafikus környezet, azonban ha később specifikusabb területre (például szoftverfejlesztés támogatására) kívánjuk finomítani a rendszert, akkor elengedhetetlen a magasszintű grafikus vezérlőelemek létrehozásának lehetősége. Bővíthető, ingyenesen elérhető, nyílt forráskódú fejlesztőrendszerből a két legjelentősebb a Netbeans és az Eclipse, mely utóbbira az IBM Jazz Platform (részletesen lásd: 4.2. alfejezet), és a SENSORIA rendszer is támaszkodik. A cél tehát egy olyan általános eszközintegrációs architektúra kialakítása, amely később alkalmas lehet szoftverfejlesztési folyamatok támogatására, és vállalati infrastruktúrán, elosztottan is képes működni. Több fejlesztő használja, és lehetőség van hálózaton keresztül, a manapság divatos cloud computing elvnek megfelelően bárhol, egy szerveren, vagy akár egy másik fejlesztő gépén futó szolgáltatások elérésére, közvetlenül a fejlesztői környezetből. A rendszernek képesnek kell lennie munkafolyamatok végrehajtására, amely munkafolyamatok az egyes eszközök szolgáltatásainak igénybevételéből állnak Az eszközintegrációs keretrendszer modellje A 3.2. ábra mutatja a vázlatos felépítését annak a keretrendszernek, amely eszközeink integrációját hivatott támogatni. A 3.2. ábrán látható architektúrát a MOGENTES Európai Uniós FP7 kutatási projektben [22], az egyetem kontribútoraival (Majzik István, Polgár Balázs, Ráth István) közösen terveztük meg. Az architektúra részletes leírását a [27] cikk tartalmazza. Ahhoz, hogy az eszközeink (Tool-ok) által nyújtott funkciókat egységesen érhessük el, szükséges egy olyan elemet készíteni minden eszközhöz, amely kivezeti a keretrendszer számára a nyújtott szolgáltatásokat. Ez az ábrán látható Connector (csatoló) elemek elsődleges szerepe. A később ismertetett Artefact Store-ba ezek a komponensek úgy tudnak adatokat írni, hogy az a többi eszköz (Connector) számára is olvasható. Az eszközök bármilyen felülettel rendelkezhetnek (grafikus, parancssori stb.), amennyiben a keretrendszer ezt a felületet programozottan meg tudja hajtani. A csatolók teszik azt lehetővé, hogy a keretrendszer számára minden eszköz egységes felülettel rendelkezzen. Az eszközeinket a keretrendszerben reprezentáló csatolókat (a Connectorokat) a Tool Manageren 29

30 3.2. ábra. Eszközintegrációs keretrendszer architektúrája, forrás: [27] keresztük lehet elérni, ami egy Tool Repository-ra, támaszkodva üzemel. A Tool Manager tartja nyilván a rendszerben elérhető csatolókat, de feladata az eszközök keresésének támogatása, illetve rajta keresztül eltávolíthatunk, vagy hozzáadhatunk csatolókat a rendszerhez. A Tool Repository a Tool Manageren keresztül elérhető, csatolókkal kapcsolatos adatokat tárolja. Az integráció szükséges feltétele, hogy az eszközök között adatokat lehessen megosztani. Erre szolgálnak az Artefact Manager és Data Repository komponensek. A Data Repository az adatok tárolásáért felelős relációs adatbáziskezelő, amelyet a keretrendszer elemei az Artefact Manager komponensen keresztül tudnak elérni. Az Artefact Manager az adatok megosztását magas szinten támogatja, vagyis lehetővé teszi metaadatok elérését, és verziókezelést is biztosít. A dokumentumok verziókezelés alatt tartása lehetővé teszi az adatok nyomon követését egy hosszabb folyamat során. A dokumentum különféle adatokat jelölhet, például fájlokat, objektumokat, illetve domain-specifikus modelleket. Az Artefact Manager segítségével az eszközök igénybevételekor (bemenő) adatokat tudunk átadni, valamint az eszközök igénybevételekor keletkező dokumentumokat tudunk tárolni. A keretrendszer lehetőséget biztosít a rendelkezésre álló eszközökből (Toolokból) folyamatok összeállítására és végrehajtására. A folyamat modelljét a Process Model tartalmazza, melyet egy modell alapú folyamatszerkesztő, a Process Editor segítségével állíthat össze a felhasználó. A folyamatmodellben olyan fogalmak jelennek meg, mint például a (szoftverfejlesztési) folyamat egyes feladatai, az egyes feladatok elvégzése során felhasznált és előálló dokumentumok, a különböző szerepek (amely szerepet viselő felhasználók felelősek egy adott feladat végrehajtásáért), vagy a feladatok elvégzéséhez szükséges eszközök. A folyamat végrehajtását a Process Execution Engine (végrehajtó motor) végzi. A végrehajtás során 30

31 a folyamatvégrehajtó a leírás (Process Model) alapján a Tool Manager segítségével megkeresi azt az eszközt, amely a feladat végrehajtására képes, és igénybe veszi az általa nyújtott szolgáltatást. Konkrét esetben a folyamatleíró nyelv absztrakciós szintjétől függően szükség lehet a folyamat finomítására, vagy transzformációjára (a konkrét végrehajtási lépéseket jobban követő nyelvre) ahhoz, hogy végrehajtható leírást kapjunk. A végrehajtás során rendelkezésre áll egy felhasználói felület (Process Execution User Interface), amelyen nyomon követhetjük a folyamat végrehajtásának állását Az eszközintegráció értelmezése a diplomatervben A diplomaterv további részében a 3.2. ábra szerinti architektúrának egy implementációját fogom ismertetni, ahol az eszközök integrációjának fogalma specifikus értelemben kerül elő. Az eszközöket az Eclipse fejlesztői környezetben definiáljuk, és ennek a bővíthető platformnak az integrációs képességeire építve tudunk saját keretrendszert definiálni. Egy eszközintegrációs keretrendszer Eclipse környezetben történő működtetése, és az eszközök szolgáltatásainak munkafolyamat-végrehajtó motorból történő meghívása érdekes lehetőségekkel kecsegtet. Egyrészt a folyamatból hívható szolgáltatások az Eclipse rendszer komponenseit is megszólíthatják, ami lehetővé teszi például szerkesztő felületek automatikus megnyitását. Ha ilyesmire képesek vagyunk, akkor különféle szerkesztők sorozatos megnyitásával lehetséges különféle eszközökkel támogatott, bonyolult szoftverfejlesztési folyamatok automatizált végrehajtása is. Eclipse-alapú eszközintegrációs keretrendszer a SENSORIA Development Environment és az IBM Jazz Platform is, melyeket részletesen bemutatom a 4. fejezetben. A keretrendszer általam megvalósított változatát mutatja a 3.3. ábra. A keretrendszer implementációjának alapjául a SENSORIA Development Environment (SDE) szolgált (3.3. ábra piros részei), amely a 3.2. ábrán szereplő Tool Manager szerepét tölti be, és lehetőséget nyújt SENSORIA Tool-ok (Connector elemek) definiálására. A SENSORIA rendszer azonban nem biztosít lehetőséget távoli hoszton elérhető eszközök elérésére, valamint nem rendelkezik magasszintű folyamatvégrehajtási képességekkel, ezért két komponenssel kiegészítettem: Lehetővé tettem, hogy az SDE ne csupán lokális, hanem távoli eszközök elérésére is képes legyen. Ez nagyvállalati infrastruktúrában kiemeleten fontos, hiszen bizonyos szolgáltatásoknál sokkal kifizetődőbb a központi elérés. Ez a hozzájárulás a SENSORIA Development Environment hivatalos honlapján [31] is elérhető (pontos URL: [21]). A SENSORIA rendszer hiányosságát pótolva a JBoss jbpm modell-alapú munkafolyamat-végrehajtó motort illesztettem a rendszerhez. Ennek segítségévél magasszintű folyamatmodell alapján eszközök hívhatóak meg, melyek akár a fejlesztői környezet részét képezhetik. Így elérhető közel- 31

32 ségbe kerül például egy szoftverfejlesztési folyamat végrehajtása, amely egy vagy több fejlesztő gépén használ eszközöket, ezzel bevonva őket a fejlesztési folyamatba. A rendszerhez illesztett jbpm keretrendszer a 3.3. ábrán a Process Execution Engine szerepét tölti be. A munkafolyamatok megalkotását jpdl nyelven végezhetjük ez tehát a Process Definition Language. A nyelvhez magasszintű szerkesztőfelület ( Process Editor ) is rendelkezésre áll a JBoss jóvoltából. A JBoss jbpm rendszer felhasznált elemeit a 3.3. ábrán zölddel jelöltem. A jbpm rendszert részletesen ismerteti az 5.3. alfejezet. A fenti két komponenesen kívül megvalósítottam egy speciálisan a DIANA szoftverfejlesztési folyamat adatmodelljéhez használható addattároló komponenst, amely az IBM Jazz Platform adattárolási szolgáltatását használja fel. Ez az IBM Jazz Repository Service komponens, mely az Artefact Manager szerepét tölti be, és az 3.3. ábrán kékkel jelöltem. Az általam megvalósított komponens a felépítését részletesen tárgyalja a 6. fejezet. Az automatikus folyamatvégrehajtás demonstrálására a 6. fejezetben bemutatom a DIANA szoftverfejlesztési folyamat modelljét a keretrendszerben felhasznált jpdl munkafolyamatleíró-nyelven. Ugyanitt ismertetem a DIANA folyamat eszközeinek a 2. fejezetben részletesen bemutatott fejlesztőeszközök, valamint a alfejezetben ismertetett automatizált allokációt végző eszköz integrációját a keretrendszerbe. A felsorolt implementációs eredmények együttesen egy, a 3.2. ábrának megfelelő, folyamatvezérelt eszközintegrációs rendszert adnak ki, amely rendszer a MOGENTES Európai Uniós FP7 projektben[22] is felhasználásra kerül. 32

33 3.3. ábra. A keretrendszer diplomatervben bemutatott implementációja 33

34 4. fejezet Felhasznált technológiák 4.1. A SENSORIA Development Environment, mint eszközintegrációs platform A SENSORIA projekt keretében fejlesztették ki a SENSORIA Development Environment (SDE) rendszert, amely az Eclipse fejlesztői környezetet terjeszti ki, úgy, hogy lehetővé teszi a 3.2. ábra analógiája szerint Connectorok definiálását, valamint biztosít egy egyszerű Tool manager és Artefact Store implementációt, amelyek memóriabeli tárolók felett dolgoznak. A keretrendszer lehetőséget biztosít JavaScript nyelven egyszerű munkafolyamatok megfogalmazására is (így tehát koncepcionálisan hasonlít az OLE Automationre), illetve felhasználói felületet biztosít a rendelkezésre álló eszközök, és funkcióik, valamint az Artefact Storehoz hasonló komponens objektumainak megjelenítésére, az eszközök funkcióinak használatára Az Eclipse integrált fejlesztőkörnyezet Az Eclipse rendszer egy alapvetően Java nyelven írt, nyílt, bővíthető fejlesztői környezet és alkalmazás platform. A rendszer Java nyelven írt komponensekkel kiterjeszthető, és ez által a Java nyelvű fejlesztésen kívül elvileg tetszőleges programozási nyelven történő szoftverfejlesztést képes támogatni. Az Eclipse rendszer alapja a 3.0-s verzió óta az OSGi Release 4 szabványnak (Open Services Gateway initiative) megfelelő Equinox környezet. Az OSGi rendszerarchitektúra modell Az OSGi specifikáció Release 4 verziója egy komponens alapú rendszert le, Java nyelven írt programok számára. Az OSGi rendszer black boxként tekintve némi hasonlóságot mutat egy Java alkalmazásszerverhez, melyben kész webes alkalmazásainkat tudjuk a külvilág számára az interneten elérhetővé tenni. 34

35 4.1. ábra. Az Eclipse rendszer vázlatos felépítése A két rendszer között lényeges különbség, hogy az OSGi keretrendszer elsődlegesen csekély erőforrásokkal bíró, beágyazott rendszerekhez kialakított környezet, míg az alkalmazásszerverek ennél általában nagyobb erőforrás igényűek. Az OSGi rendszer szoftverkomponensek futási időben történő dinamikus betöltését teszi lehetővé. A szoftverkomponenseket bundle-ként (kötet) említik az OSGi terminológiában. A bundle Java osztályok, és egy hozzájuk tartozó leíró állomány, a manifeszt fájl közös elnevezése. A bundle általában JAR fájl formájában kerül terjesztésre. Minden egyes kötetnek egyedi azonosítója van, és a manifeszt fájlban explicit módon deklarálja a függőségeit (az importált Java csomagokat), illetve a belőle mások által felhasználható (exportált) Java csomagokat. Az R4 specifikáció szerint egy bundle megnevezhet másik bundle-öket, amelyek megléte szükséges a futásához ilyenkor hozzáfér annak exportált csomagjaihoz is. A függőségeket verziószámmal láthatjuk el, jelezve hogy legalább/legfeljebb milyen verzió szükséges az adott csomagból vagy bundle-ből. Minden bundle-nek saját classloadere van, mely az adott bundle-ben a classpath-ban található elemek betöltéséért felelős. A classpath értéke a manifeszt fejlécében állítható. Az importált csomagok betöltésével mindig az azt exportáló bundle-t bízza meg a rendszer, így lehetőség van arra, hogy a közösen használt Java osztályok csak egyetlen egyszer töltődjenek be, ezzel csökkentve a rendszer memória felhasználását. 35

36 Minden bundle megadhat egy osztályt (Bundle-Activator osztály), amely a bundle indításakor példányosításra kerül, és a bundle életciklusát érintő eseményekről (elindítás, leállítás) tájékoztatást kap. Egy bundle életciklusát a 4.2. ábra szemlélteti ábra. OSGi bundle életciklusát leíró modell, forrás: [34] A bundle-t használat előtt először telepíteni kell a rendszerbe. A legtöbb OSGi keretrendszer futás közben egy konzolt bocsájt rendelkezésünkre, amelynek segítségével egy új bundle telepítése mellett lekérdezhető a már telepített bundle-ök és állapotaik. Általában azonban egy konfigurációs állományban, még a keretrendszer indításakor határozzuk meg, hogy mely bundle-ok töltődjenek be. A telepített bundle akkor kerül resolved állapotba, ha a felhasznált függőségeit a rendszer teljesíteni tudja. Ezután a bundle elindítható, indításakor (start) pedig Starting állapotba kerül, majd a Bundle- ActivationPolicy manifeszt fejléc mező beállításaitól függően meghívódik a Bundle-Activator manifeszt fejlécben leírt osztály új példányának start metódusa. A gyorsabb rendszerindítás céljából (hogy ne töltődjön be egyszerre az összes bundle Bundle-Activator osztálya) a példányosítás késleltethető például az első bundle-beli osztály betöltéséig. A start metódus futásának befejezéséig a bundle Starting állapotban van. Az aktív bundle leállításakor (kézi leállításkor, vagy rendszer leállásakor) a stop metódus hívódik meg. A hívás végrehajtása alatt a bundle Stopping állapotban van. A stop metódus használható például erőforrások felszabadítására. Az uninstall hívással a bundle eltávolítható a rendszerből (nem indítható újra). 36

37 OSGi szolgáltatások (services) Az OSGi keretrendszer alapja tehát a bundle-ök közötti függőségek feloldása, illetve az életciklus menedzselése. Az OSGi specifikáció része egy szolgáltatások lekérésére, és definiálására használatos modul, valamint az ennek segítségével definiált alapvető szolgáltatások (például csomagokról, bundle-ökről futásidejű információ lekérése, üzenetküldési szolgáltatás, naplózás stb.) Az OSGi keretrendszer önmagában lehetőséget biztosít szolgáltatások definiálására (regisztrálására) és interfész alapján történő lekérésére, használatára. Ezekre a keretrendszer központilag ad lehetőséget, vagyis minden bundle akármelyik osztálya, szabadon regisztrálhat szolgáltatásokat, illetve számára elérhetőek a többi bundle által definiált szolgáltatások. Ennek az elvnek a hátránya az, hogy a keresett, használni kívánt szolgáltatás nem feltétlenül elérhető a rendszerben azért, mert az azt definiáló bundle még nem került betöltésre, vagy a szolgáltatás regisztrálása egyéb, nem teljesülő feltételekhez van kötve. Részben a fenti nehézségek miatt, részben pedig azért, mert az OSGi rendszer nem elég régóta használatos az Eclipse alapjaként, ezért az Eclipse rendszerben nem ez a szokásos módja szolgáltatások deklarálásának, és felhasználásának. Az eszköz és szolgáltatás fogalma Eclipse környezetben Miután az Eclipse rendszer alapját képző OSGi keretrendszerrel megismerkedtünk, most társítsuk az eszközintegrációs keretrendszer alapvető fogalmait az Eclipse-ben megjelenő fogalmakhoz. Az Eclipse fejlesztői környezet bővíthető, azaz lehetőségünk van saját modulok definiálására. Az ilyen beépülő modulokat Eclipse plugineknek hívják, és amióta a fejlesztő környezet alapja az OSGi keretrendszer, azóta a pluginek OSGi bundleként valósulnak meg, vagyis minden pluginnek megvannak az OSGi specifikáció által leírt lehetőségei szolgáltatásaik megosztására más pluginekkel. A pluginfejlesztők körében azonban szinte kizárólagosan az Eclipse rendszerben korábban meghonosított mechanizmust használják. A manifeszt fájltól függetlenül minden pluginnek lehet egy saját plugin.xml állománya, amely kétféle információt tartalmaz: egyrészt leírja, hogy ez a plugin milyen szolgáltatásokat, kiterjesztési pontokat (extension point) definiál, másrészt ő maga milyen más szolgáltatásokat, kiterjesztéseket (extension) nyújt más pluginek számára. A definiált szolgáltatás egyedi azonosítóval bír, és egy XSD fájl (XML Schema Definition) írja le. Minden olyan pluginnek, ami ehhez az azonosítóhoz nyújt kiterjesztést, a plugin.xml fájl szolgáltatás leíró részében meg kell felelnie ennek a sémadefiníciónak. A séma a leírás valamelyik mezőjében általában elvárja egy argumentum nélküli konstruktorral rendelkező osztály teljes nevét. Ehhez megadható akár egy kötelezően implementálandó ősinterfész, vagy ősosztály is. A pluginek képesek a keretrendszertől elkérni egy adott azonosítójú kiterjesztési ponthoz tartozó hozzájárulásokat (más pluginek kiterjesztéseit, szolgáltatásait), képes lekérni a plugin.xml fájlban az 37

38 egyes XML elemekhez tartozó, a bővítmény írója által megadott értékeket, illetve megadott osztálynév esetén elkérni az Eclipse keretrendszertől annak egy példányát. E miatt a példányosítás miatt van szükség argumentum nélküli konstruktorra bizonyos megadott osztályoknál. Ezzel a módszerrel csatolódnak szét az Eclipse rendszer részei: bizonyos pluginek definiálják, hogy milyen kiterjesztéseket várnak más pluginektől, és futásidőben képesek az összes kiterjesztést felfedezni, és igénybe venni, anélkül, hogy közvetlenül deklarálniuk kellene a függőségüket a nyújtott szolgáltatásoktól. Fontos megjegyzés, hogy egy plugin deklarálhat olyan kiterjesztést is, aminek kiterjesztési pontját saját maga definiálta. A kiterjesztési pontok, és kiterjesztések definiálásához a fejlesztői környezetben grafikus segédeszközök állnak rendelkezésre A SENSORIA keretrendszer részletes leírása A SENSORIA keretrendszer három Eclipse pluginből épül fel: a modellt tartalmazó eu.sensoria-ist. casetool.core pluginől, a grafikus felhasználói felületet tartalmazó eu.sensoria-ist.casetool.ui pluginből, illetve az 3.2. ábra terminológiája szerinti Connector elemek fejlesztését támogató eu.sensoriaist.casetool.dev pluginből. A SENSORIA keretrendszer illeszkedését az Eclipse környezetbe a 4.3. ábra mutatja ábra. A SENSORIA keretrendszer illeszkedése az Eclipse környezetbe (forrás: [26]) A SENSORIA keretrendszer modellje három fő komponensből áll: a Tool Storeból, mely az 3.2. ábrán szereplő Tool Managernek felel meg, a Blackboardból, amely egy egyszerű Artefact Manager szerepet tölt be, és a kettőt burkoló SensoriaCore komponensből. 38

39 A Tool Store működése A SENSORIA Development Environment egyik lényeges komponense a Tool Store, amely lehetővé teszi a Sensoria Toolok keresését, a definíciójuk újraolvasását, a kategóriák fastruktúrájának bejárását, és visszahívást biztosít a Toolok eltávolításáról, vagy hozzáadásáról az ezt kérő komponenseknek (listener minta alkalmazásával). A Tool Store komponens (osztály) a Sensoria core plugin (eu.sensoria-ist.casetool.core) indításakor inicializálódik: a pluginben definiált Sensoria Tool extension pointhoz tartozó extension-ök lekérése után a rendszer minden egyes Sensoria Tool esetén példányosítja a szolgáltatást nyújtó osztályt. Ezután a plugin.xml fájlban található további adatok alapján (Tool, Function, Parameter bejegyzések) készít hozzá egy objektum-modellt, ami a leírtaknak megfelel, és lehetővé teszi a nyújtott szolgáltatás megismerését más eszközök számára futásidőben, vagy a leírások megjelenítését a felhasználó számára. A Tool Store ezeket a Sensoria Tool-hoz tartozó Tool objektumokat tartja nyilván, melyen keresztül a hívható függvények, és paramétereik feltérképezhetőek, illetve hozzáférhetünk a szolgáltatást nyújtó objektumhoz is, és azon hívást hajthatunk végre. A hívás - amennyiben az objektummodellen keresztül hívunk - szinkron módon történik ábra. A SENSORIA Development Environmentben a Sensoria Toolok leírására alkalmazott modell egyszerűsített osztálydiagramja A Blackboard működése A SENSORIA keretrendszer modelljének másik fontos eleme a Blackboard. Ez az a komponens, amely objektumok megosztását teszi lehetővé az eszközök, a Sensoria Toolok között. A Blackboard segítségével minden Sensoria Tool-hoz objektumok tárolhatók el, vagyis egy tárolási művelet kiadásakor meg kell adnunk a tárolást kérő Sensoria Tool objektumot is. Tárolás előtt az objektum egy burkoló objektumba kerül, amelyben rögzítésre kerül a tárolás dátuma, valamint a tárolást indító tool referenciája. A tárolás mellett lekérhetők a burkoló objektumok halmazai, illetve a burkoló objektumoktól megszabadított adatok halmazai egy adott Toolhoz, illetve objektumtípus alapján. A grafikus felhasználói felületen keresztül lehetőségünk van a Blackboardon található szöveget reprezentáló objektumokat (Stringeket) fájlba kimenteni. Tetszőleges objektum perzisztens tárolására nincs lehetőség, illetve az eredeti architektúrában felvázolt dokumentumkezelés is hiányzik. A Blackboardon 39

40 keresztül tehát legfeljebb az eszközök közötti kommunikáció valósítható meg. JavaScript alapú orkesztráció A JavaScript orkesztráció lehetővé teszi, hogy a JavaScript nyelv vezérlési elemeit felhasználva, bizonyos lekötött változókkal a SENSORIA rendszerhez hozzáférve egyszerű folyamatokat írjunk le. A konzolba történő közvetlen beírás mellett lehetőségünk van előre megírt, fájlban tárolt szkriptek futtatására is. A kód tényleges futtatását a Java 1.6-os verziójában helyet kapott Rhino Script Engine végzi. Ez az orkesztrációs mechanizmus a JavaScript nyelv korlátai miatt viszonylag egyszerű folyamatok definiálását teszi csak lehetővé. A JavaScript nyelvben a párhuzamos végrehajtás közvetlenül nem támogatott, nem lehet szálakat indítani. Sőt, mivel a JavaScript alapvetően interpretált nyelv, ezért az eszközök szolgáltatásainak hívásakor fellépő hibák (kivételek) kezelése nehézkes. A következő példakód két fordító szolgáltatás igénybevételét mutatja Sensoria szkriptből. A kódban az egyetlen magyarázatra szoruló elem az score változó, amely a kódban nincs definiálva. Ezt a változót a SENSORIA keretrendszer bocsájtja rendelkezésünkre, és a SensoriaCoreService azonosítójú Sensoria Tool-t reprezentálja. Ez egy olyan, a SENSORIA keretrendszerrel szállított Tool, amely a felhasználó számára hozzáférhetővé teszi a SENSORIA legalapvetőbb szolgáltatásait (a Tool Store-t és a Blackboardot). A Blackboardra történő írási műveletek ilyenkor mindig a SensoriaCoreService nevében történnek. 40

41 A SENSORIA rendszer grafikus felhasználói felülete A SENSORIA Development Environment felhasználói felülete négy fontos elemből áll. A Sensoria Browser a rendszerben elérhető Tool-ok megjelenítésére szolgál, kategóriákba rendezve (4.5. ábra) ábra. Sensoria Browser A Blackboard browseren látható a Blackboard tartalma, ahol minden egyes eszközhöz külön látszanak az általuk a Blackboardra írt objektumok (4.6. ábra) ábra. Sensoria Blackboard grafikus megjelenítése Szkriptek azonnali beírására, végrehajtására használható a Sensoria Shell (4.7. ábra). A Sensoria Browserben látható eszközökön duplán kattintva azok részletes leírása jelenik meg középen az Eclipse központi szerkesztő felületén (Tool Info, 4.8. ábra). Itt az egyes függvények nevére kattintva grafikus felületet kapunk, ahol a hívási paraméterek átadhatóak. A SENSORIA Development Environment használatának, illetve Sensoria Tool-ok fejlesztésének részletes leírását az interneten megtalálható SENSORIA Development Environment Tutorial [26] tartalmazza. 41

42 4.7. ábra. Sensoria Shell 4.8. ábra. Tool Info a SENSORIA Development Environmentben 42

43 4.2. Az IBM Jazz Platform Bevezető Az IBM Jazz Platform egy új, kifejezetten eszközintegrációt megcélzó technológia, melyre az IBM Rational Team Concert terméke is épül. A Jazz Platform 0.6 verziója, amellyel behatóan sikerült megismerkednem, a 3.2. alfejezetben vázolt architektúra elemeiből elsősorban az eszközök integrációjára, és adatok központi elérésére fektet hangsúlyt. Ebben az alfejezetben a Jazz Platform fontosabb szolgáltatásait mutatom be, kitérve a technikai részletekre is. Ehhez felhasználtam a Jazz Platform honlapján[12] található információkat, különös tekintettel a Jazz Platform technikai leírására [17] Architektúra A Jazz Platform kliens-szerver architektúrával rendelkezik, a két komponens közötti kommunikáció pedig web alapú technológiák segítségével, HTTP protokollon, SOAP üzeneteken keresztül valósul meg. A Jazz Platform vázlatos felépítését mutatja a 4.9. ábra. Az ábrán az is jól látszik, hogy a Jazz rendszerben jól elkülönülnek a nyújtott szolgáltatások interfészei a szolgáltatás implementációjától ábra. A Jazz Platform szolgáltatásainak elérése, forrás: [17] Szerver oldali architektúra A Jazz Platform a szerver oldalon lehetővé teszi Eclipse Equinox környezetben komponensek definiálását. A komponensek szolgáltatásokat (valójában szolgáltatási interfészeket) definiálhatnak, illetve deklarálhatják egy szolgáltatás megvalósítását. Új komponensek hozzáadásához, szolgáltatások, és megvalósításuk deklarálásához a rendszer az Eclipse extension point mechanizmusát használja fel. A szerver oldal szolgáltatásai igénybe vehetik egymás szolgáltatásait, de egymástól való függésüket explicit deklarálniuk kell. A deklarált szolgáltatások többféle típusúak lehetnek, melyek közül a három legfontosabb: 43

44 RAW_HTTP A szolgáltatás implementációja ilyen esetben közvetlen hozzáférést kap a HTTP kéréshez, és a HTTP válaszhoz, ami a Java Servlet-ek[14] működéséhez hasonló. A HTTP kérés különböző GET és POST paraméterei, valamint a kérés URL-je alapján készíti el a HTTP válasz tartalmát. Ez a legprimitívebb szolgáltatástípus. MODELED_REST Az ilyen típusúnak deklarált szolgáltatás úgynevezett RESTful web szolgáltatás lesz (REpresentational State Transfer, részletesen lásd: [29]). Ennek a koncepciónak a lényege, hogy az egyes nyújtott funkciók (Java metódusok) külön URI-n érhetőek el, és a HTTP kérés típusa (GET, POST, PUT, DELETE) elvben meghatározza a függvény működésének jellegét (létrehozás, olvasás, frissítés, törlés) feltéve hogy a fejlesztő ehhez tényleg tartja magát. A szolgáltatás függvényeihez ilyenkor automatikusan külön URI-n férhetünk hozzá, amennyiben betartjuk a Jazz függvénynév konvencióit. A függvények komplex adattípusokkal is visszatérhetnek, amennyiben ezek a típusok a alfejezetben leírtak szerint kerültek definiálásra. A visszatérés értéke ilyenkor az objektum SOAP üzenet formájában sorosítva. RPC A RESTful web szolgáltatáshoz hasonló működési mód, ekkor azonban a hívás bemenő paraméterei is lehetnek komplex adattípusok. A függvények ebben az esetben nem feltétlenül vannak külön URI-hez rendelve. A 3.2. alfejezet terminológiája szerint a szerver oldali szolgáltatások megfeleltethetőek a csatoló (Connector) elemeknek, melyek lehetővé teszik bármilyen platformon a különféle eszközökhöz való hozzáférést. A kliens oldalon a szerver szolgáltatások fölé építhetünk magasabb szintű funkcionalitást (például az adatok cache-elésével, grafikus megjelenítéssel, stb.). Kliens oldali architektúra A Jazz Platform a kliens oldali szolgáltatások megvalósítását alapvetően az Eclipse fejlesztői környezetben képzeli el, így a kliens oldalon könnyen alkothatunk magasszintű, grafikus felhasználói felületet. Fontos megjegyezni azonban, hogy nem feltétlenül szükséges Eclipse, vagy OSGi környezet ahhoz, hogy a szerver oldali szolgáltatásokat igénybe vegyük. A szerver oldali szolgáltatások, különös tekintettel a MODELED_REST típusúak könnyen elérhetőek tetszőleges programozási nyelvből, amelyhez létezik a HTTP-kommunikációt, illetve SOAP üzenetek felolvasását támogató függvénykönyvtár. Az Eclipse környezeten belül itt is egy extension point felel a bővíthetőségért, vagyis hogy kliens oldali szolgáltatásokkal dinamikusan bővíthető legyen a rendszer. 44

45 A Jazz Platform alapvető komponensei A Jazz Platformnak része kettő, a fenti módszerekkel definiált alapvető komponens, a Repository (adattároló), valamint a Team Process (egyfajta folyamattámogatás). Az adattároló lehetőséget biztosít a szolgáltatásoknak, hogy könnyen tudjanak perzisztensen adatokat tárolni, és a tárolt adatokra lekérdezéseket megfogalmazni. A tárolható adattípusok halmaza bővíthető ennek módszerét a alfejezet tárgyalja. A Team Process komponens a névhasonlóság ellenére koncepcionálisan nem azonos a már vázolt eszközintegrációs keretrendszer egyik folyamatokkal kapcsolatos komponensével sem. A Team Process komponens a szoftverfejlesztési folyamatot jeleníti meg a Jazz rendszerben. Ez a komponens már a tároló kompnensre építkezik, és fogalmi szinten bevezeti a szoftverfejlesztői csapat, és a szoftverfejlesztési projekt fogalmát. A szoftverfejlesztési projekteken belül lehetőség van meghatározni különböző fejlesztési vonalakat (development line), melyek például lehetnek egy szoftver fejlesztés alatt álló, illetve már csupán támogatott, tovább nem fejlesztett változata. Fel tudjuk venni egy-egy projekt mérföldköveit (Milestone), amelyek hagyományosan a projekt főbb állomásait jelölik. A Jazz Platform lehetőséget biztosít arra, hogy az egyes eszközök annak függvényében kicsit más működést produkáljanak, hogy éppen a folyamat melyik fázisában tartózkodunk, vagy a több fejlesztői csapat közül melyiknek vagyunk a tagjai A Repository komponens használata A Jazz rendszer Repository (adattároló) komponensének célja, hogy perzisztens adattárolást nyújtson a rendszerben lévő szolgáltatások számára. Az adattároló komponens alapja egy relációs adatbáziskezelő rendszer. A tárolót igénybe vevő szolgáltatások Java nyelven kerülnek elkészítésre, a Java nyelv pedig objektum-orientált, vagyis komplex adatstruktúrák objektumok (osztályok példányai) segítségével adhatóak meg. A relációs és objektum-orientált terminológia közötti megfeleltetést objektum-relációs leképzésnek hívják, és Repository komponens a Jazz rendszerben pontosan ezt a feladatot látja el. Ha a Jazz rendszerben a Repository komponens szolgáltatásait szeretnénk igénybe venni, akkor az EMF keretrendszer segítségével definiálhatunk olyan osztályokat, amelyeknek a példányait el szeretnénk tárolni. Az EMF keretrendszer bemutatása Az EMF (Eclipse Modeling Framework) egy modellezési keretrendszer, és kódgeneráló eszköz, amellyel eszközöket, illetve más alkalmazásokat építhetünk, amelyek struktúrált adatmodellre építkeznek [8]. Az EMF definiál egy modellezési nyelvet, melynek fogalmai az UML nyelv osztálydiagramjának elemeihez állnak közel. A modellezési nyelv legfontosabb elemeit egy osztálydiagramon szemlélteti a ábra. A nyelv használatakor alapvetően EClass-okat, vagyis osztály jellegű elemekt definiálunk, melynek 45

46 lehetnek ősei (esupertype). Az osztály tagváltozóit (eattributes), és referenciáit más osztályok példányaira (ereferences) is deklarálhatjuk. Az EAttribute és EReference elemek két egész szám értékű adattagja adja meg a hivatkozott elemek multiplicitását az alsó és felső korlát definiálásával ha a felső korlát -1, akkor korlátlan számú példányra hivatkozhatunk. Egy EReference megjelölheti, hogy melyik EReference példány adja a vele ellentétes relációt (eopposite). Egy EReference leírhat tartalmazási relációt (iscontainment adattag), ennek a jelentése például egy objektum sorosításnál érdekes: egy objektum által tartalmazott elemek mindig sorosításra kerülnek ha az objektumot sorosítjuk ábra. Az EMF modellezési nyelvének metamodellje. Az ábra az UML osztálydiagramjának formalizmusait használja. A modellezési nyelvhez rendelkezésünkre áll egy szerkesztőfelületet, amelynek segítségével modelleket állíthatunk össze. Ezt a szerkesztőfelületet mutatja a ábra. Az ábrán egy könyvtár modellje látható, a jobb oldalon pedig a Library nevű EClass books nevű EReference elemének részletes leírása látható. Ebből kiderül, hogy egy Library elemhez végtelen sok Book típusú elem tartozhat ábra. Az ecore modellek szerkesztésére kialakított felhasználói felület. Az ábrán egy könyvtár ecore modellje látható. Az ecore nyelv tehát az UML osztálydiagramokhoz hasonló kifejezőerőt képvisel. A nyelv segítségével leírt modellből lehetséges kódot, Java osztályhierarchiát generáltatni. A generált osztályokat 46

47 hagyományos módon használhatjuk, de az EMF számos extra szolgáltatást nyújt, például lehetőséget biztosít, hogy az osztályok példányaiból alkotott objektumhierarchiát XMI formátumba sorosítsuk. Ez különösen kedvező tulajdonság, ha a generált osztályhierarchiát egy speciális terület (domain) modellezésére, domain-specifikus modellezésre használjuk. Az ecore nyelvvel ilyenkor egy modell modelljét készítjük el, vagyis úgynevezett metamodellt alkotunk. Vegyük észre, hogy ábra képén is egy metamodell látható, méghozzá az ecore modell modellje, az UML szintaktikájával rajzolva. Saját adattípusok eltárolása: tárolási (storage) modellek létrehozása Ahhoz, hogy a Jazz adattárolójában új, magunk által definiált típusokat tudjunk eltárolni, úgynevezett tárolási (storage) modellt kell létrehoznunk. A tárolási modell nem más, mint egy hagyományos EMF ecore modell, ahol az általunk definiált EClass-ok Java osztályoknak feleltethetőek meg. Ahhoz, hogy a Jazz rendszerben használni tudjuk az osztályainkat, hozzá kell valamilyen módon kapcsolni a meglévő Jazz adattípusokhoz, és néhány egyéb konvenciót be kell tartani. A konvenciókat és a szükséges lépéseket ebben az alfejezetben mutatom be, a jazz.net wiki vonatkozó leírása [15] alapján. Az itt leírtak hangsúlyozottan a Jazz Platform 0.6-os változatára érvényesek. Egy EMF ecore modell elemeit úgy tudjuk a Jazz rendszerben tárolhatóvá tenni, hogy örökléssel származtatjuk a Jazz adattároló által erre a célra definiált három osztály valamelyikéből. Ehhez az EMF modellünkben egy külső ecore fájlra kell hivatkozni, amelyet a Jazz Repository komponens definiál. A három osztály, amiből az elemeinket származtathatjuk: SimpleItem egyszerű tárolható elem. Egy példányon végzett módosítások után a példány új állapotazonosítót (state ID) kap. Auditable a SimpleItem-hez hasonló elem, azonban a Jazz rendszerben a példány régebbi állapotai is elérhetőek, vagyis a rendszer egyfajta verziókezelést végez. Helper nem önálló elem, mindenképp egy SimpleItem vagy Auditable kell, hogy tartalmazza (EMF containment EReference). A tartalmazó elem törlésekor a Helper példány is törlésre kerül. A fentieken kívül úgy is tárolhatóvá tehetjük egy osztály példányait, ha az osztály nem közvetlenül, hanem indirekt módon származik a SimpleItem vagy az Auditable osztályból. Fontos megkötés, hogy az osztályok között a Jazz tárolási modellben nem lehet többszörös öröklés. Arra is ügyelni szükséges, hogy az egyes osztályok EReference mentén csak akkor jelöljenek tartalmazást, ha a refereált elem Helper típusú. A Jazz adattárolóban az attribútumok és referenciák multiplicitásának (lowerbound és upperbound értékek) csak egy része tekinthető érvényesnek. A megengedett multiplicitásokat a 4.1 táblázat tartalmazza. 47

48 EReference lowerbound upperbound EAttribute lowerbound upperbound (b) (a) 4.1. táblázat. Megengedett multiplicitások (a) EReference és (b) EAttribute esetén A táblázatból látható, hogy a Jazz adattároló nem támogatja, hogy egy attribútumból több is tartozzon egy osztály példányához. Ezt a megkötést úgy lehet áthidalni, hogy Helper referenciát adunk meg, amiből már lehetséges több példányt megadni az osztály definíciójánál. Megkötések vonatkoznak az osztályok attribútumainak típusaira. Az alábbi lista a megengedett attribútumtípusokat sorolja fel. Az EMF beépített adattípusai közül megengedett: EBigDecimal EDate EInt EBoolean EInt ELong EString (korlátos méretű szöveg, részletesen lásd lejjebb) A Jazz Repository által definiált primitív típusok közül megengedett: UUID (a Repositoryban használt egyedi azonosító) Timestamp (a java.sql.timestamp típust modellezi) Szöveges információ tárolására relációs adatbáziskezelőkben általában legalább kétféle módon lehetséges: méretkorlátos, vagy dinamikusan változó méretű szövegként. Az EString típusú attribútumok méretkorlátos szövegként tárolódnak az adatbázisban. Hogy pontosan milyen méretkorláttal, azt a tárolási modellben az attribútumhoz fűzött annotációk (EAnnotation) segítségével adhatjuk meg (4.12. ábra). A Jazz Repository háromféle fix méretet támogat (SMALL, MEDIUM, LARGE). 48

49 4.12. ábra. String méretkorlátjának megadása annotáció segítségével A tárolási modellben további annotációkat használva úgynevezett query model -t, avagy lekérdezési modellt is tudunk generáltatni. A lekérdezési modell segítségével Java-ban programozottan tudunk lekérdezéseket megfogalmazni, melyek feldolgozásához a Jazz rendszerben elérhető az IQueryService. Egy attribútumhoz a queryableproperty annotációt hozzáadva kerül bele a lekérdezési modellbe, vagyis ezután adhatunk meg rá keresési feltételt. Változó méretű szövegek eltárolására is biztosít lehetőséget a Jazz adattárolója. Ehhez egy Content típusú EReference-et kell felvenni az osztály tagváltozói közé méghozzá tartalmazást jelképezőt. A Content típust a Jazz Repository EMF modellje definiálja. Java osztálydefiníciók és adatbázistáblák generálása a tárolási modellből A tárolási ecore modellből a Jazz Code generation tool segítségével tudunk osztálydefiníciókat generálni (letölthető a jazz.net wikiről [16]). A kódgenerálás eredménye egy Eclipse plugin, melyben az osztályok különböző Java csomagokba kerülnek. A bundle neve, és a csomag, amelybe az osztályokat generáljuk, az ecore modellben annotációk segítségével adható meg. A szükséges annotációkat mutatja a ábra. Az ábrán látható konfiguráció a com.example.jazzbot.common.test nevű Eclipse plugin src könyvtárába generálja az alatta levő csomag tartalmát. A jazzbot EPackage-ben lévő osztályok pedig a com.example.common.internal.model Java csomagba képződnek le ábra. Szükséges annotációk a tárolási modell osztályainak generálásához Ahhoz, hogy az osztályaink példányait perzisztálni is tudjuk, még szükséges, hogy az adatok tárolásához szükséges adatbázistáblákat létrehozzuk a megfelelő adatbáziskezelőben. Ennek több módja is 49

50 van, attól függően, hogy egy futó Jazz szerveren, vagy csupán fejlesztési célra szeretnénk, a fejlesztői környezetünkben futó Jazz szerveren szeretnénk az adatbázist elérni. Mivel ez a generálási lépés a Jazz Repository lényegi működése szempontjából irreleváns, ezért itt nem kerül bemutatásra. A témával részletesen foglalkozik a jazz.net vonatkozó wiki oldala [11]. A tárolási modell típusainak programozott használata A tárolási modell típusainak használatakor három érdekes kérdés merül fel: hogyan tároljunk egy új objektumot az adatbázisban, hogyan kérünk le meglévő adatokat, illetve a módosított adatok mentése hogyan történik. Új objektumok létrehozása az EMF által generált osztályok felhasználásval történik, egyszerű konstruktorhívással, vagy a factory tervezési minta felhasználásával, azonban az adatbázisban történő tároláshoz először egy munkapéldányt (working copy) kell kérnünk az objektumból a getworkingcopy metódus meghívásával. Ezt a metódust az öröklési hierarchia mentén az IItem interfésztől öröklik az önálló osztályok (SimpleItem és Auditable). Az elemek tárolását és törlését egy Jazz szolgáltatás, az IRepositoryItemService segítségével végezhetjük el. A szolgáltatás programozói felületét a ábra mutatja. Új objektum tárolásához, vagy módosított objektum elmentéséhez a saveitemintxn függvényt szükséges meghívni, paraméterül adva az elmentendő IItem referenciáját. Az objektumok módosítása hasonló módon, az objektumból munkapéldány kérésével, majd annak mentésével történik ábra. A perzisztenciát biztosító Jazz szolgáltatás programozói interfészének részlete Már létező objektumok módosításánál lényeges kérdés, hogy több kliens, azaz több szálról történő módosítás esetén hogyan reagál a rendszer, illetve az adatok konzisztens állapotban tartásáért hogyan felel. A Jazz rendszerben lehetőségünk van tranzakciók definiálására és futtatására. Ha egy tranzakció valamilyen hiba folytán mégsem futna le, arról kivétel dobásával (Java Exception) küld jelzést. Ennek megfelelően a saveitemintxn függvény sem közvetlenül írja az adatbázist, változtatásai csak a tranzakció commitálása után lesznek láthatóak a többi, adatbázist író/olvasó tranzakció számára. A programozói felületen magyarázatra szorul még az IItemHandle interfész. Ez az interfész egyfajta mutató egy, az adatbázisban fellelhető IItem példányra, mint azt a fetchitem függvény sejteni engedi. Az IItemHandle pusztán a konkrét objektum eléréséhez szükséges információt tartalmazza (itemid és stateid), vagyis az objektum addattagjainak és referenciáinak értékét nem. A korábban em- 50

51 lített IQueryService lekérdezőszolgáltatás segítségével ilyen IItemHandle példányokra szerezhetünk referenciát. Az IItemHandle referenciák teljes állapotát az IRepositoryItemService szolgáltatás fetchitem függvényével tudjuk lekérni A Jazz Repository hasznosítása dokumentumkezelőként A Jazz Repository dokumentumkezelőként történő hasznosításának vázlatát mutatja a ábra. Az ábra bal oldalán a 3.2. ábra folyamatmodelljének egy lehetséges változata látható. Ebben a Task -ok különféle, eszközök által elvégzendő feladatokat jelölnek, és a Task -ok között fekete nyíllal jelölve látható a vezérlés áramlás. Az ábra bal alsó részén láthatóak a Jazz tárolási modelljének megfelelő konstrukció, amelynek segítségével dokumentumtípusokat tudunk definiálni. A Task ki- és bemenő adatait a dokumentumtípusok segítségével tipizálhatjuk. A dokumentumtípusok között relációkat tudunk megadni mint például tartalmazás, referencia vagy öröklődés. A dokumentumtípusok a Jazz tárolási modelljében lévő osztályoknak (EClass-oknak) felelnek meg. Egy osztály attribútumai a dokumentum metaadatait írják le (például verziószám, módosítás ideje stb.). A folyamat egy példányában, amely az ábra jobb oldalán látható, ezen dokumentumtípusok példányai jelennek meg. A dokumentumok metaadatait a Jazz Repository segítségével tudjuk elérni, a dokumentum szöveges, vagy bináris formátumú tartalmát szintén elérhetjük a Jazz Repositoryból, Content típusú referencia deklarálásával. A folyamat futásakor ezeket a dokumentumpéldányokat adjuk át az egyes konkrét eszközöknek ( Activity ), illetve az eszközöknek lehetőségük van dokumentumok létrehozására és tárolására is egy Jazz szolgáltatáson keresztül. Az ábrán láthatónak megfelelő dokumentumkezelő rendszert elkészítettem a DIANA folyamat allokációs lépéséhez. Ezt a rendszert a későbbiekben részletesen bemutatom az 6.5. alfejezetben ábra. A Jazz Repository felhasználása dokumentumkezelésre 51

52 5. fejezet Implementációs eredmények 5.1. A rendszer kiegészítéseinek ismertetése A SENSORIA rendszer hiányosságai A SENSORIA Development Environment lehetőséget biztosít egy számítógépen eszközök integrált elérésére, azonban vannak bizonyos hiányosságai, ha nagyvállalati felhasználhatóság szempontjából vizsgáljuk. Egyrészt a JavaScript nem kellően kifinomult és magas szintű nyelv az eszközökből kialakított folyamatok definiálására. Alapvető nyelvi elemek hiányoznak például a párhuzamos végrehajtás kifejezésére. A SENSORIA-ban található konzolos, forráskód alapú folyamatkészítés, és tervezés bonyolultabb folyamatok esetén kényelmetlen, és akkor sem állja meg a helyét, ha olyan ember szeretné használni, aki a rendszer technikai részleteivel kevésbé van tisztában, vagy programozási ismeretei egyáltalán nincsenek. A 3.2. alfejezetben vázolt architektúrához képest a SENSORIA rendszerből teljes mértékben hiányzik a dokumentum fogalma, és a dokumentumkezelés támogatása. Bár a Blackboard dokumentumok megosztására alkalmas, erős korlátozás, hogy nem nyújt lehetőséget perzisztens adattárolásra. Verziókezelésnek, vagy hozzáférési jogok kezelésének támogatásának, amelyek dokumentumok kezelésénél felmerülő kérdések, nyoma sincsen a SENSORIA rendszerben. Dokumentumkezelés elvégzésére általában egy központi elemet használnak egy üzleti folyamat résztvevői. Egy ilyen rendszer iránti igény szükségessé teszi általánosságban egy szolgáltatás hálózaton keresztül történő megosztásának megoldását. A dokumentumkezelő szolgáltatás megosztására kidolgozhatunk egy speciális SENSORIA Tool-t, ami a dokumentumkezelő rendszert valamilyen általa támogatott protokollon, célszerűen Java programozói felületen keresztül éri el. Ígéretes lehetőség egy olyan megközelítés, ahol ezt a SENSORIA Tool-t hálózaton keresztül elérhetővé tudjuk tenni más SENSORIA felhasználók számára, hiszen így egyetlen gép nyújtja ezt a szolgáltatást, a többi csak használja. Egy, a SENSORIA szolgáltatások megosztását, és távoli eljárások hívást biztosító, a felhasználó 52

53 számára átlátszó köztes réteg kidolgozása azért is előnyös, mert a rendszer orkesztrációs képességeit kihasználva számos új lehetőségünk nyílik. Például erőforrás-igényes feladatok végrehajtását más, erősebb számítógépen végeztethetjük el, vagy egy gépről több, másik gépen elérhető szolgáltatást megszólítva terheléselosztást tudunk végezni. Egy másik alkalmazási lehetőség, hogy egy központi gépre egy folyamatvégrehajtó rendszert telepítünk, és számára biztosítjuk a különböző fejlesztői gépeken található eszközök elérését, így egy (szoftverfejlesztési) folyamat végrehajtása során az egyes lépéseket különböző fejlesztőknek tudjuk delegálni. A SENSORIA Development Environment rendszer architektúráját a fentieknek megfelelően két fő elemmel egészítettem ki. Elsőként elkészítettem egy olyan modult, amely lehetővé teszi a SENSORIA Tool-ok távolról történő elérését, és azok metódusainak meghívását. A második kiegészítés a SEN- SORIA rendszer munkafolyamat végrehajtásához, és tervezéséhez nyújtott támogatást javítandó, egy munkafolyamat-végrehajtó motort illesztettem a keretrendszerhez. Ezeket a kiegészítéseket ebben a fejezetben ismertetem. A fenti, architekturális bővítéseken kívül elkészítettem egy, a DIANA folyamat egyik lépéséhez használható, dokumentumkezelésre alkalmas SENSORIA Tool-t, melynek felépítését a alfejezet tárgyalja Távoli elérés (remoting) előkészületek A távoli eljáráshívás megvalósítására több alternatív technológia létezik Java környezetben. Mivel a teljes keretrendszer Java nyelven íródott, kézenfekvőnek tűnik a Java RMI (Remote Method Invocation) használata a feladat megoldására. Ez a technológia azonban teljesítményét tekintve jelentős, hátrányban van más technológiákkal szemben, amelyet mérések is igazolnak (lásd: [13]). Az RMI technológia nem használja ki az OSGi keretrendszer adottságait sem. Egy másik alternatívaként web szolgáltatásokat (Web Services) használhatnánk a távoli objektumok eljárásainak meghívására. A legalkalmasabbnak vélt technológia a remoting megvalósítására az R-OSGi (Remoting-OSGi [28]). A Java RMI-hez képest, kisebb méretű függvényparaméterek esetén, jobb teljesítményt nyújt a hálózati kommunikáció során, és a web szolgáltatásoknál jóval egyszerűbben illeszkedik a használt OSGi környezetbe, mivel maga az R-OSGi is egy OSGi bundle, illetve azért, mert az R-OSGi technológia fejlesztésének kifejezett célja, hogy OSGi szolgáltatások megosztását tegye lehetővé OSGi-alapú rendszerek között. Szintén e mellett a technológia mellett szól, hogy többféle szolgáltatás-felfedező mechanizmust is képes használni. A kliens-szerver stílusú, direkt kapcsolódás, és szolgáltatás-elérés mellett az SLP (Service Locatio Protocol) [6] protokollnak megfelelően multicast-alapú decentralizált, vagy központ által vezérelt szolgáltatás felfedezést (discovery) is támogat. Ilyen irányú kiterjesztés céljából a jslp könyvtár használata javasolt, amely az SLP protokoll használatát teszi lehetővé Java nyelven. 53

54 A munkafolyamat-végrehajtó környezet kiválasztása A munkafolyamat-végrehajtást vezénylő motor kiválasztása szorosan összefügg a munkafolyamat-leíró nyelv kiválasztásával. Web szolgáltatások orkesztrálására, munkafolyamatba szervezésére széles körben elterjedt a WS-BPEL (Web Services Business Process Execution Language) nyelv. Ez egy XML-alapú nyelv, amelyhez több grafikus szerkesztő is létezik (lásd az [25] és [7] weboldalakat), amelyek hatékonyan segítik a folyamatok magasszintű tervezését. Sajnos a BPEL munkafolyamatokat végrehajtó motor működtetéséhez többnyire Java alkalmazásszerverre van szükség, amelynek alkalmazását szeretnénk elkerülni. A BPEL nyelv használatához egy web szolgáltatás létrehozása elegendő lenne, amelyen keresztül elérhetőek a SENSORIA Toolok. Web szolgáltatások használata OSGi környezetben előző fejezetben már említett nehézségeket, és kisebb hatékonyságot vonhat maga után. A BPEL azonban az iparban széles körben alkalmazott technológia folyamatok szervezésére, ezért ha lehetséges törekednünk kell a támogatására. A munkafolyamat-végrehajtó környezetként végül a JBoss jbpm motor [33] mellett döntöttem. A jbpm egy Java nyelven írt munkafolyamat-végrehajtó motor, ami nemcsak Java alkalmazásszerverben, hanem standard (alap) Java környezetben is képes futni. Ez az alkalmazásszervert igénylő megoldásokhoz képest jelentős költségcsökkenést jelent. A jbpm a folyamatleírónyelvtől független, a BPEL-t is támogatja, de első számú célja a JBoss által fejlesztett jpdl (JBoss Process Definition Language) nyelven írt folyamatok végrehajtása. Ez az XML-alapú folyamatleíró nyelv rendkívül rugalmas, és sok teret enged a kiegészítéseknek, ami az integrációját rendkívül megkönnyíti. A munkafolyamathoz Java nyelven tehetjük hozzá saját kiegészítéseinket, sőt a jpdl nyelvet kiegészíthetjük: új munkafolyamat elemeket is szabadon definiálhatunk. A jpdl nyelven írt folyamatok készítéséhez rendelkezésünkre áll egy Eclipse alapú szerkesztőfelület Áttekintés: a bővített rendszer felépítése Elsőként a remoting implementációt készítettem el. A szolgáltatások megosztásához szükséges funkcionalitást egy SENSORIA Toolban valósítottam meg. A távoli tool-ok használatához a kliens oldalon apró modell-kiegészítésre volt szükség. A munkafolyamat-végrehajtó motor illesztése úgy történt, hogy a munkafolyamat-végrehajtó JAR programból először Eclipse plugint készítettem, majd ebben a megosztani kívánt szolgáltatásokat egy SENSORIA Toolban elérhetővé tettem a keretrendszer számára is. A jbpm motor keretrendszerbe történő illesztésekor elkészítettem egy SensoriaActionHandler nevű osztályt, amely a jpdl-ben leírt folyamatokban lehetővé teszi SENSORIA Tool hívások definiálását. Az 5.1. ábra a kibővített SENSORIA keretrendszer egy alkalmazási lehetőségét mutatja be. Az ábra 54

55 felső részén található egy szerverként funkcionáló SENSORIA rendszer, amelyben elérhető mind egy dokumentumkezelést biztosító (Content Repository Tool), mind a munkafolyamat-végrehajtást biztosító (jbpm Executor Tool) SENSORIA Tool. Látható, hogy a A Content Repository Tool a Content Repository adattárolóval kommunikál, a jbpm Executor Tool pedig (a SensoriaActionHandler közvetítésével) a SENSORIA rendszer összes többi Tool-ját képes meghívni. Az ábra alsó részén kliensként működő SENSORIA rendszerek láthatóak, amelyek a remoting köztes réteg segítségével hálózaton keresztül érik el a dokumentumkezelőt és a munkafolyamat-végrehajtó SENSORIA Tool-t, így képesek közös dokumentumtárba dolgozni, és folyamatdefiníciókat végrehajtani. A kliens SENSORIA példányokban tehát a felhasználóknak, és az ott definiált más Tool-oknak lehetősége van a központi SENSORIA példányon elérhető Toolok használatára. A példában a kliens példányokat a gyakorlatban fejlesztők munkaállomásaival, és azon futó Eclipse példánnyal tudjuk helyettesíteni, a közösen használt szerver pedig akár grafikus felhasználói felülettel nem rendelkező Eclipse példányt is futtathat ábra. A kibővített SENSORIA keretrendszer egy alkalmazási lehetősége 55

56 5.2. Remoting implementáció Előkészületek A távoli SENSORIA Tool-ok elérése három probléma megoldását igényli: először a SENSORIA keretrendszer alkalmassá tételét arra, hogy az aktuális gépen lévő egyetlen SENSORIA Core-tól különböző Core-okat is képes legyen kezelni. Másodsorban a feladat fontos eleme, hogy a SENSORIA Tool-ok attól függetlenül tudjanak megjelenni a lokális gépen a felhasználói felületen és a modellben, hogy távoli, vagy lokális Core-on át érjük el. Harmadrészt pedig meg kell oldani, hogy az egyes komponensek, és a SENSORIA Toolok függvényhívásai ténylegesen tudjanak utazni a hálózaton, valamilyen kommunikációs protokoll segítségével. Core modell kiegészítése Ahhoz, hogy a SENSORIA rendszert alkalmassá tegyük távoli SENSORIA Core-ok elérésre, először lehetővé kell tenni, hogy egy rendszerben több SENSORIA Core is elérhető legyen. A kompatibilitás megőrzése érdekében a régi SENSORIA Core-t reprezentáló osztályt meghagyva bevezettem egy új fogalmat, a SENSORIA Core Registry-t, amely több SENSORIA Core elérésére képes (5.2. ábra). A Core objektumhoz egy egyedi String azonosítót kell rendelni, hogy egyértelműen azonosítható legyen. Ennek a bővítésnek az implementációja során el meg kellett szüntetni a SENSORIA Core, és tartalmazott elemei, a Blackboard és a Tool Store egyedi (singleton) mivoltát. A változások a grafikus felületet is érintették, hiszen alkalmassá kellett tenni a SENSORIA Tool Browsert, és a Blackboard Viewert is, hogy több Core-hoz tartozó Tool Store, illetve Blackboard tartalmát megjelenítsék. Távoli hívás objektum modellje A következő lépés a távoli SENSORIA Tool-okat leíró objektummodellek átvitelének biztosítása volt. Ehhez egy szerializálható, azaz hálózaton átvihető, vagy akár fájlba kiírható variánst kell készíteni az egyes modell-elemekből. A Java programozási nyelvben ez részben rendkívül egyszerű, hiszen elegendő az osztályoknak a Serializable marker interfészt implementálni, valamint minden referált tagváltozónak primitívnek vagy szerializálhatónak kell lennie. A SENSORIA rendszer modellje a futásidőben szükségszerű reflektív hívások miatt biztosan nem szerializálhatóak pusztán a fenti interfész implementálásától. Ezért szükségszerű volt egy szerializálható modellvariáns megalkotása. A munkát nehezítette, hogy nem álltak rendelkezésre ősinterfészek a Toolokat leíró modellben, ezeket külön létre kellett hoznom, hogy a rendszer többi komponense függetlenül tudja kezelni a lokális és a távoli implementációt. A teljesen szerializálható Tool modell megalkotásához azonban szükség van a függvényhívás mikéntjének 56

57 5.2. ábra. SENSORIA rendszer bővítése elosztott integrációhoz ismerete, hiszen ez az egyetlen nem szerializálható rész a lokális Tool modellben. A vezérlés, és a Toolokat leíró objektumok hálózati átvitelére az R-OSGi technológiát használtam fel. Az R-OSGi egy olyan OSGi bundle, amelynek segítségével OSGi szolgáltatások oszthatóak meg akár különböző, hálózatba kötött rendszerek között. Az R-OSGi másik nagy előnye a platformegyezés mellett, hogy mivel beágyazott, erőforrásszegény rendszerekben történő alkalmazásra tervezték, ezért hatékony kommunikációt biztosít, kevés sávszélességet használ. Az R-OSGi rendszert a következő fejezetben ismertetem. A távoli hívások pontos módszerének ismeretében tehát megalkotható a pontos távoli Toolokat leíró szerializálható modell. A Blackboard esetén egy kicsit egyszerűbb a helyzet, itt ugyanis a Blackboardon kívül néhány burkoló objektum szerializálása szükséges, ezt könnyedén kezelhetjük a Serializable interfész implementálásával ezekben a komponensekben. A Blackboardra azonban tetszőleges objektum kiírható, és ezek nem mindegyike szerializálható. A Blackboard elemei közül tehát csak a szerializálhatóakkal foglalkozunk a távoli elérés 57

58 során Az R-OSGi ismertetése Az R-OSGi (Remoting-OSGi) könyvtár egy OSGi bundle, amely lehetővé teszi szolgáltatások megosztását OSGi rendszerek között. A szolgáltatás regisztrálása az OSGi szolgáltatások regisztrálási folyamatába illik, a szolgáltatás elkérése pedig szintaktikailag rendkívül hasonló az OSGi rendszerben használatos szolgáltatások kezelésével. A távoli szolgáltatáson történő hívások paramétereinek és visszatérési értékének értelemszerűen szerializálhatónak kell lennie. Alapvető működés Az R-OSGi rendszer működését két részletben érdemes megismerni: a szolgáltatás nyújtó, és a szolgáltatást lekérő oldalról. Szolgáltatások definiálása az OSGi környezetben megszokott módon történik. A központi szolgáltatások regisztrációjához csakúgy, mint a szolgáltatáslekéréshez, a BundleContext objektum használatos OSGi környezetben. Ennek egy példányát minden BundleActivator osztály megkapja a bundle indításkor a start metódusának paramétereként. A többi osztály célszerűen a BundleActivator implementációnktól kaphat referenciát erre a BundleContext objektumra. Szolgáltatást regisztrálni az 5.3. ábra alján szereplő registerservice függvénnyel lehet, amelynek szüksége van egy olyan interfész nevére, amelyet a második paraméterül adott objektum implementál. A hívás utolsó paramétereként egy Java Dictionary vagy Hashtable adható át, amelyben különböző extra paramétereket adhatunk meg. Ezeket később mi magunk, vagy más alkalmazások lekérhetnek. Az ábra tanúsága szerint az R-OSGi szolgáltatás pontosan ezt teszi: miután az OSGi keretrendszer bejegyezte a szolgáltatásunkat, eseményt küld szét a rendszerben, közölve hogy új szolgáltatás lett elérhető. Erre az eseményre az R-OSGi bundle egyik osztálya is fel van iratkozva, és az extra paraméterek között a RemoteOSGiService.R_OSGi_Registration értékét kiolvasva dönti el, hogy elérhetővé kell-e tennie távoli kérések esetére. Szolgáltatások lekérési mechanizmusát R-OSGi használatával az 5.4. ábra és az 5.5. ábra szekvencia diagramjai szemléltetik. A távoli szolgáltatások lekéréséhez első lépéseként csatlakoznunk kell egy olyan OSGi rendszerhez, ahol egy R-OSGi szolgáltatás figyel, és szolgáltatásokat oszt meg. Ehhez a RemoteOSGiService interfészt megvalósító OSGi szolgáltatás a kulcs, amelyet az OSGi rendszerekben szokásos módon érünk el. A tanúsága szerint először a BundleContext objektumhoz fordulva elkérjük a RemoteOSGiService interfészt megvalósító szolgáltatás referenciáját. A híváskor átadott String nem más, mint egy Java interfész neve, amit a keresett szolgáltatásnak implementálnia kell (a konkrét esetben ez a RemoteOSGi.class.getName() függvénnyel írható le). A ServiceReference objektumhoz tartozó 58

59 5.3. ábra. OSGi szolgáltatás regisztrálása, R-OSGi regisztrációt kérve valódi szolgáltatást, a megadott interfészt megvalósító objektumot a getservice hívással kapjuk meg. A hívás után a kapott objektumot a megfelelő interfészre kasztolva férünk hozzá a RemoteOSGiService szolgáltatás funkcióihoz. Miután referenciánk van az R-OSGi központi szolgáltatására, kapcsolódást kezdeményezhetünk olyan OSGi rendszerekhez, amelyeken az R-OSGi már fut. Erre szolgál a connect(uri) függvény, amely egy, a gépet azonosító címet vár, amellyel az R-OSGi protokollon tud kommunikálni, például: r-osgi:// :9278. Ahogy az a példából sejthető, az R-OSGi szolgáltatás alapbeállításon a 9278-as porton figyel. Az R-OSGi szolgáltatás indítása az R-OSGi bundle indításakor történik meg. Miután a fenti módon kapcsolódtunk egy távoli OSGi rendszerhez, el tudjuk érni az ott távoli elérésre a korábban leírt módon regisztrált szolgáltatásokat. A távoli szolgáltatás elkérését az 5.5. ábra illusztrálja. Az első két hívásnál a hívások szintakszisa hasonló az OSGi szolgáltatások lekérésekor használthoz, azzal a különbséggel, hogy itt meg kell adnunk a célállomás URI azonosítóját (azonos a csatlakozáskor használttal), illetve megadhatunk egy szűrő kifejezést az eredmények szűkítésére. Az eredmény szolgáltatás referenciák tömbje, amelyből egyet kiválasztva, és a getremoteservice függvénynek paraméterül adva elérhetjük a kívánt szolgáltatást. A szolgáltatás referencia, illetve maga szolgáltatás lekérése is kommunikációt indít a szerver oldalon figyelő R-OSGi szolgáltatással. A szolgáltatások tényleges lekérésekor a szerver oldal egy bundle-t generál, ami a szolgáltatás által implementált interfésznek szintén megfelelő osztályt tartalmaz, ám annak 59

60 5.4. ábra. R-OSGi szolgáltatás elkérése az OSGi keretrendszertől metódustörzseiben hálózati kommunikációt megvalósító műveleteket találunk. A kliens oldalon utána ez a bundle kerül telepítésre, és a generált osztályt használjuk a távoli szolgáltatás elérésére. A proxy bundleba belekerülnek mindazon csomagok, amelyek az eredeti szolgáltatást regisztráló bundle-ben exportálva voltak, a manifeszt fájl import fejléce pedig átkerül a proxy bundle-ba, változások nélkül. Érdemes még megemlíteni, hogy az R-OSGi lehetőséget biztosít arra, hogy a proxy bundle-ben létrehozott, a kliens oldalon megjelenő osztályt testre szabjuk. Ehhez a szolgáltatás definiálásakor átadott Hashtable-ben egy absztrakt osztály nevét kell átadnunk, amely megfelel a szolgáltatás interfészének. Az R-OSGi a proxy osztály generálásakor a meglévő függvényeket a megadott osztályból bemásolja az proxy osztályba, a maradékot pedig a kommunikációs csatornán átmenő hívásokkal helyettesíti. Így lehetővé válik, hogy pontosan leírjuk, hogy a kliens oldalon milyen kód hajtódik végre Az R-OSGi felhasználása az implementációban Az R-OSGi tehát alkalmas OSGi szolgáltatások megosztására OSGi rendszerek között. Így a távoli szolgáltatások meghívását viszonylag egyszerűen meg tudjuk oldani: minden SENSORIA Toolhoz egy OSGi szolgáltatást kell készítenünk a szerver oldalon, és ezeket elérhetővé kell tenni az R-OSGi segítségével. Ezzel az ötlettel az egyetlen probléma, hogy az OSGi szolgáltatásoknak kötelező interfésznevet megadni a regisztrációkor, ám a SENSORIA Tool-oknak nem. Ennek az interfésznek a megadása a jövőben egy- 60

61 5.5. ábra. Távoli OSGi szolgáltatás elkérése R-OSGi segítségével szerű, és célszerű bővítése lehet a SENSORIA modelljének, és a SENSORIA Tool extension pointnak, a kész implementációban reflektív Java hívásokat alkalmaztam az eszközhöz tartozó interfész megállapítására. Ennek a technikának az alkalmazásával egyértelművé válik, hogy hogyan kell felépülnie a szerializálható modell variáns távoli eljárást hívó részének: tárolnunk kell a távoli OSGi URI azonosítóját, és meg kell tudnunk mondani a SENSORIA Tool-hoz tartozó interfészt a hívást kezdeményező osztályban. Ezek alapján ugyanis elkérhető a távoli szolgáltatás, és a települő proxy bundleból származó proxy objektumon végezhetjük a hívást. Egy távoli szolgáltatás metódusának meghívásakor lejátszódó szekvenciát láthatunk az 5.6. ábrán. RPC A következő megoldandó problémát a távoli SENSORIA Core elérése jelenti. Ez közvetlenül a SEN- SORIA Core OSGi szolgáltatássá alakításával nem oldható meg, hiszen sem a rajta keresztül elérhető Blackboard, sem a Tool Store nem szerializálható biztosan. A helyzet megoldására létrehoztam három új osztályt, RemoteCore, RemoteToolStore, illetve RemoteBoard néven, amelyek távoli Core, Tool Store és Blackboard objektumokat jelölnek, és szerializálhatóak. Ezek alapján, ha egy rendszeren engedélyezzük a Tool-ok távoli elérését, akkor egyszerűen egy másolatot készítünk a Tool Store-ról és a Blackboard szerializálható elemeiről, és ezeket a Remote Tool Store és Remote Blackboard osztályokból tesszük elérhetővé. A Tool Store és a Blackboard modell elemeit a korábban leírt szerializálható modell variáns osztályaiból alakítjuk ki. Ezzel a megoldással biztosan megvalósítható a fent említett távoli eljáráshívási koncepció, hiszen a szerver a saját URI azonosítóját ismeri, a szolgáltatás interfészét pedig a Tool 61

62 5.6. ábra. Távoli eljárás hívásának vázlatos szekvenciája Store másolásakor kideríti. Ezek után a Remote SENSORIA Core-t OSGi szolgáltatásként már bátran megoszthatjuk távoli elérésre. Ahhoz, hogy a rendszerünkhöz a grafikus felhasználói felületet illeszteni tudjuk, néhány további finomításra van szükség. A SENSORIA rendszerben a Blackboard, illetve a SENSORIA Tool-ok listáját megjelenítő fa nézet alapvetően a modell objektumok változásaikor (Tool Store, Blackboard) értesítést kapó Listener osztályok segítségével frissül. Vegyük észre, hogy mivel csak a Remote SENSORIA Core-hoz férünk hozzá távoli szolgáltatásként, ezért sem a Remote Blackboardra, sem a Remote Tool Store-ra nem rakhatunk Listener objektumokat. Ennek oka az, hogy a Remote Core függvényein keresztül érjük el a távoli Tool Storet és Blackboardot, és az R-OSGi működésének következtében ilyenkor a távoli szerveren lévő objektumok szerializált másait kapjuk. A kliens oldalon tehát szükségünk van egy olyan objektumra, amely a távoli Blackboardot jelképezi. Ezt a problémát is megoldhatjuk az R-OSGi segítségével úgy, hogy a Remote Blackboard, és Remote Tool Store objektumainkat is távolról elérhetővé tesszük a segítségével. Ez önmagában még kevés, hiszen a Remote SENSORIA Core-t reprezentáló proxy osztály még mindig a szerializált példányokat adná vissza. Ezért igénybe kell vennünk az R-OSGi azon képességét, amellyel a proxy osztályba saját kódot injektálhatunk, ezzel egy okos proxy -t (smart proxy) hozva létre. Esetünkben a Tool Storet és a Blackboardot elérő függvényeket úgy kell felüldefiniálni, hogy azokban a Tool Store illetve Blackbo- 62

63 ard interfészeinek megfelelő R-OSGi szolgáltatások lekérései legyenek. Ezek a szolgáltatás-lekérések a komponenseknek megfelelő proxy bundle-öket telepítenek, és a kliens számára minden lekérésnél ugyanaz a proxy objektum fog látszani. Távoli eseménykezelés Most azonban egy másik problémával találjuk szembe magunkat, nevezetesen hogy a Listener objektumaink, amiket meg akarunk hívatni változások esetén, átkerülnek a szerver oldalra, hiszen a hozzáadás is távoli eljáráshívást jelent. Ezért még egy apró trükköt kell bevetnünk: a Remote Blackboard és Tool Store proxy objektumait is ki kell egészítenünk a smart proxy mechanizmus segítségével, hogy a Listenerek kezelése (hozzáadás, eltávolítás) a kliens oldalon valósuljon meg. Ahhoz, hogy a Listener osztályaink függvényei valamilyen esemény bekövetkezésekor tényleg meg is hívódjanak, valahogyan a szerver oldalról át kell tudnunk juttatni az eseményeket a kliens oldalra. A távoli elérésre szánt Tool Store és Blackboard a szerver oldalon minden alkalommal frissül, ha az eredetijük frissül, amennyiben nem felejtettünk el Listener függvényeket adni a szerver oldal lokális Tool Store és Blackboard objektumaihoz. Ezeket az eseményeket kellene propagálni valahogy a kliens felé. Szerencsénkre az R-OSGi erre is nyújt támogatást. Az OSGi Platform Release 4 specifikációja definiál egy Event Admin szolgáltatást, amely az OSGi keretrendszeren belül eseményekről tud értesítést küldeni szinkron és aszinkron módon. Az üzenetnek témája (topic) van, amely hierarchikus, az egyes szintek / karakterrel választhatók el. Az R-OSGi megoldja, hogy az összekapcsolt OSGi rendszerek megkapják egymás, Event Admin által küldött üzeneteit. Ez annyit jelent, hogy a szerver oldalon az Event Adminon keresztül üzeneteket küldve azokat a kliens láthatja, csupán a megfelelő témára kell feliratkoznia. Az architektúra felépítéséből adódik néhány egyszerű, de annál fontosabb tény. Az egyik ilyen, hogy a Remote Tool-ok minden lekéréskor szerializálódnak, vagyis kópiákkal dolgozunk. Ezt főleg a Blackboardra való írás és olvasás műveletek implementálásánál érdemes figyelembe venni, hiszen elvileg lehetőség van Tool referenciához tartozó változók lekérésre. Mivel a szerializált, majd deszerializált Tool-nak nincs egyértelmű megfelelője a szerver oldalon, ezért az ilyen kérések Tool id- alapú lekérésekké fordulnak. A távoli Blackboardról objektum törlése nem megengedhető, hiszen itt még kevésbé találunk szerver oldali ekvivalens megfelelőt a törölni kívánt objektumnak Összefoglalás Összefoglalva tehát a következők a teendők a szerver oldalon a távoli szolgáltatás-elérés engedélyezéséhez: minden SENSORIA Tool-hoz megfelelő OSGi szolgáltatást kell készítenünk, a SENSORIA Tool 63

64 5.7. ábra. Remoting események és hívások: a fekete nyíl az események továbbítását jelöli, a piros nyíl a távoli eljáráshívást jelzi által implementált interfész neve alá regisztrálva azt minden SENSORIA Tool-ról szerializálható másolatot készítünk, amelyben bemenő paraméter a szerver URI azonosítója, és a SENSORIA Tool által implementált interfész a szerializálható Tool-ok bekerülnek a Remote Tool Store-ba Remote Blackboardot hozunk létre a szerver oldali lokális Blackboard szerializálható elemeit felmásoljuk a Remote Blackboardra, kivéve azokat, amelyeket olyan Tool publikált, amihez nem készült Remote másolat eseménykezelők hozzáadása a másolatok eredeti modell eleméhez, hogy azok változásait követni tudjuk Remote SENSORIA Core létrehozása, paraméterei a Remote Tool Store és Blackboard, illetve a szerver URI-je 64

65 Remote Tool Store és Blackboard OSGi szolgáltatások regisztrálása, majd a Remote SENSORIA Core szolgáltatás regisztrálása, mindhárom helyen Smart Proxy osztály megadásával 5.3. Munkafolyamat-végrehajtó rendszer illesztése a SENSORIA rendszerhez A SENSORIA rendszer munkafolyamat-végrehajtó motorral való kiterjesztésére a JBoss jbpm (JBoss Business Process Management) rendszert javaslom. Ennek a rendszernek az előnye, hogy nyílt forráskódú, és kellően egyszerű felépítése miatt könnyen illeszthető akármilyen Java alapú környezetbe. A jbpm rendszerben a folyamatok végrehajtásáért egy processz virtuális gép (PVM, Process Virtual Machine) felel, amely saját, jól dokumentált[18] végrehajtási konstrukciókat használ, így akár saját leírónyelvet is készíthetünk, amelyet a PVM végrehajtónyelvére fordítva futtathatunk. A PVM támogatja a jpdl (JBoss Process Definition Language) nyelven írt folyamatok végrehajtását, melyek készítéséhez modell alapú szerkesztő áll rendelkezésre. A jpdl-en kívül BPEL és Pageflow nyelven írt folyamatok végrehajtását is támogatja a jbpm (5.8. ábra) ábra. A jbpm vázlatos felépítése, forrás: [33] A folyamatok végrehajtása során a folyamat aktuális állapotát (végrehajtás állása, esetleges folyamatváltozók) egy relációs adatbázisban képes a jbpm rendszer perzisztálni. A jbpm folyamatvégrehajtó rendszer Java ARchive (JAR) formában használható fel programozottan. A jbpm honlapjáról letölthető egy olyan, a JBoss alkalmazásszerverbe telepített web-alkalmazás, amely webes felhasználói felületen teszi lehetővé folyamatok telepítését, és futtatását. 65

66 A jpdl nyelv sajátosságai A jpdl nyelv XML-alapú, és közvetlenül végrehajtható folyamatok definiálását teszi lehetővé és a jbpm végrehajtó motorjának elsődlegesen támogatott nyelve. A jpdl vizuális reprezentációval rendelkező nyelv, a hozzá tartozó Eclipse alapú szerkesztő elérhető a downloads/ honlapról. Az Eclipse alapú szerkesztővel folyamatmodellt (process model) alkothatunk, amelynek példányait a korábban említett PVM komponens képes végrehajtani. A jpdl nyelv és a jbpm környezet részletes ismertetése a [20] leírásban tekinthető meg, mely alapján ennek az alfejezetnek a jpdl-t bemutató része is készült. A jpdl alapvetően kétféle nyelvi elemet definiál: csomópont (node), és él (transition, tranzíció). Csomópontból a nyelvben többféle is létezik, ezek a végrehajtáskor különbözőképpen viselkednek és a legfontosabbak ebben az alfejezetben bemutatásra kerülnek. Az élek az egyes csomópontok közötti lehetséges átmeneteket írják le, vagyis a vezérlésáramlást (cotnrol flow). A tranzícióknak nevet is adhatunk, ez akkor jelentős, ha egy csomópontnak több kimenő tranzíciója is van, hiszen ekkor az egyes ágakat így lehet azonosítani. A jpdl-ben leírt folyamatok mindenképp tartalmaznak két csomópontot: a kezdő, és a vég csomópontot (Start, illetve End State). A folyamat egy példányának végrehajtása úgy képzelhető el, mintha egy érmét (tokent) tennénk le a kiinduló csomópontra, és ezt a tranzíciók mentén fokozatosan mozgatnánk az egyes csomópontokon, egészen addig, míg a végcsomóponthoz nem érünk, ekkor a folyamat véget ér. Amikor az érme egy csomópontra ér, érvényre jut a csomóponthoz meghatározott speciális viselkedés, mely azt is meghatározza, hogy az érme továbbvándorol-e a következő csomópontra, vagy a folyamat külső jelzésre (signal) vár, mielőtt továbbhaladna. A rendszer implementációjában a folyamaton végigvezetett token valójában nagyobb szereppel bír, egyfajta végrahajtási kontextusként szolgál a különféle csomópontoknak. Ez a kontextus lehetővé teszi úgynevezett folyamatváltozók definiálását is, amelyek segítségével adatokat tudunk megosztani az egyes csomópontokhoz tartozó végrehajtást végző elemek között. A folyamatvégrehajtás alapvetően szinkron módon történik, azonban minden csomópont-típusnál lehetőség van egy async nevű mező beállítására, melynek hatására a jbpm aszinkron módon dolgozza fel az adott csomópontban végrehajtandó tevékenységet. Szinkron feldolgozás esetén a jelzés (signal) hatására elindított végrehajtás egészen addig nem tér vissza, amíg valamilyen oknál fogva a végrehajtásnak meg kell állnia (a végrehajtás megállását bizonyos típusú csomópontok eredményezhetik, lásd alfejezet). Ha a végrehajtás közben valamelyik csomópont aszinkron végrehajtásra van kijelölve, akkor a csomópontra specifikus viselkedésének végrehajtása előtt visszatér a lefutást indító függvény, és a folyamatvégrehajtás további része, beleértve a csomópont viselkedését, egy munkaegységbe lesz becsomagolva. A munkaegységeket egy üzenetsorba (vagy a jbpm beépített üzenetsorába, vagy Java Messaging Service üzenetsorba) rakjuk, ahonnan úgynevezett worker thread -ek tudják kivenni, és a 66

67 munkaegység adatai alapján folytatni a végrehajtást. A végrehajtás folytatása itt a csomópont speciális viselkedésének végrehajtását jelenti, beleértve azt is, hogy esetleg a csomópont továbbadja a tokent, és így további csomópontok végrehajtására is szükség lehet A jpdl csomóponttíupsok A következőkben ismertetem a fontosabb csomópont-típusokat az 5.9. ábra alapján ábra. A lényegesebb jpdl csomópont-típusok az ábrán láthatóak Állapotot jelképező csomópont (state node) Az 5.9. ábra «State» feliratú csomópontja egy állapotot jelöl. Ez azt jelenti, hogy a vezérlés erre a csomópontra jutva időlegesen megáll, és a végrehajtás csak akkor folytatódik, ha a folyamat külső jelzést (signal) kap. A jelzésnek szöveges azonosítója van, és a végrehajtás csak abban az esetben halad tovább, ha ez az azonosító megegyezik valamelyik, az állapot csomópontból kimenő tranzíció nevével. A vezérlés ilyenkor értelemszerűen a megfelelő él irányába halad tovább. 67

68 Egyszerű csomópont (node) A «Node» feliratú csomópontja egy egyszerű csomópontot jelöl. Ennek az elemnek az elsődleges szerepe a speciális, programozó által definiált tevékenység végrehajtása, ugyanis a programozó definiálhatja, hogy mi történjen, ha a csomópontot a vezérlés eléri. Ehhez a programozó megadhat egy osztályt, amely implementálja az ActionHandler interfészt, amely egyetlen metódust ír elő ez hívódik meg a vezérlés megérkezésének hatására. A metódus bemenő paramétere a végrehajtási kontextus, amelyen keresztül a metódusban a programozó hozzáfér a folyamatban definiált változókhoz. A folyamatleírásban kézzel is megadhatunk paramétereket, amelyeket a végrehajtó rendszer attribútumok reflektív beállításával, vagy reflektív setter metódushívások segítségével, példányosításkor állít be. Példányosítás után az interfészen definiált execute metódus kerül meghívásra. Alapesetben beállítatlan, vagy üres ActionHandler esetén ez a csomópont állapotként viselkedik, vagyis a vezérlés újabb beérkező jelzésig megáll. A vezérlést az ActionHandler execute metódusában explicit módon tovább is adhatjuk valamelyik kimenő él mentén. Párhuzamos végrehajtás, és összevonás (fork és join node) A «Fork» (párhuzamos elágazás) illetve «Join» (párhuzamos ágak összeterelése) feliratú csomópontjai egymással közeli kapcsolatban állnak. Az előbbi csomópont a vezérlést egyszerre több irányba adja tovább mindegyikre a beérkező token egy gyermek tokenjét bocsájtva, míg az utóbbi a párhuzamos végrehajtási agákat összefésülve akkor továbbítja a végrehajtást, ha egy szülő token összes gyermek tokenje beérkezett hozzá. Feltételes döntés (decision node) A «Decision» feliratú csomópont kettő, vagy több végrehajtási ág közül választja ki azt, amelyiken a vezérlés tovább adódik. Itt is lehetőség van a döntési logika osztályban történő megadására, mely ez esetben a DecisionHandler interfésznek kell, hogy megfeleljen. A interfész által igényelt egyetlen függvény szöveges (String) visszatérési értéke annak a kimenő élnek az azonosítója kell, hogy legyen, amelyiken a vezérlést tovább szeretnénk vinni. Feladat csomópont (task node) A legutolsó csomópont típus a «Task Node»-ja. Ebben lehetőségünk van feladatok (task) definiálására, amelyek végrehajtását a folyamatban részt vevő emberi felhasználóktól várjuk. A vezérlés csak abban az esetben adódik tovább, ha minden feladat elvégzésre került. Ezen csomóponttípus lehetővé teszi, hogy felhasználókhoz, vagy felhasználók egy csoportjához feladatokat rendeljünk. A felhasználók 68

69 hozzárendelését programozottan, az AssignmentHandler interfész implementálásával, vagy a folyamat definíciójába fixen kódolva is megtehetjük. Összegzés A fentiek alapján elmondható, hogy a jpdl nyelven írt folyamatok a Node típusú csomópont lehetőséget biztosít saját viselkedés definiálására egy saját ActionHandler implementáció biztosításával. A jpdl ezen kívül számos számos egyéb lehetőséggel kecsegtet, mint például a feladatlisták, vagy az actor (vagy felhasználói identitás) fogalmának megjelenése, amelyek bonyolult fejlesztési folyamatokban is előkerülnek. A jbpm rendszert a kiterjeszthető működés különösen alkalmassá teszi egyszerűvé teszi a a folyamatok speciális körülményekre történő alkalmazását Folyamatok definiálása jpdl nyelven A bemutatott csomóponttípusokból, illetve tranzíciókból az Eclipse alapú jbpm Graphical Process Designetr (GPD)[19] felület segítségével tudunk folyamatmodelleket készíteni. A folyamattervező felhasználói felületét mutatja az ábra, bal oldalon a lerakható elemekkel (csomópontok, és él), jobb oldalon pedig a folyamatot ábrázoló szerkesztői felülettel ábra. A jbpm folyamattervező felhasználói felülete A jpdl nyelv bővíthető Java osztályok segítségével, ezért a folyamat készítésekor hasznos, ha a folyamatmodellt és a kapcsolódó Java osztályokat jól struktúráltan tudjuk elérni. Ehhez a GPD az Eclipse környezetben megszokott módon egy új projekttípus, úgynevezett Process Project definiálását teszi lehetővé, amelyben az osztályok és a folyamat forráskódja külön könyvtárba kerül. Azt is fontos megje- 69

70 gyezni, hogy egy jpdl folyamat leírása semmilyen, a folyamat grafikus reprezentációjával kapcsolatos információt nem tartalmaz, ezek az adatok külön kerülnek tárolásra a projekten belül is. A megalkotott folyamat futtatásához szükséges előállítani egy olyan fájlt, amiben az osztálydefiníciók és a folyamat definíciója is benne foglaltatik. Ez a fájl Process Archive, egy ZIP formátumú, tömörített fájl, amelyet a GPD a projektből automatikusan képes generálni. A Process Archive fájlt lehetséges egyből egy JBoss alkalmazásszerveren futó, jbpm web-alkalmazásba feltölteni, így abban a környezetben azonnal elérhető lesz. Ezen kívül lehetőség van egyszerű fájlként bárhova elmenteni a fájlrendszeren A jpdl nyelv és a SENSORIA keretrendszer összekapcsolása A SENSORIA keretrendszerben történő, jbpm-alapú folyamatvégrehajtás egyik alapfeltétele tehát a jpdl nyelvhez egy olyan ActionHandler implementáció megírása, amely egy SENSORIA Tool egy metódusának hívását definiálja. Ennek segítségével leírhatunk olyan folyamatokat, amelyek SENSORIA eszközök meghívását is tartalmazzák. A SENSORIA hívásokat is leírni képes folyamatok végrehajtásához szükséges egy olyan környezet biztosítása, ahol a jbpm folyamatvégrehajtója eléri a szükséges SENSORIA elemeket. Fontos továbbá az is, hogy a folyamatok végrehajtásához valamilyen felhasználói felület is rendelkezésünkre álljon, ahol legalább a folyamat leírását át tudjuk adni végrehajtás céljából. Az általam választott megoldásban a jbpm munkafolyamat végrehajtó JAR állományát felhasználva egy OSGi bundle-t készítettem, így a SENSORIA rendszerrel közösinteraktív virtuális gépben futhat. A megalkotott OSGi bundle egyúttal egy SENSORIA Tool-t is definiál, ami folyamatok végrehajtására nyújt programozói felületet, és a felhasználói felületre a SENSORIA szolgáltatásainak köszönhetően szintén ki van vezetve. ActionHandler implementáció A jbpm rendszer kiegészítéseként elkészítettem egy SensoriaActionHandler osztályt. Az osztály olyan szöveges adattagokkal rendelkezik, amelyek megadásával egyértelműen azonosíthatjuk egy SEN- SORIA Tool egy függvényét. Egy eszköz egy függvényének azonosításához szükséges paraméterek: SENSORIA Core Id Definiálja, hogy a SENSORIA rendszeren belül melyik Core tartalmazza a hívni kívánt függvényt. Itt van lehetőség távoli Core megadására, ami távoli eljáráshívást fog eredményezni. SENSORIA Tool Id A SENSORIA Tool egyedi azonosítója, amely alapján a ToolStore-ban egyértelműen megtalálható. 70

71 Metódus neve A SENSORIA Toolon belül egy Function-t azonosító név. Ez még a hívott szolgáltatást nem feltétlenül azonosítja, hiszen más paraméterezéssel létezhet azonos nevű függvény. Paraméterek száma és típusa A hívni szándékozott függvény paramétertípusainak egyeznie kell (vagy ősosztály viszonyban kell lennie) azoknak az adatoknak a típusával, amelyet a hívás paraméteréül szánunk. Visszatérési érték típusa A visszatérési érték típusát is meg kell adnunk a metódus teljes azonosításához, hiszen elképzelhető, hogy két metódus minden egyéb tulajdonsága azonos. A SensoriaActionHandler osztály adattagjai a fentieknek megfelelően az ábrán láthatóak. Az azonosításhoz szükséges paraméterek mind String típusúak, vagyis a folyamatleírásban szövegesen megadhatóak. A params attribútum egy név-érték párokat tartalmazó Map, amelyben a hívás változóneveihez rendelünk String típusú értéket. A folyamatleírásban csak szöveges értékeket tudunk megadni, azonban egy metódus objektumokat is kaphat paraméterül, ezért a SensoriaActionHandler működése során a #-el kezdődő params értéket úgy értelmezi, hogy az egy folyamatváltozó neve ábra. A SensoriaActionHandler osztály A SensoriaActionHandler execute metódusa, amely az eszköz meghívásáért felelős, megpróbálja a beállított attribútumok alapján egyértelműen megkeresni a hívandó függvényt. Ehhez először elkéri a SENSORIA keretrendszertől a megadott nevű SensoriaCore-t, majd ennek ToolStore-jában a megadott toolid alapján lekéri a Tool-t. Ezután a Tool összes függvényét (Function példányok) végigézi, és ha megfelelő nevűt talál, akkor ellenőrzi a többi kritériumot: ellenőrzi a paraméterek számát és típusát, valamint a visszatérési érték típusát. A paraméterek típusának ellenőrzésekor végigmegy a SENSORIA Function példány minden Parameter elemén, és ellenőrzi, hogy a params Map-ben az adott nevű paraméter benne van-e. Ha benne van, akkor megvizsgáljuk a Map-ben hozzárendelt értéket: ha az érték egy #-el kezdődő szöveg, akkor lekérjük a folyamatváltozók közül az ezen a néven tárolt értéket (objektumot). Ezután a Java Reflection API-t igénybevéve, megvizsgáljuk, hogy a folyamatváltozó típusa értékül adható-e a paraméter típusának (Class.isAssignableFrom(Class clazz) függvény). A visszatérési típusnál a típusok egyezését vizsgáljuk (ebben az öröklés nem játszik szerepet). Ha a fenti ellenőrzések után a kiszemelt Function megfelelő, akkor elvégezzük rajta a metódushívást, szükség szerint a folya- 71

72 matváltozók értékeiből behelyettesítve a hívás paramétereit. A metódus visszatérési értékét ezután a egy folyamatváltozóba írjuk, amelynek nevét a returnname attribútumnak kell tartalmaznia. A jbpm folyamatvégrehajtó beültetése a SENSORIA környezetbe A jbpm osztálykönyvtár, amely a teljes végrehajtórendszert tartalmazza, JAR formátumban rendelkezésünkre áll. A JAR fájlok OSGi bundleban történő felhasználása egyszerű, a kérdéses JAR fájlt be kell másolni bundle egy alkönyvtárába, majd beírni a MANIFEST fájlba, a Bundle-classpath fejléchez a JAR fájl relatív elérési útját. Így a JAR fájlban lévő osztályok elérhetőek a bundle-ben. Így a JAR fájl a classpath-on lesz, vagyis a benne elérhető osztályokra hivatkozhatunk a bundle-on belül. A jbpm központi részén kívül szükség van az általam elkészített SensoriaActionHandler osztályra is, ezzel ugyanis lehetőség nyílik pusztán a folyamatot leíró XML fájl alapján annak végrehajtását kezdeményezni, amennyiben a SensoriaActionHandler-en kívül egyéb Java osztályt a leírás nem igényel. A következő lépés az, hogy a felhasználó, illetve fejlesztők számára kivezessük a folyamatvégrehajtó funckionalitását. Ezért egy olyan SENSORIA Tool-t készítettem, amely egy megadott jpdl (XML), vagy Process Archive folyamatleírását képes végrehajtani. A szolgáltatás SENSORIA Tool-ként való elkészítése azért is előnyös, mert a funkcionalitás a SENSORIA rendszer primitív felhasználói felületén azonnal ki is próbálható ábra. A jbpm folyamatvégrehajtót burkoló SENSORIA Tool programozói interfésze Az elkészített SENSORIA Tool programozói interfészét mutatja az ábra. A createschema és a cleardatabase függvények a jbpm alatt futó adatbázis inicializálását (táblák létrehozását) illetve törlését végzik el. Az adatbázishoz való csatlakozás paramétereit egy konfigurációs XML állomány (hibernate.cfg.xml) tartalmazza, amely szintén az OSGi bundle classpath-ában elérhető. A jbpm rendszer a Hibernate[10] objektum-relációs leképezőt használja fel a folyamatleírás, valamint a folyamatváltozók, és a folyamat állapotának adatbázisba mentésére, a konfigurációs állományban ezt a rendszert paraméterezzük fel. A jbpm rendszer tartalmaz egy mintát a konfigurációs fájl beállításaira, így ebből kiindulva könnyen beállíthatjuk. A csatlakozáshoz mindenképp szükséges az adatbáziskezelőhöz tartozó JDBC meghajtó megléte is a bundle-ben. Én a MySQL adatbáziskezelő 5.0-s verzióját használtam, és a neki megfelelő JDBC meghajtót szintén a bundle classpath-ra raktam. Mielőtt tehát először igénybe vennénk a folyamatvégrehajtó szolgáltatásait, szükséges a createschema 72

73 függvény meghívása. Folymat futtatásához a másik két függvény, az executeprocessdefinition és az executeprocessarchive használatosak. Az előbbi egy jpdl folyamatleíró XML tartalmát, míg az utóbbi egy Process Archive -ra mutató abszolút elérési utat vár paraméterül. Mindkét függvény először parseolja a folyamat leírását, majd telepíti az adatbázisba. Ezután létrehoz egy új példányt (ProcessInstance), és abban elindítja a végrehajtást (ProcessInstance.signal). Ez a stratégia olyan folyamatok végrehajtására alkalmas, amelyekben nincsen állapotot jelképező csomópont (wait state), hiszen ezeknek újabb jelzés (signal) szükséges, hogy a várakozásból továbblépjenek. Ha minden csomópont a SensoriaActionHandler-t használja, abban az esetben a folyamat teljes végrehajtása után tér vissza mindkét függvény. 73

74 6. fejezet A DIANA szoftverfejlesztési folyamat átültetése a bővített keretrendszerbe Ebben a fejezetben egy példán keresztül demonstrálom az eszközintegrációs keretrendszer képességeit és használatát. A példa során a DIANA fejlesztési folyamat 2. fejezetben megismert, a 2.3. ábrán látható részfolyamatából indulunk ki. A közreműködésemmel elkészült folyamatvezérelt eszközintegrációs keretrendszer lehetővé teszi az integrált eszközök felett folyamatok végrehajtását. Ezeket a lehetőségeket kihasználva a folyamat átültetése két lépésben történt: A folyamat során felhasznált eszközökhöz csatolót kellett készíteni, melynek segítségével az eszközintegrációs keretrendszerben a szolgáltatásaik elérhetővé váltak. El kellett készíteni a folyamat modelljét a jpdl leírónyelven. A fejezet részletesen tárgyalja a fenti lépéseket, és a megalkotott folyamatmodell végrehajtásának szemantikáját A DIANA folyamat végrehajtásához szükséges csatolók A DIANA szoftverfejlesztési folyamat kiválasztott részfolyamatában, vagyis az összerendelési folyamatban az elvégzendő tevékenységek zömét a fejlesztő végzi, méghozzá a 2. fejezetben részletesen bemutatott, Eclipse alapú felület segítségével. A folyamat eszközintegrációs keretrendszerbe ültetett változatban a DIANA modell szerkesztését továbbra is a fejlesztő kell, hogy végezze a grafikus felületen keresztül, azonban valamilyen mechanizmust kell biztosítanunk arra, hogy a fejlesztő tudomást szerezzen arról, hogy neki milyen feladatot kell elvégeznie. Azt is meg kell oldani, hogy a fejlesztő jelezni tudja, hogy az adott fejlesztési lépéssel készen van, hiszen a fejlesztési folyamat végrehajtása sok esetben csak az aktuális fejlesztési lépés végrehajtása után haladhat tovább. 74

75 A fejlesztők munkája és a folyamatvégrehajtás közötti szinkronizációra több értelmes megoldás is elképzelhető, például egy feladatlista karbantartása, ahol a fejlesztő követni tudja a számára kijelölt feladatokat, illetve jelezni tudja, ha azokkal elkészült. Ennél közvetlenebb egy olyan módszer, ahol a feladat végrehajtásához szükséges felületet a folyamatvégrehajtó automatikusan megnyitja, majd ezen a felületen a fejlesztő a szükséges módosítások elvégzése után jelzi, hogy a lépéssel elkészült. Implementációs szempontból a legegyszerűbb megoldás, ha a felhasználó értesítése a megfelelő szerkesztő képernyő megjelenítésével történik. Szintén implementációs könnyebbség, ha a szerkesztő becsukása egyben azt is jelzi a folyamatvégrehajtó rendszernek, hogy az adott lépéssel a fejlesztő elkészült. A fejlesztési lépések végrehajtásához (mások által) kifejlesztett szerkesztőt már megismerhettük a 2.3. alfejezetben. Ehhez a szerkesztőhöz elkészítettem egy olyan csatolót, amely lehetővé teszi, hogy a keretrendszerből egy metódus meghívásával egy adott lépéshez tartozó képernyőt megnyissunk, és a metódushívás csak akkor térjen vissza, amikor a fejlesztő bezárta a szerkesztőfelületet A DIANA szerkesztő csatolása a keretrendszerhez A DIANA folyamathoz rendelkezésre álló szerkesztőhöz kialakított csatolófelületen egyetlen metódus található, amellyel a folyamat megadott lépéséhez tartozó szerkesztő nyitható meg egy megadott fájlra. A metódushívásnak akkor kell visszatérnie, ha szerkesztett fájlt a fejlesztő elmentette és utána a szerkesztőt becsukta. Az Eclipse rendszerben, amelyben a DIANA fejlesztőeszköz készült, egy szerkesztő megnyitása nem blokkoló művelet, vagyis a megjelenés után azonnal visszakapjuk a vezérlést. A szerkesztő becsukásának hatására az Eclipse rendszer a szerkesztőt megvalósító osztály egy meghatározott függvényét hívja meg. Az eredeti szerkesztőből örökléssel származtattam egy olyan változatot, amely képes a becsukásról érdekelt objektumokat értesíteni az esemény bekövetkezéséről. Ezután készítettem el a csatolót, amelyet az eszközintegrációs keretrendszerből is el lehet érni. A csatoló az új szerkesztőt nyitja meg, és zárakat használ arra, hogy egyetlen metódusa csak akkor térjen vissza, mikor a szerkesztőt bezárták. Az új szerkesztő megnyitásának vázlatos szekvenciáját mutatja a 6.1. ábra. Az Eclipse rendszerben megszokott módon először referenciát szerzünk a megnyitni kívánt szerkesztőre az egyedi azonosítója alapján. A szerkesztőnek implementálnia kell az általam definiált ISENSORIAWorkflowCapableEditor interfészt. Ez az interfész olyan szerkesztőt jelöl, amely becsukása esetén jelzést képes küldeni érdekelt objektumok számára. Az interfésznek két metódusa van, egy addcallbacklistener (ISENSORIACallback) és egy removecallbacklistener (ISENSORIACallback), melyek az ilyen, érdekelt objektumok bejegyzésére illetve eltávolítására szolgálnak. A szerkesztő megnyitása után a csatoló (ISensoriaTool) azonnal zárol egy zárat (lock), majd egy a szerkesztő bezárását figyelő eseménykezelőt helyez el a szerkesztőn, 75

76 6.1. ábra. Eclipse szerkesztő megnyitása SENSORIA Toolból amely feloldja a zárat. Végül a csatoló ismét zárolja a zárat, és így a metódus blokkol, és egészen addig nem tér vissza, amíg a bezárás eseményét figyelő kezelő függvény (editorisclosing) meg nem hívódik, és fel nem oldja a zárat A DIANA folyamat jpdl reprezentációja A DIANA fejlesztési folyamat 2.3. ábrán látható leírását néhány apró változtatással átvehetjük a folyamat jpdl modelljébe, mely az 6.2. ábrán látható. A folyamat egyes tevékenységei a jpdl leírásban Node csomópontoknak felelnek meg. Ezen felül csak arra kell figyelnünk, hogy a párhuzamosan végrehajtandó ágakat Fork típusú csomópontokból ágaztassuk szét, és az ágakat megfelelően, egy Join csomóponttal fésüljük össze (minden Fork csomóponthoz tartozik egy Join csomópont, ami az ágait összefésüli). 76

77 6.2. ábra. A DIANA folyamat jpdl leírása Az egyes Node csomópontok akciójaként (az alfejezet alapján) a SensoriaActionHandler osztályt megadva és felparaméterezve a SENSORIA keretrendszerbe ültetett csatolók (és ezáltal eszközök) szolgáltatásait vehetjük igénybe. A DIANA folyamat esetében az 6.1. alfejezetben leírt csatolót fogják az egyes csomópontok meghívni. A hívás paraméterezése minden egyes csomópontnál a szerkesztőfelület azonosítója (sorszáma), és a modellt tartalmazó fájl neve. A fájl nevét a #filename folyamatváltozóban tároljuk. A folyamat egy csomópontjának XML forráskódja alább látható. 77

78 <node name =" Interface type mapping" > <action name =" invoke DIANA editor" class =" eu. sensoria_ist. casetool. workflow. jbpm. SensoriaActionHandler " > <toolid > hu.bme.mit.pimpsm.sensoria.tools.idianatool </toolid > < functionid > openeditor </ functionid > < returntype > String </ returntype > <params > <entry > <key >relativepath </key > <value ># filename </value > </entry > <entry > <key > editorpageindex </ key > <value >4</ value > </entry > </params > < resultname > DIANA_Step3 </ resultname > </action > < transition to=" bigjoin" name =" if. to_join2" ></ transition > </node > 6.4. A DIANA folyamat jpdl leírásának végrehajtása A DIANA folyamat fentiekben megalkotott modelljét végrehajtásra odaadhatjuk a folyamatvezérelt eszközintegrációs keretrendszernek. A folyamatvégrehajtó a megkapott leírás alapján elkezdi végigjárni a folyamat csomópontjait, vagyis a DIANA folyamat fejlesztési lépéseit. Az egyes Node-okhoz a leírásban hozzá van rendelve a keretrendszer egy csatolójának meghívása. Minden csomóponthoz ugyanaz a csatoló van hozzárendelve, csak más paraméterezéssel. Mikor a folyamatvégrehajtó egy Node csomópontot talál, a következők történnek: A folyamatvégrehajtó a leírás alapján megfelelő paraméterezéssel meghívja a DIANA szerkesztőt elérő csatolót. Az egyik paraméter a DIANA modellt tartalmazó fájl elérési útja a lokális fájlrend- 78

79 szerben. A megfelelő DIANA szerkesztő megnyílik. A hívás eredményeként mindig az adott csomópontnak megfelelő fejlesztési lépéshez tartozó szerkesztő nyílik meg. A szerkesztő azonosítása számok alapján, a folyamatleírásban található meg. A fejlesztő változtatásokat végez a DIANA modellen a szerkesztő segítségével, majd a bemeneti fájlba elmenti a változásokat. A fejlesztő bezárja a DIANA modell szerkesztőfelületét. Ennek hatására a folyamatvégrehajtó megkeresi a következő csomópontot, és ugyanez a folyamat ismétlődik. A folyamat végrehajtása során a keretrendszer és az általa igénybe vett eszközök azonos Eclipse környezetben futnak. A fejlesztő minden lépésben ugyanazt a fájlt módosítja, vagyis a folyamaton egyetlen dokumentum áramlik végig. A 6.3. ábra a folyamat végrehajtásának egy lépését szemlélteti ábra. A DIANA folyamat egyik lépésének (alkalmazás típusának megállapítása) végrehajtása. Felül a megnyíló szerkesztő, alul a folyamat aktuális állapota (pirossal kiemelve), valamint néhány már elkészült lépés (kékkel kiemelve) látható. 79

80 6.5. Távoli eljáráshívás, dokumentumkezelés a folyamatban A fejlesztési folyamatnak nem minden lépésében működik közre a fejlesztő, ugyanis a alfejezetben leírt allokációs lépésében automatikusan kerülnek kiszámításra bizonyos elemek. Ebben a lépésben a fejlesztő gombnyomására olvassa be a DIANA modellt egy megoldóprogram. Ez tehát egy algoritmus által elvégzett, potenciálisan számításigényes művelet, ezért célszerű lehet ezt távoli eljárás segítségével egy másik, nagyobb teljesítményű hoszton elvégezni. Ezt a lehetőséget az eszközintegrációs keretrendszer távoli eljáráshívás segítségével támogatja. Az eszköz, amely a számítást végzi, eredetileg egy gombnyomás hatására hívódott meg, ezt a mechanizmust a keretrendszer által végzett, programozott hívásra szeretnénk lecserélni. Ehhez egy csatolót kell készíteni a megoldóeszközhöz. Érdemes végiggondolni, hogy hogyan alkotjuk meg a csatolót, azaz milyen paraméterekkel kívánjuk meghívni, és milyen visszatérési értéket várunk tőle. A DIANA folyamat allokációs lépéshez is biztosítanunk kell azt a modellt, amely a lépéshez szükséges bemenő adatokat szolgáltatja. Az eredeti folyamatban ezeket az adatokat egy, a lokális fájlrendszeren elérhető fájlból nyertük ki. Távoli eljáráshívás esetén nem szükségszerűen áll rendelkezésre ez a fájl a távoli hoszton. Lehetséges lenne a fájl tartalmát valamilyen módon a hívás paramétereként átadni, ez azonban nem túl elegáns megoldás. Az eredeti eszközhívás mellékhatásaként az allokációs lépés eredménye tárolásra került az eszköznek megadott fájlban. Távoli eljáráshívás esetén ez a megoldás nem járható, hiszen az eredményre a hívó oldalon van szükségünk. Megoldást jelentene, ha a csatolót úgy írnánk meg, hogy a hívás visszatérési értéke az allokációs lépés eredményét is tartalmazó modell sorosított változata legyen. A fentiek lehetőségek helyett egy dokumentumkezelő rendszert alkalmaztam, ahonnan és ahová a hívás szereplői fel- illetve le tudják tölteni a bemeneti és kimeneti fájlokat. Az IBM Jazz Platform (részletesen lásd: 4.2. alfejezet) adattárolóját (data repository) használtam fel egy speciálisan a DIANA allokációs részfolyamatához kialakított tároló megvalósításához. A Jazz Platform adattárolója objektummodellek tárolását teszi lehetővé relációs adatbázisban, úgynevezett objektumrelációs leképzés (ORM, Object-Relational Mapping) segítségével. Az általam megvalósított DIANA adattároló csupán az allokációs részfolyamatra koncentrál. Az implementáció része az adatmodell, amely a tárolni kívánt adatokat leírja (tárolási, avagy storage modell), valamint azon szolgáltatások megvalósítása Jazz környezetben, amelyek az adatok magasszintű kezelésére használhatóak A tárolási (storage) modell kialakítása A tárolási modell segítségével tudjuk definiálni a modellünkben előforduló adattípusokat, melyekből a Jazz keretrendszer képes a szükséges adatbázis táblák származtatására (részletesen lásd: alfejezet. A DIANA folyamat allokációs lépésében előforduló elemeket a 6.4. ábra mutatja. Alapvetően négyféle 80

81 elemnek van fontos szerepe: Application típusú elemek, melyek a fejlesztett szoftver komponenseit jelképezik. Partition típusú elemek, melyek a készítendő szoftver célplatformjának elemi, alkalmazásokat futtatni képes hardver komponenseit jelképezik CompatibilityMapping típusú elemek, melyek segítségével a fejlesztő definiálhatja az érvényes alkalmazás partíció összerendeléseket. ValidAllocation típusú elemek, melyek az allokációs algoritmus lefutása után megmutatják, hogy egy Application és egy Partition típusú elem között milyen érvényes összerendelés létezik, vagyis hogy melyik alkalmazás melyik partícióban futhat, a CompatibilityMapping elemeket kényszerként figyelembe véve (a számítás egy kényszerkielégítési probléma megoldását jelenti, bővebben lásd:[5]) ábra. Az allokációs lépés fontos típusai (részlet a DIANA metamodellből) A fentiek alapján elmondható, hogy az allokációs lépés modellje három, egymástól független részre bontható. Az Application és Partition típusú elemek gyűjteménye a modellben függetlentül megjelenthetnek. A ValidAllocation, illetve CompatibilityMapping típusú elemek egy külön modellrészt alkotnak, hiszen csak egyirányú referenciákat tartalmaznak a partíciókra, illetve az alkalmazásokra. 81

82 A tárolási metamodell ezeket a tulajdonságokat nagyvonalakban követi, vagyis a tárolási modellben az egymástól független dokumentumrészek külön kerülnek ábrázolásra. Az egyes független modellrészek tartalmát a tárolási modellben (tetszőleges hosszú) szövegként modelleztem (Content típusú referencia), vagyis az egyes modellrészek tartalmát sorosítva tudjuk eltárolni. Az összes elemet az Auditable ősosztályból származtattam, amelynek segítségével az objektumok a Jazz Platform automatikus verziókezelése alá kerülnek. A megalkotott tárolási modell UML osztálydiagramját a 6.5. ábra mutatja (az ábrán szürkével jelölve a Jazz Platform által definiált osztályokat) ábra. Az allokációs lépés tárolási metamodellje A továbbiakban a DIANA modell kifejezés alatt a 6.4. ábrán látható metamodell egy példányát értjük, tárolási modell alatt pedig a 6.5. ábrán látható metamodell egy példányát. Egy tárolási modell gyökérelemének tekinthető a DianaModel osztály, melynek name attribútuma egyedi azonosító. A tárolási modell Replication és Platform osztályai rendre az alkalmazásokat, illetve a partíciókat tárolják, míg az Allocation típusú csomópont az allokáció követelményeit, és az allokációs lépés eredményét hivatott tárolni. Az Allocation osztály hasvalidallocations mezője azt jelzi, hogy a tárolt modellrész tartalmazza-e már egy allokációs lépés lefutásának eredményeit, vagyis hogy az érvényes allokációk kiszámításra kerültek-e már. 82

83 Jazz szolgáltatások a tárolási modell tartalmának elérésére Az elkészült tárolási metamodellhez létrehoztam a Jazz keretrendszerében egy szerver oldali szolgáltatást, valamint egy ehhez tartozó kliens oldali könyvtárat (client library), melyek az alapvető Jazz adattároló szolgáltatásaihoz képest az adatok magasabb szintű elérését teszik lehetővé. A szerver oldalon lévő szolgáltatás alapvetően DianaModel példányok név alapján történő lekérésére és létrehozására, valamint egy DianaModel típusú objektum részeihez (Replication, Platform, Allocation) tartozó tartalom (String objektumok) eltárolására és lekérésére definiál műveleteket. A szerver oldali szolgáltatást RPC típusúnak definiáltam. Szerver oldalon az egyes DIANA modellrészek tárolásakor a megadott DianaModel megfelelő részéből (Platform, Replication) mindig új példányt hozunk létre, és a DIANA modellrész sorosított változatát ez alá az új objektum alá töltjük fel. Erre azért van szükség, mert a Jazz Platform a Content típusú elemek (szöveg) tartalmának változása esetén az őt tartalmazó konténer elem verzióját nem változtatja meg, így ha pusztán a Content objektumot kicserélve a tárolási modellben történt változások nem lennének láthatóak. A szerver oldali szolgáltatás programozói interfészét mutatja a 6.6. ábra ábra. A tárolási modellhez tartozó szerver oldali Jazz szolgáltatás API-ja A kliens oldali könyvtár a szerver oldali szolgáltatásra építve definiálja saját műveleteit. A kliens oldali könyvtár támogatja, hogy egy EMF Resource objektum tartalmát egy adott nevű DianaModel különböző modellrészeiként tároljuk el. Ez annyit jelent, hogy egy megadott Resource tartalmának XMI formátumú, String objektumba sorosított változatát tároljuk el, melyhez a szerver oldali szolgáltatást hívjuk segítségül. A kliens természetesen támogatja az egyes modellrészek lekérdezését is. A lekérdezések az egyes DianaModel részek tartalmából egy Resource objektumot töltenek fel, így a Resource objektumon belül létrejön a sorosított modellnek megfelelő objektumhierarchia. Feltöltéskor a kliens könyvtárnak átadott Resource objektum tartalmazza a DIANA metamodelljének (6.4. ábra) egy példányát. A fentiekből következik, hogy (legkésőbb a DIANA modell tárolásakor) érdemes a DIANA modell független részeit külön Resource-ba rendezni. Ez abból a szempontból is hasznos, hogy a független modellrészek fájl szinten is elkülönülnek. Ez azért szerencsés, mert meggátolja olyan szituációk 83

84 kialakulását, amelyekről különböző modellverziók összefésülését igénylik. A kliens oldali könyvtár publikus programozói felületét mutatja az 6.7. ábra ábra. A tárolási modellhez tartozó kliens oldali Jazz szolgáltatás API-ja Ha több Resource-ba rendezzük a modellünk elemeit, akkor ezen Resource-okat egy ResourceSetbe összegyűjtve az EMF a független modellrészek közötti referenciákat képes feloldani. Technológiai szempontból így lehetséges az, hogy például a DIANA modell ValidAllocation elemei értelmesen eltárolhatóak legyenek külön modellrészként. Ilyenkor a ValidAllocation elemeket tartalmazó modell sorosított változatába bekerül egy hivatkozás egy másik fájlra. Fontos, hogy ezt a hivatkozást mindig fel lehessen oldani, amikor a modell tartalmához hozzá akarunk férni, vagyis a hivatkozott fájlnak léteznie kell, mikor a modell objektumait manipuláljuk. A példa szempontjából ez azért lényeges, mert a modell tárolásakor, a modell sorosítása folyamán ezen hivatkozott Resource-ok elérési útja rögzítésre kerül. Kiolvasás után, a modell referenciáinak feloldásakor ugyanezen elérési utakon lévő fájloknak léteznie kell a kiolvasást végző rendszerben, természetesen megfelelő tartalommal. Ezt a feltételt a példában úgy lehet biztosítani, hogy a modellt tartalmazó fájlokat mindig egyforma könyvtárstruktúrában tartjuk, és egymáshoz képest a relatív elérési útjuk a tárolásnál és a kiolvasásnál mindig ugyanaz. Ennél általánosabban is megoldható a probléma úgy, hogy minden egyes Resource tárolásakor a tárolási modellben feljegyezzük azt az egyedi erőforrás-azonosítót (URI, Uniform Resource Identifier), amelyen a tárolásnál megadott forrás Resource megtalálható A tároló szolgáltatásainak felhasználása a DIANA folyamatban Ahhoz, hogy a leírt tárolási modellt és a kapcsolódó szolgáltatásokat dokumentumkezelésre tudjuk használni a közreműködésemmel elkészült folyamatvezérelt eszközintegrációs keretrendszeren keresztül, csatolót kell hozzá készítenünk. A csatoló alapvetően egy burkoló, amely a kliens könyvtáréhoz hasonló funkcionalitást nyújt, és a kliens szolgáltatás tárolási és lekérési függvényeit hívja meg a háttérben. A csatoló tárolófüggvényeinek bemenő paramétere egy DIANA modellt tartalmazó fájl elérési útja és a létrehozandó DianaModel neve, a lekérdezéseket végző függvényeké pedig a letöltés céljául szolgáló fájl elérési útja, valamint az adatforrás DianaModel neve. A kliens szolgáltatás fölé írt csatoló programozói interfészét mutatja a 6.8. ábra. 84

85 6.8. ábra. A tárolási modell Jazz kliense köré írt SENSORIA csatoló API-ja A szolgáltatást ezután arra használjuk fel, hogy az allokációs lépést elvégző megoldóeszköz (távoli) meghívása előtt a számításhoz szükséges modellrészeket feltöltsük, majd a megoldóeszköz meghívása utána letöltsük a tárolóból. A megoldóeszköz meghívása a csatolóján keresztül történik, a hívás egyetlen paramétere pedig a ki- és bemenet tárolására használt DianaModel neve. A megoldóeszköz csatolója a megadott név alapján összeállítja az eszköz bemenő adatait, meghívja az eszköz szolgáltatását, majd az eredményt feltölti a tárolási modellbe, a neki megfelelő helyre. Ez alapján a leírás alapján könnyedén megalkothatjuk a korábbi (egyetlen csomópontból álló) allokációs lépést helyettesítő jpdl leírást. Az új részfolyamat három egymást követő lépésből áll: A folyamatvégrehajtó a DIANA modellt tartalmazó fájl szükséges részeit (Partition, Application és CompatibilityMapping objektumok) feltölti a Jazz adattárolóba. A feltöltött DIANA modellre látható példa a 6.9. ábrán. Az ábrán három alkalmazás és két partíció, és közöttük definiált kényszerek láthatóak. Ennek a modellnek a tárolási modellben megjelenő változatát mutatja a ábra. Az ábrán szürkével jelölt részek külön vannak sorosítva, és a tárolási modell különböző részeiben helyezekdnek el az adatbázisban. A folyamatvégrehajtó meghívja az allokációt végző eszközt egy távoli hoszton, paraméterül adva a DianaModel nevét, amelybe az imént töltöttünk adatokat. A hívás során: Az adattárolóból a megoldóeszköz csatolója letölti a bemenő adatokat. A csatoló meghívja a megoldóeszközt, amely kiszámítja az érvényes ValidAllocation objektumokat. Az eredményt a csatoló feltölti az adattárolóba, külön ügyelve, hogy a hasvalidallocations logikai változót true értékre állítsa, ezzel jelezve, hogy az allokációk kiszámítása megtörtént. Az eszköz meghívása utána a ábrán láthatóhoz hasonló tartalom található a tárolóban. Az allokáció előtti állapothoz képest egy lehetséges megoldás (a pirossal jelölt rész) került a modellbe. A folyamatvégrehajtó meghívja a tároló csatolóját, amely letölti az eredményt a Jazz adattárolóból, és fájlba írja azok tartalmát. 85

86 6.9. ábra. Példa az allokációs lépés előtti DIANA modell objektumokra és relációikra ábra. Példa az allokációs lépés végrehajtása előtt a tárolási modell tartalmára. A DIANA modell különböző (szürkével jelölt) részei az adatbázisban külön sorosítva vannak eltárolva. 86

87 6.11. ábra. Példa az allokációs lépés végrehajtása után a tárolási modell tartalmára. A DIANA modell különböző (szürkével jelölt) részei az adatbázisban külön sorosítva vannak eltárolva. Pirossal kiszínezve látszanak az allokációs lépés által kiszámított elemek. 87

88 Az új részfolyamat jpdl leírását mutatja az (6.12. ábra). Ezen lépések után a folyamatvégrehajtó továbbhalad a folyamatban úgy, hogy az utolsó lépésben kiírt fájl szolgáltatja a további (fejlesztői interakciót igénylő) lépések bemenő adatát ábra. A DIANA folyamat allokációs részfolyamatának jpdl leírása 88