BPEL 2.0 ALAPÚ MUNKAFOLYAMATOK KOOPERÁCIÓJÁNAK FORMÁLIS VERIFIKÁCIÓJA. Bende Tibor V. évf. Műszaki informatika

Átírás

1 BPEL 2.0 ALAPÚ MUNKAFOLYAMATOK KOOPERÁCIÓJÁNAK FORMÁLIS VERIFIKÁCIÓJA Bende Tibor V. évf. Műszaki informatika Hegedüs Ábel V. évf. Műszaki informatika Konzulensek: Kovács Máté LMU-PST doktorandusz Gönczy László BME-MIT ügyvivő szakértő Dr. Varró Dániel BME-MIT egyetemi ajdunktus Méréstechnika és Információs Rendszerek Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem Budapest, 2008.

2 2 Bende Tibor, Hegedüs Ábel : BPEL 2.0 alapú munkafolyamatok kooperációjának formális verifikációja Copyright c All rights reserved This document was typeset in L A TEX 2ε.

3 Tartalomjegyzék 1. Bevezetés 9 2. Munkafolyamatok Motivációs példa Webszolgáltatások Web Services Description Language (WSDL) Business Processes Execution Language (BPEL) Alaptevékenységek Strukturált tevékenységek Hiba-, esemény-, kompenzáció-, és megszakításkezelés Megkötések Az esettanulmány folyamatainak bemutatása Modellellenőrzés Lineáris idejű temporális logika Tranzíciós rendszerek A modellellenőrzési probléma Symbolic Analysis Laboratory keretrendszer (SAL) BPEL 1.1 munkafolyamatok modellezése Adatfolyam modellezése Alaptevékenységek modellezése Strukturált tevékenységek modellezése Szekvenciális végrehajtás Párhuzamos végrehajtás Feltételes végrehajtás Ciklikus végrehajtás Korlátozott műveleti hatókörű tevékenység BPEL 2.0 munkafolyamatok modellezése Változó inicializáció modellezése Adatmanipuláció modellezése Hibaterjesztés Megszakításkezelő modellezése Flow linkek modellezése Tevékenységek kihagyása Linkek állapottere Átviteli és kapcsolódási feltétel modellezése Holt utak eltávolításának modellezése BPEL modellezéséhez kapcsolódó munkák

4 4 TARTALOMJEGYZÉK 6. Kooperáló munkafolyamatok modellezése Kooperáció modellezésének célja A kooperáció modellezése A folyamat modellje A tevékenységek állapottere Adatmodell Finomítási lépés BPEL kooperáció modellezéséhez kapcsolódó munkák Kooperáló BPEL 2.0 munkafolyamatok analízise Önálló folyamat vizsgálata Biztonsági kritériumok formalizálása Hibainjektálás Kooperáló folyamatok vizsgálata Modellellenőrzés végrehajtása Mintafolyamat ellenőrzése Hibaterjedés vizsgálata Kooperáló folyamatok ellenőrzése Megvalósítás Metamodellezés Gráftranszformáció VIATRA 2 modelltranszformációs keretrendszer Modelltér Navigáció a modelltérben Megvalósítás BPEL Kooperáció Értékelés Függelék BPEL2.0 statikus analízis kivonata Webszolgáltatások protokollkészlete Extensible Markup Language (XML) SOAP Transzformációk végrehajtása Az esettanulmány folyamatai

5 Összefoglalás Napjainkban egyre több, az iparban tevékenykedő cég helyezi el szolgáltatásait webszolgáltatásként az Interneten. Ilyen szolgáltatásokat megvalósító folyamatok összessége "lazán kapcsolt" egységet alkot oly módon, hogy új szolgáltatásokat a rendelkezésre állók kombinációjából hoznak létre. Ezen automatizált folyamatok megadásának egyik legelterjedtebb módja a Business Process Execution Language (BPEL) használata. A BPEL szabvány egy XML alapú nyelvet definiál üzleti munkafolyamatok viselkedésének leírására. Azonban a lazán csatoltság és platformfüggetlenség ára, hogy sok esetben nem garantált a hívott szolgáltatások megfelelő működése. Ezért valós igény mutatkozik arra, hogy formálisan is ellenőrizzük ezeket a folyamatokat és az azok közötti együttműködést. Ezért szükség van olyan szisztematikus, precíz módszerekre amelyek segítik a tervezőt robosztus munkafolyamatok létrehozásában. A probléma természetesen nem teljesen új keletű, létezik olyan megközelítés, amely e folyamatokat nemdeterminisztikus véges automatákra képezi le, és olyan is, amely egy folyamatot adatfolyamhálóvá transzformál. Ismeretes olyan módszer is, amely egy önálló folyamatot képez le tranzíciós rendszerre, amelyben modellellenőrzésre és lineáris temporális logikai kifejezések bizonyítására van lehetőség matematikailag bizonyított módszerekkel. Mindezek azonban a BPEL szabvány 1.1-es vagy korábbi verzióját támogatják ben elkészült a nyelv legújabb, 2.0-ás változata, amelyre nem létezik még megfelelő megoldás. Ráadásul önálló BPEL folyamatok ellenőrzése önmagában figyelmen kívül hagy megannyi hibalehetőséget, amelyek pont a köztük lévő kommunikációból erednek. Az együttműködésből adódó hibák vizsgálatához több folyamatot kell vizsgálni, valamint a belső működés mellett a kommunikációt is ellenőrizhető formában kell ábrázolni. Dolgozatunkban bemutatunk egy módszert, amellyel lehetséges a BPEL 2.0 szabványnak megfelelő munkafolyamatok és a közöttük fennálló kooperáció modelljének formális analízise. Az együttműködő folyamatok vizsgálatát két szinten végezzük el, egyrészt a folyamatok közötti interakciót leíró, másrészt az egyes folyamatok belső működését ábrázoló modellen. A létrehozott modellekben a vizsgált folyamatokban szereplő konkrét adatokat nem-interpretált módon kezeljük (például a változók értékei helyett azok állapotát figyeljük). A kétszintű megközelítés lehetővé teszi, hogy az ellenőrzéseket különböző absztrakciós szinteken végezzük el, egy absztraktabb kooperációs modell és az egyéni BPEL folyamatokat precíz modellje alapján. Módszerünket automatikus modelltranszformációk használatával implementáltuk, melyek gráftranszformációs technikákon alapulnak. Szabványos BPEL leírásokból állítunk elő származtatott formális modelleket. A dolgozatban ismertetjük a módszer korlátait, továbbfejlesztési lehetőségeit, valamint egy mintapéldán keresztül illusztráljuk a használatát. 5

6 6 TARTALOMJEGYZÉK

7 Abstract Nowadays, an increasing number of industrial companies tend to publish their services as web services on the Internet. Such services are sets of loosely coupled business processes, whose combination provide the new service. The most common way to define such processes is the Business Process Execution Language (known as BPEL). BPEL is an XML-based specification for describing the behavior of automated business workflows. The disadvantage of having loosely coupled components running on independent platforms is the loss of guaranteed service, reliability and availability. Thus the spread of web services triggered an imminent need for methods formally verifying separate and collaborating processes. Therefore precise and systematic methods are needed to help the engineer in developing robust business processes. The issue has forced the design of approaches based on non-deterministic automata and data flows. Techniques have also been developed to transform business processes into transition systems. By creating expressions of linear temporal logic we may define several criteria to be proved on these models by mathematical means. This method is called model-checking. Most of the existing solutions are unfortunately only capable of handling BPEL 1.1 processes. In 2007, BPEL 2.0 has been published to which there is still no proper solution checking on complex orchestrations. Moreover, examining a standalone BPEL process neglects a large set of errors caused by the interaction of processes. To detect errors of the orchestration of these processes, we suggest a combined multi-level method in order to check complex scenarios. We present a method to carry out formal verification of standalone and cooperating BPEL 2.0 processes. Cooperating BPEL processes will be examined on two levels. On the one hand we check the interaction between these processes (abstract level), on the other hand we will use the results of model checking of a single process(lower level) at the abstract level. We model values of variables in a non-interpreted way. The practical realization of our method is based on automatic model transformations implemented in the form of graph transformations. The input of our method is a standard BPEL description. In this work we demonstrate the usage of our tool on a case study example. Details and the limitations of our method and possibilities of further development are also discussed. 7

8 8 TARTALOMJEGYZÉK

9 1. fejezet Bevezetés A számítógépek elterjedése előtt hosszú ideig az adatokat papíron tárolták, ebből adódóan egy adott adaton egyszerre csak egy ember dolgozhatott. Hasonlóan, egy munkadarabon is egyvalaki dolgozott, ez szekvenciális munkavégzést vont maga után és hosszabb időt vett igénybe. Az informatikai rendszerek megjelenése lehetővé tette az adatok elektronikus tárolását és a párhuzamos hozzáférést, ezzel megnyílt a lehetőség a munka jobb hatásfokú végrehajtására, egymásra nem épülő részfeladatok párhuzamos elvégzésére. A számítógépek programozhatósága más módon is segíti a munkát, olyan tevékenységek esetén, amelyeket az esetek döntő többségében azonos módon kell végrehajtani, általában az emberi munkavégzés kiváltható automatizált programokkal vagy gépekkel. Az emberi hibák esélyének csökkentése mellett az emberi munkaerő által feladatonként elvégzendő munka is kevesebb. Motiváció. Az Internet elterjedése előtt a cégek által nyújtott szolgáltatásokat általában csak személyesen lehetett igényelni, ez olyan kiegészítő munkát jelentett, amely a szervezetek működését nehezítette és költségeiket növelte. A világháló megjelenésével létrejöttek olyan technológiák, amelyek segítségével üzenetek és adatok küldhetőek, ezek számos területen kihasználhatók szolgáltatások nyújtására, távoli elérésére vagy igénylésére. Az ilyen távolról elérhető és felhasználható, szabványos protokollokat használó szolgáltatásokat nevezzük webszolgáltatásoknak (Web Services, WS). A vállalati alkalmazások kialakulásával megjelent az igény az adatokon végzett feladatok minél integráltabb végrehajtására. Fontos volt, hogy a különböző programok által automatizáltan elvégzett feladatokat sorrendbe lehessen állítani és ez által egy folyamatot kialakítani. Az így kialakult munkafolyamatok egyrészt leírják a szolgáltatások közötti interakciót és információcserét, másrészt megadják a feladat vezérlési folyam gráfját. Ilyen folyamatok használhatóak vállalati alkalmazásintegrációban (Enterprise Application Integration) és vállalatok közötti automatikus adatcserében (Business-to-Business). A különböző megoldások közötti kompatibilitás megtartásáért a webszolgáltatások és munkafolyamatok leírására szabványok alakultak ki, ezekre példa a Web Services Description Language (WSDL) [9], és a dolgozatunkban is vizsgált Business Process Execution Language (BPEL) [3]. A BPEL szabvány 1.1-es verziója 2003-ban alakult ki, Business Process Execution Language For Web Services (BPEL4WS) [4] néven, létrehozásában részt vett az IBM, a BEA Systems, a Microsoft, a SAP AG, és a Siebel Systems. Az ipari résztvevők által is szükségesnek tartott javítások és kiegészítések szabványosítása után, az OASIS szabványosító szervezet 2007-ben adta ki a 2.0-ás változatot, Web Services Business Process Execution Language (WS-BPEL) néven. 9

10 10 FEJEZET 1. BEVEZETÉS Problémafelvetés. Bár az előzőekben említett szabványok útmutatásul szolgáltak ahhoz, hogy milyen módon lehet leírni egy munkafolyamatot és hogyan lehet publikálni webszolgáltatásként, azt nem definiálták pontosan, hogy milyen elveket kell figyelembe venni egy munkafolyamat tervezésekor. Az esetek jelentős részében előfordul, hogy a munkafolyamatokban külső szolgáltatások kerülnek felhasználásra. Sok esetben nem lehetünk meggyőződve a használt szolgáltatások megbízhatóságáról valamint hibamentes működéséről, ennek következtében az általunk nyújtott szolgáltatás megbízhatóságát is nehéz garantálni. A munkafolyamatok tervezésekor a használt szolgáltatások megbízhatóságán kívül fontos a folyamat helyes viselkedése is. Szükséges lehet, hogy meg tudjuk állapítani, hogy van-e felesleges munkavégzés a folyamatban, vagy például olyan információt használnánk fel, amely az olvasás pillanatában még nem létezik. Továbbá hasznos, ha meg tudjuk mondani, hogy melyek azok a hibák, amelyek bekövetkezhetnek, de a folyamat nincs felkészülve a kezelésükre. Ezeket az ellenőrzéseket végrehajthatjuk manuálisan is, de praktikusabb, ha automatikus ellenőrzést tudunk biztosítani, lehetőleg formálisan verifikáció segítségével, amely bizonyítottan helyes eredményt ad. Az önálló munkafolyamatok vizsgálata sok esetben hasznos információkkal szolgál, de még ennél is többet tudhatunk meg, ha az együttműködő folyamatokat egy egészként vizsgáljuk. Ebben az esetben lehetőség van olyan hibákat is megtalálni, amelyek csak a folyamatok közötti kommunikációt elemezve fedezhetők fel. Például megvizsgálható egy üzenet átvitele során keletkezett hiba, vagy éppen az üzenet sikertelen átvitelének hatásai. Ahhoz viszont, hogy folyamatok lazán csatolt egységét vizsgálhassuk, szükségünk van a használt folyamatok leírására is. Célkitűzés. A dolgozatban egy olyan módszert dolgoztunk ki, amellyel együttműködő és önálló folyamatok BPEL nyelvű leírása alapján matematikai precizitással ellenőrizhetjük azok működését. Célunk egy olyan megközelítés létrehozása, amellyel az ellenőrzés automatikusan végrehajtható és a felhasználó (például munkafolyamat tervező mérnök) számára átlátszó működést biztosít. Az ellenőrzéshez a tranzíciós rendszerek elméletét használjuk fel. Leírjuk azt a leképezést, amely a BPEL folyamatok leírását konkrét modellnek felelteti meg, továbbá azt a leképezést, amely az együttműködő folyamatok leírását felelteti meg absztrakt modellnek. Mindkét modellt a tranzíciós rendszer formalizmusa felett definiáljuk. A származtatott tranzíciós rendszerekkel szemben lineáris temporális logikai kifejezések formájában megfogalmazott követelmények teljesülését modellellenőrzés segítségével vizsgáljuk. Továbbá egy esettanulmányon keresztül bemutatjuk a módszer használatát és a tipikusan kiszűrhető hibákat. Az általunk kidolgozott módszer a következő alkalmazási lehetőségeket nyújtja: Önálló BPEL 2.0 folyamatok vizsgálata. Modellellenőrzés segítségével a folyamatok tulajdonságai ellenőrizhetők, továbbá ha a megfogalmazott kritérium nem teljesül, akkor a helytelen lefutás is megkapható. Kooperáló BPEL 2.0 folyamatok vizsgálata. Az említett kétszintű modellezés használatával az ellenőrzés hatékonyabban végezhető el, mint más triviális megoldások esetén. Hibaterjedés vizsgálata. Lehetőség van arra, hogy a munkafolyamatokban esetlegesen fellépő hibák hatásait megfigyeljük. A hibák helyének megadását a módszer támogatja. Megközelítés. Az ellenőrzéshez használt modelleket modelltranszformációk segítségével állítjuk elő. A transzformációk végrehajtásához először létre kell hozni a vizsgált munkafolyamatok modelljeit. A transzformáció eredményeként létrejött tranzíciós rendszer modelleket kódgenerálás alkalmazásával alakítjuk tranzíciós rendszer leírássá. Az analízis modell leírásához a Symbolic Analysis Laboratory (SAL) [31] elnevezésű nyelvet használjuk. A transzformációk létrehozásához és futtatásához a Visual Automated Model Transformations (VIATRA2 R3) [5] gráftranszformációs

11 ábra. A módszer lépései keretrendszert használjuk. A VIATRA2 Eclipse alapú környezet, amely moduláris felépítésének köszönhetően könnyen kiterjeszthető további funkcionalitással. A megvalósítás során a következő feladatokat valósítottuk meg: Implementáltuk a folyamat modell létrehozását végző programot Kiegészítettük a VIATRA2 keretrendszert egy olyan Java nyelvű feldolgozóval, amely a BPEL 2.0 szabványt követő munkafolyamatok leírásából létrehozza a VIATRA2 modelltérbeli reprezentációjukat. Létrehoztuk a modellek előállításához szükséges transzformációkat. Ezek segítségével a folyamatmodellek alapján elkészíthetők a tranzíciós rendszer modellek. Végül a rendszermodellek alapján generálható a SAL rendszerleírás. Kritériumokat definiáltunk a modellellenőrzéshez. Az említett alkalmazási lehetőségek mindegyikéhez megadtunk olyan általános kritériumokat, amelyek munkafolyamatok viselkedésének vizsgálatához használhatók. A módszert valós esettanulmányon teszteltük. A dolgozatban bemutatott esettanulmány folyamatait modellező tranzíciós rendszer leírásokat létrehoztuk, és működésüket módszerünk alkalmazásával ellenőriztük. Fontos megemlíteni, hogy a dolgozatban a BPEL 2.0 verziójú szabványát megvalósító munkafolyamatokat vizsgálunk, továbbá nem csak önálló folyamatok működését ellenőrizzük, hanem együttműködő folyamatokat is. A módszer bemutatására használt mintapélda a Software Engineering for Service-Oriented Overlay Computers (SENSORIA) [30] projekt egyik esettanulmányának része, emellett a módszer integrálható a SENSORIA Development Environment (SDE) fejlesztési környezetbe, így a munkafolyamatok fejlesztésének és ellenőrzésének folyamata összeköthető. A SENSORIA egy EU Information Society Technologies (IST) projekt, a Global Computing Initiative (GC) részeként működő 6. keretprogramban (FP6). A projekt célja átfogó és újszerű szemléletmód kialakítása szolgáltatás-orientált architektúrák szoftver rendszereinek tervezéséhez, integrálva az alapvető elméleteket, technikákat és módszereket a gyakorlati fejlesztésbe. A dolgozat felépítése. Először egy rövid áttekintést adunk a munkafolyamatokról a 2. fejezetben (Munkafolyamatok). A modellellenőrzés elméletét ismertetjük a 3. fejezetben (Modellellenőrzés). Ezután a 4. fejezetben (BPEL 1.1 munkafolyamatok modellezése) bemutatjuk azt a modellezési megközelítést, amely a BPEL 1.1 alapú munkafolyamatok ellenőrzésére használható és módszerünk kiindulási pontja.

12 12 FEJEZET 1. BEVEZETÉS. Az 5. fejezetben (BPEL 2.0 munkafolyamatok modellezése) leírjuk, hogyan terjesztettük ki ezt a módszert BPEL 2.0 alapú munkafolyamatok ellenőrzéséhez. A 6. fejezetben (Kooperáló munkafolyamatok modellezése) részletezzük az általunk kidolgozott, kooperáló munkafolyamatok ellenőrzését lehetővé tevő modellezési módszert. Ezt követően a 7. fejezetben (Kooperáló BPEL 2.0 munkafolyamatok analízise) ismertetjük azokat a vizsgálatokat, amelyek segítségével a munkafolyamatok analízise elvégezhető. Végül a 8. fejezetben bemutatjuk, hogyan valósítottuk meg az ismertetett módszert. A dolgozat zárásaként összefoglaljuk és értékeljük a leírtakat.

13 2. fejezet Munkafolyamatok Egy cselekvéssorozatot, amely egy személy, csoport vagy gép végez el egy megadott módon, munkafolyamatnak nevezünk. A munkafolyamat általában egy összetett feladat végrehajtásának módját írja le. Ezek a feladatok sokfélék lehetnek, de közös bennük, hogy van valami dolog, amelyet a tevékenység végrehajtása létrehoz vagy megváltoztat, nevezzük ezt munkadarabnak vagy esetnek. Előfordulhat, hogy a munkadarab nem egy kézzelfogható tárgy vagy adat, hanem ezeknél absztraktabb, például hitelkérelem, vagy tantárgyfelvétel. Az összetettebb feladatoknak van eleje és vége, végrehajtása pedig az esetek többségében felbontható egyszerűbb, elemi tevékenységek sorozatára. A munkafolyamat leírásának fontos részei továbbá az elemi tevékenységek sorrendjét meghatározó feltételek is. Az általunk vizsgált technológiákban külső szemlélő számára a munkafolyamat általában egy webszolgáltatásként jelenik meg, amely valamilyen adatot vár a bemenetén és válaszul adatot ad vissza, ezen kívül a szolgáltatást használó számára nem látható hatásai is lehetnek a végrehajtásnak, például a tantárgyfelvétel esetén a rendszerben tárolásra kerül a felvett kurzus ábra. BPEL mint webszolgáltató és felhasználó [7] Fontos, hogy a munkafolyamatok képesek egymás között is kommunikálni, egymás szolgáltatásait használni, ez teszi lehetővé a komplex üzleti folyamatok létrehozását. Az együttműködéshez egyrészt szükség van egy szabványos, akár gépek számára is feldolgozható szolgáltatás leírásra, továbbá szükséges egy szabványos szolgáltatás nyilvántartó rendszer. A kommunikáció szabványos struktúrájú üzenetek segítségével történik. A munkafolyamatok létrehozásához használt technológiák bemutatását a webszolgáltatások be- 13

14 14 FEJEZET 2. MUNKAFOLYAMATOK mutatásával kezdjük, majd a BPEL munkafolyamat leíró nyelvet ismertetjük Motivációs példa A dolgozatban módszerünk bemutatásához egy esettanulmányt fogunk felhasználni. A példánkban két különböző egyetem információs rendszerének oktatási és adminisztrációs moduljai szerepelnek, a példa egy lehetséges megvalósítást mutat be ahol a feladat hallgatói kérelmek elbírálása annak érdekében, hogy egy hallgató egy adott kurzust ne a saját egyetemén, hanem egy másik egyetemen végezhessen el. Egy ilyen kérelem elbírálása során szükség van mind az oktatási, mind az adminisztrációs rendszerek különböző szolgáltatásaira, a feladat végrehajtása során a folyamatok kommunikálnak egymással. A mintapélda a SENSORIA projekt elosztott tanulmányi és kurzus menedzsment rendszert leíró esettanulmányának (elearning Case Study [15]) egy részfeladatát használja fel. A SENSORIA projekt célja a modellalapú fejlesztésre, ellenőrzésre használható módszerek kifejlesztése. A projekt keretében négy esettanulmány készült, amelyek közül három ipari alkalmazás. Az esettanulmányok között megtalálható egy telekommunikációs, egy autóipari, és egy pénzügyi témájú, továbbá az általunk is használt elosztott tanulmányi rendszer. Egy tanulmányi rendszer egyik fontos feladata a hallgatók kurzusjelentkezéseinek kezelése, amely összetett feladatot több együttműködő komponens végez el. Abban az esetben, ha egy hallgató egy kurzust nem a saját egyetemén kíván teljesíteni, akkor a két egyetem tanulmányi rendszereinek kooperációjára van szükség, melynek során a kurzus áthallgatási kérelmet elbírálják és tárolják. Az általunk mintapéldaként használt folyamatok a kurzus áthallgatási kérelem feldolgozását végzik el. Az öt folyamat összesen 47 elemi feladatból áll, amelyeket különböző vezérlési szerkezetek tartalmaznak. Az elemi feladatok közül 26 kommunikációs feladat. Az öt folyamat együttműködése 10 üzenet segítségével történik meg. A dolgozatban bemutatott módszer felhasználásával megvizsgáljuk a mintapélda folyamatait és kooperációjukat. Az egyes folyamatok esetén egyrészt az adatok tárolására használt változók helyes használatát ellenőrizzük, másrészt megnézzük, hogy a folyamatok minden esetben véget érnek-e. A folyamatok együttműködésének vizsgálatakor az üzenetváltásokat is figyelembe véve ellenőrizzük a teljes feladat lefutását. Megvizsgáljuk továbbá az elemi szolgáltatások hívása közben előforduló esetleges hibák hatását a teljes folyamat lefutására Webszolgáltatások A W3C szabványosító szervezet definíciója szerint a webszolgáltatás együttműködő számítógépek hálózat feletti pont-pont kölcsönhatásának támogatására tervezett szoftverrendszer. Interfészleírása gépek által feldolgozható formátumú (különösen a WSDL). A webszolgáltatás és más rendszerek közötti kölcsönhatás a webszolgáltatás leírása alapján történik, SOAP üzenetek felhasználásával, általában HTTP, felett XML sorosítás és egyéb webes szabványok használatával. [13] A webszolgáltatások működéséhez több különböző szabályrendszerre is szükség van, ezek a protokollok írják le, hogy milyen módon kell a szolgáltatásokat definiálni, implementálni, megtalálni, valamint hogyan tudnak kommunikálni egymással. Ezeket együttesen a webszolgáltatások protokollkészletének nevezzük. A webszolgáltatások protokolljait illusztrálja a 2.2. ábra. A protokollok bővebb ismertetése olvasható a Függelék fejezetében.

15 2.3. WEB SERVICES DESCRIPTION LANGUAGE (WSDL) ábra. Webszolgáltatások protokolljai 2.3. Web Services Description Language (WSDL) A webszolgáltatások egyik komoly előnye, hogy a szolgáltatások interfészének szintaktikai deklarációja és a szolgáltatások megvalósítása tisztán különválik. A szolgáltatások eléréséhez szükséges interfészleírást definiáló szabvány a WSDL, amely szintén XML alapú. Az interfész meghatározásakor meg kell adni az elérhető műveleteket, a műveletek be- és kimeneti paramétereit, valamint e paraméterek típusát, és a típusok definícióját. Előnye, hogy az újrafelhasználhatóság érdekében különválasztja a szolgáltatások és üzenetek absztrakt definícióját és a konkrét példányokat. Az együttműködő folyamatokat a szolgáltatásokban meghatározott szerepek betöltése alapján lehet összekapcsolni. A műveletek definiálásakor lehetőség van különböző üzenetváltási minták alkalmazására. Ezek a minták meghatározzák a művelet végrehajtása során használt üzenetek számát. Az alap WSDL szabványban csak az egyirányú (a szolgáltatás használója üzenetet küld a szolgáltatásnak, de választ nem vár) és a kérés-válasz (a szolgáltatás a kapott üzenetre választ is küld) minta használható. A WSDL struktúra támogatja az értesítés (a szolgáltatás üzenetet küld, amelyre nem vár választ) és a kérelem-válasz (a szolgáltatás üzenet küldése után választ is vár) mintát is, várhatóan az a specifikáció, amely definiálna protokollokat ezekhez, tartalmazná a használatukhoz szükséges WSDL szabvány kiegészítéseket is. A 2.1. részlet <? xml version ="1.0"? > < definitions name =" CourseChange " targetnamespace =" http :// eclipse. org / bpel / course "> <types > < schema targetnamespace =" http :// eclipse. org / bpel / course " xmlns =" http :// /2001/ XMLSchema "> < element name =" CourseChangeRequest " > < complextype > <sequence > < element name =" input " type =" string "/ > </ sequence > </ complextype > </ element > < element name =" CourseChangeResponse " > < complextype > <sequence >

16 16 FEJEZET 2. MUNKAFOLYAMATOK < element name =" result " type =" string "/ > </ sequence > </ complextype > </ element > </ schema > </ types > < message name =" CourseChangeRequestMessage " > < part name =" payload " element =" tns : CourseChangeRequest "/ > </ message > < message name =" CourseChangeResponseMessage " > < part name =" payload " element =" tns : CourseChangeResponse "/ > </ message > < porttype name =" CourseChange " > < operation name =" process "> < input message =" tns : CourseChangeRequestMessage " / > < output message =" tns : CourseChangeResponseMessage "/ > </ operation > </ porttype > < plnk : partnerlinktype name =" CourseChange " > < plnk : role name =" CourseChangeProvider " porttype =" tns : CourseChange "/ > </ plnk : partnerlinktype > </ definitions > Részlet 2.1. Az esettanulmány főfolyamatának szolgáltatás definíciója A WSDL szolgáltatás leírás gyökéreleme a definíciókat tartalmazó elem (definitions), ezen belül találhatóak a típus, az üzenet, a hozzáférési pont, és az összeköttetés definíciók. A típus (types) elemen belül deklarálhatjuk a szolgáltatás használatához szükséges adatstruktúrákat. Az üzenet (message) elemek definiálják a használt üzenetek felépítését. A hozzáférési pont (porttype) elem tartalmazza a művelet definíciókat, míg az összeköttetés (partnerlinktype) elem határozza meg az adott szolgáltatás elérhető funkcióit szerepek megadásával. A művelet (operation) elem adja meg egy adott üzenetváltás bemenő (input) és kimenő (output) paramétereit. Esetünkben kérdés-válasz típusú üzenetváltási mintát használ a művelet. Végül a szerep (role) elemek adják meg az adott összeköttetésben elérhető hozzáférési pontokat. Az összeköttetés és szerep elemek nem részei az alap WSDL szabványnak, hanem definiálásukhoz annak kiterjeszthetőségét használja fel a BPEL szabvány Business Processes Execution Language (BPEL) A BPEL nyelv webszolgáltatásokon alapuló munkafolyamatok definiálására használt XML alapú formátum. A munkafolyamatok működésének absztrakt leírásán kívül alkalmas futtatható folyamatok létrehozására is. E tulajdonsága hasonlatossá teszi hagyományos programozási nyelvekhez. A nyelv definíciója lehetőséget ad arra, hogy alkalmazási terület vagy munkafolyamat specifikus elemekkel egészítsük ki a szabványban meghatározott elemkészletet. A BPEL szabvány által definiált munkafolyamat leíró nyelvet az ipar számos résztvevője felhasználta üzleti folyamataik létrehozására, és a használat során több olyan igény is felmerült, amelyek az 1.1 verziójú szabvány felülbírálását igényelték. Ennek hatására jött létre 2007-ben a BPEL 2.0 verziójú szabványa, amelyben több helyen átdolgozták és kibővítették a munkafolyamat leíró nyelvet. A szabvány elemkészletének fontosabb részeit a 2.3. példán mutatjuk be. Fontos, hogy az ábra csak vizuális megjelenítése a valójában XML alapú szöveges leírásnak. Az ábrán nem szerepelnek olyan technikai részletek, amelyek a munkafolyamat futtatásához elengedhetetlenek, de a megértést nem segítik. Az ábra jobb oldalán a lehetséges tevékenységek és grafikus reprezentációik listája.

17 2.4. BUSINESS PROCESSES EXECUTION LANGUAGE (BPEL) ábra. BPEL Mintafolyamat A példában egy olyan folyamatot mutatunk be, mely egy tanulmányi rendszer kurzusáthallgatási kérelmeket feldolgozó szolgáltatásának egy részfolyamata. A beérkező kérés megvizsgálásra kerül, majd a vizsgálat eredményétől függően két különböző úton haladhat a végrehajtás. Ha az elágazás feltétele igaz, akkor a végrehajtás két párhuzamos ágon fut tovább. A folyamat futása válaszüzenet küldésével fejeződik be. Egy BPEL munkafolyamat-leíró dokumentum gyökere a <process> elem, ez tartalmazza a folyamat leírását. A gyökérelemben elhelyezkedő elemek sorrendje fontos, mert a feldolgozás általában szekvenciális, ezért az elemek definíciójának meg kell előznie az elemekre való hivatkozásokat. A gyermekelemek sorrendben a következők: <extensions>, <import>, <partnerlinks>, <variables>, <faulthandlers>, <eventhandlers>, <activity>. Az <extensions>, amely a használt kiegészítések definícióját tartalmazza, az <import>, amely a máshol dokumentált definíciók helyének megadására szolgál, a <partnerlinks> a munkafolyamat és más szolgáltatások közötti interakciót szabályozza, a <variables> a folyamaton belül felhasználható változók definícióját tartalmazza, továbbá a változók kezdőértéke is itt adható meg. A <faulthandlers> adja meg a folyamatszintű hibakezelők leírását, az <eventhandlers> a folyamatszintű eseménykezelőket tartalmazza, végül az <activity> egy referencia, amely a lehetséges tevékenységek csoportjára mutat. Az activity név egy gyűjtőfogalom amely a tevékenységek halmazát jelöli, olyan értelemben hivatkozunk rá, hogy azon adott helyen bármelyik tevékenység típus használható. A példában a tartalmazott tevékenység a Local Educational Workflow elem, a <process> elem nem kerül megjelenítésre. A lehetséges tevékenységek két típusát különböztetjük meg, az egyik az alaptevékenységek típusa, amelyek nem tartalmaznak további tevékenységeket, hanem általában elemi feladatokat hajtanak végre, a másik a strukturált tevékenységek típusa, amelyek összetett folyamatrészletek meghatározott végrehajtási szemantikával.

18 18 FEJEZET 2. MUNKAFOLYAMATOK Alaptevékenységek A folyamat elindulását a munkafolyamat által nyújtott szolgáltatás meghívása okozza, az így kapott üzenet fogadását végzi el a <receive> tevékenység. Attribútumai egyrészt megadják, hogy a munkafolyamat szolgáltatás definíciójának mely művelet meghívásakor hajtódik végre, továbbá a createinstance attribútum megadja, hogy létrejön-e új folyamatpéldány az üzenet érkezésekor. A példában a folyamat indulását a Receive Course Change Request jelzi, míg a futás közbeni üzenetfogadásra példa a Receive Answer from Admin WF elem. Az alaptevékenységek között kiemelkedő fontosságúak a webszolgáltatások nyújtásához és használatához kapcsolódók. Egy távoli webszolgáltatás hívása az <invoke> tevékenység segítségével történik, amelynek attribútumai megadják, hogy melyik konkrét szolgáltatást hívja meg. Szinkron hívás esetén a folyamat végrehajtása szünetel, amíg válasz nem érkezik, aszinkron esetben a folyamat továbbhalad az üzenet elküldése után. A példában ilyen tevékenység például a Check Student s Educational Status elem, amely olyan szolgáltatást hív meg, amely ellenőrzi a hallgató tanulmányi adatait. Általában a küldött üzenetek után a hívó fél válaszüzenetet vár a használt szolgáltatástól. Ezt a válaszüzenetet a <reply> tevékenység segítségével küldhetjük el. Sok esetben a munkafolyamat végrehajtása a válaszüzenet elküldésével véget ér. Mivel a példafolyamat aszinkron működésű, ezért a válaszüzenetet nem <reply>, hanem <invoke> elem küldi el, szinkron esetben a Send Confirmation to Admin WF elem lenne <reply> típusú. Szükség van egy olyan tevékenységre, amellyel összeállítható más tevékenységek bemeneti paraméterei és egyéb vezérlési információi. Az üzenetek és változók kezeléséhez szükség van egy tevékenységre, amely lehetőséget ad a másolásra és a módosításra. Az <assign> tevékenységben megadhatjuk, hogy mely üzenet vagy változórészeket kívánjuk másolni, módosítani vagy éppen törölni. Ilyen például a minta Fill Student Status Data elem, amelyben a kapott üzenet alapján állítjuk össze a később hívott szolgáltatás bemenő adatait. Amennyiben a végrehajtás során olyan szituáció lép fel, amelyben a munkafolyamat hibás állapotba került, a <throw> tevékenység segítségével utasíthatjuk a folyamatot hibakezelés indítására. Attribútumai meghatározzák a dobott hiba típusát és a hibás változó nevét, ezek alapján választja ki a munkafolyamat végrehajtó a használandó hibakezelőt. Amennyiben a hibakezelés során szükséges a hiba propagálása, erre a <rethrow> tevékenység használható. A hibakezelés módja emlékeztet az objektum-orientált nyelvek kivétel kezelési mechanizmusára, de a BPEL nyelvben a kivételt (exception) hibának (f ault) nevezik. Előfordulhat, hogy egy folyamatot futás közben meg kell szakítani, hogy a további végrehajtással járó lehetséges hibaterjedés ne következzen be. Ennek jelzésére használható az <exit> tevékenység, amely azonnal leállítja a munkafolyamat végrehajtását Strukturált tevékenységek A strukturált tevékenységek segítségével lehet összetettebb munkafolyamatok vezérlésfolyam gráfját létrehozni. A legegyszerűbb ilyen struktúra a szekvenciális végrehajtás, amelyet a BPEL <sequence> elemével adhatunk meg. Az elemen belüli tevékenységek a megadott sorrendben, egymás után hajtódnak végre. Példa erre a Send Reject to Admin elem. A <if> tevékenység segítségével feltételes elágazást hozhatunk létre, így a folyamat futása során a változók aktuális értéke alapján dönthetjük el, hogyan folytatódjon a végrehajtás. Az elágazáshoz megadhatunk feltételt, amely ha igaz, akkor a belső tevékenység hajtódik végre. Ha a feltétel hamis, a következő feltétel értékelődik ki, amely ha igaz, a hozzá tartozó tevékenység hajtódik végre. Végül megadható tevékenység arra az esetre, ha egyik feltétel sem teljesül. A példában ilyen tevékenység a Student Eligible for Course elem, melynek egy feltétele van, amely

19 2.4. BUSINESS PROCESSES EXECUTION LANGUAGE (BPEL) ábra. BPEL Mintafolyamat részlete: feltételes elágazás igaz értéke esetén az <if> elem nevével megegyező ág tevékenysége hajtódik végre, egyébként az Else ág. A 2.4. ábrán a mintafolyamat feltételes elágazásának tartalma látható. Esetenként szükség lehet egy megadott folyamatrészlet ismételt végrehajtására, ezt a procedurális programozási nyelvekhez hasonlóan ciklikus struktúrákkal tehetjük meg. A ciklusmagban megadott tevékenység addig ismétlődik, amíg a ciklushoz megadott feltétel igaz. Ilyen ciklikus végrehajtást tesz lehetővé a <while> tevékenység, ahol a feltétel vizsgálata a ciklusmag végrehajtása előtt történik, a <repeatuntil> tevékenység, ahol a feltétel vizsgálat a ciklusmag végrehajtása után történik. Ha a munkafolyamat végrehajtása közben olyan esetre kell felkészülnünk, hogy egy adott ponton több különböző üzenet érkezésére is lehetséges és a végrehajtás függ a beérkező üzenettől, akkor <pick> tevékenységet használhatunk. Ebben megadhatjuk, hogy egyes bejövő üzenettípusok esetén mi történjen, valamint időalapú figyelmeztetéseket is beállíthatunk, amelyek megakadályozzák, hogy egy folyamat végrehajtása megszakadjon azért, mert nem érkezik megfelelő üzenet. Sok esetben az elvégzendő feladatban találhatóak olyan részegységek, amelyek végrehajtása nincs szoros sorrendiségi függésben egymással. Az ilyen részegységek párhuzamos végrehajtására használható a <flow> tevékenység. Lehetőség van arra, hogy a párhuzamosan futó tevékenységek között függőségeket adjunk meg <link> elemek segítségével. A példában a Student Eligible for Course elem tartalmaz ilyen tevékenységet, amelynek Confirm with Admin és Call Remote Edu tevékenységei párhuzamosan hajtódnak végre, egy függőség adja meg azt a megkötést, miszerint a Call Remote Edu. WF tevékenység elindulása nem előzheti meg a Receive Answer from Admin elem befejeződését Hiba-, esemény-, kompenzáció-, és megszakításkezelés Előfordulhat, hogy egy összetett munkafolyamaton belül olyan műveleti hatókört szeretnénk kialakítani, amelyen belül külön változók, hibakezelők és eseménykezelők adhatók meg. Ehhez a <scope> tevékenység használható, amely sokban hasonlít a <process> elemre, funkcionalitása bővebb abból a szempontból, hogy megadható kompenzáció-kezelő és megszakítás-kezelő. Előbbivel a belső tevékenységek hatását lehet megszüntetni, amennyiben egy hiba miatt erre szükség van (BPEL 1.1-ben a <process> elemnek is lehetett kompenzáció kezelője, de a BPEL 2.0 ezt nem engedi meg), utóbbival pedig lehetőség van olyan folyamatrészlet megadására, amely abban az esetben fut le, ha a <scope> végrehajtását nem várt időben kell megszakítani. Ez biztosítja a <scope> futásának szabályozott leállítását.

20 20 FEJEZET 2. MUNKAFOLYAMATOK További kiegészítés, hogy BPEL 1.1-ben a kompenzáció-kezelőben ugyanaz a tevékenység szolgált az összes belső <scope> és egy konkrét <scope> kompenzáció-kezelőjének meghívására, ezt szétbontották, így a BPEL 2.0-ban egy cél <scope> esetén a <compensatescope> tevékenységet kell használni. A BPEL 2.0 szabvány több új tevékenységet is definiál, a <foreach> olyan strukturált tevékenység, amely egy <scope> elemet tartalmaz. Attribútumok segítségével adható meg, hogy hányszor hajtódjon végre a tartalmazott <scope>, és a végrehajtás soros vagy párhuzamos módon történjen. Megadható továbbá egy feltétel, amelynek igaz értéke esetén a <foreach> tevékenység azonnal véget ér. A feltétel kiértékelődik minden alkalommal, amikor a tartalmazott <scope> egy példánya befejeződik. A <validate> tevékenység segítségével futásidőben ellenőrizhetjük, hogy a változók megfelelnek-e a hozzájuk tartozó XML adatdefinícióknak. Jelentős többletmunkát igényelt a BPEL 1.1-ben az a korlátozás, hogy a tevékenységek bemeneti paramétereit és vezérlési információit csak <assign> tevékenység segítségével lehetett megadni. Ezt a problémát hivatott megoldani az Extensible Stylesheet Language Transformations (XSLT) és az XML Path Language (XPath) támogatásának bevezetése. Ez lehetővé teszi, hogy a munkafolyamatokat tömörebben fogalmazzuk meg. Végül megemlítendő, hogy a BPEL 1.1-el ellentétben a 2.0-ás szabvány előírja, hogy a munkafolyamat feldolgozó eszközöknek kötelező statikus analízist kell végrehajtaniuk a használt BPEL folyamatokon, ezáltal megakadályozva a szintaktikailag hibás folyamatok futtatását (Például egy linkhez csak egy kezdő és egy végponttal rendelkezhet). Dolgozatunkban feltételezzük, hogy a beadott folyamatokon ez a vizsgálat megtörtént, így azok szintaktikailag helyesek. A Függelék a alfejezetében összegyűjtöttük a szabványban szereplő szintaktikai szabályok egy részét Megkötések A formális verifikációhoz használt leíró nyelv korlátai és a modellellenőrzés probléma komplexitása miatt bizonyos megkötéseket kell tennünk a vizsgálható BPEL folyamatokra. Ezek a megkötések főként olyan folyamatrészleteket tartalmaznak, amelyek modellezéséhez dinamikus memóriakezelésre lenne szükség, amelyre a SAL leírás keretein belül nincs lehetőség. A vizsgált önálló folyamatok nem tartalmazhatnak olyan <scope> elemet, amely ciklikus tevékenységen belül található és van kompenzációkezelője. Ennek oka, hogy a BPEL által definiált kompenzációkezelés megköveteli, hogy a változók értékéről pillanatkép (snapshot) készüljön minden scope befejeződésekor. A kompenzáció során a végrehajtott tevékenységek a pillanatképben eltárolt változóértékeket használják. A pillanatképek dinamikus létrehozását a módszerünk nem támogatja. A vizsgált folyamat nem tartalmazhat olyan <foreach> tevékenységet, amely párhuzamos végrehajtású. Ilyenkor futásidőben dőlne el, hogy hány példányban kell végrehajtani a tartalmazott <scope> tevékenységet, amelyhez szintén dinamikus memóriakezelésre lenne szükség. Ciklikus tevékenység nem tartalmazhat <invoke> tevékenységet. A folyamatok közötti interakció vizsgálata során nem kezelünk ilyen folyamatokat, mert ebben az esetben a hívott folyamatból több példányra lenne szükség. Egy BPEL folyamatnak csak egy példánya vehet részt a kooperációban. Az előzőhöz hasonlóan, ilyenkor szintén dinamikusan kellene létrehozni a folyamatpéldányokat, amire a SAL nyelv keretein belül nincs lehetőség. A vizsgálat során nem kezeljük a korreláció alapú példányazonosítást. Mivel ez erősen támaszkodik a konkrét értékekre, míg a módszerünkben neminterpretált módon kezeljük az adatokat.

21 2.4. BUSINESS PROCESSES EXECUTION LANGUAGE (BPEL) táblázat. A BPEL1.1 és 2.0 által definiált tevékenységek Tevékenység Leírás Típus BPEL1.1 BPEL2.0 Receive Üzenetfogadás Egyfázisú alaptevékenység Reply Válaszüzenet küldés Egyfázisú alaptevékenység Invoke Szolgáltatás felhasználása Kétfázisú alaptevékenység Assign Adatmanipuláció Kétfázisú alaptevékenység Throw Hibadobás Egyfázisú alaptevékenység Exit Megszakítás Egyfázisú alaptevékenység Wait Várakozás Kétfázisú alaptevékenység Empty Üres tevékenység Egyfázisú alaptevékenység Rethrow Hiba propagálás Egyfázisú alaptevékenység Validate Változó validáció Egyfázisú alaptevékenység Compensate Teljes kompenzáció Egyfázisú alaptevékenység CompensateScope Scope kompenzáció Egyfázisú alaptevékenység Sequence Szekvenciális végrehajtás Strukturált tevékenység If Feltétel alapú elágazás Strukturált tevékenység While Elöl tesztelő ciklus Strukturált tevékenység RepeatUntil Hátul tesztelő ciklus Strukturált tevékenység ForEach Soros (ciklikus) és Strukturált párhuzamos végrehajtás tevékenység Pick Üzenet alapú elágazás Strukturált tevékenység Flow Párhuzamos végrehajtás Strukturált tevékenység Scope Korlátozott műveleti Strukturált hatókör tevékenység

22 22 FEJEZET 2. MUNKAFOLYAMATOK Az esettanulmány folyamatainak bemutatása A példában öt különböző üzleti folyamat szerepel. Ezek a főfolyamat, amely a kezdeti kérést fogadja és a kurzusáthallgatási kérelem feldolgozás szolgáltatást nyújtja a hallgató felé. A főfolyamat a helyi egyetem információs rendszerének oktatási modulján futó kurzusáthallgatási folyamattal (Local Educational Workflow, LEW) és az adminisztrációs modulján futó kurzusáthallgatási folyamattal (Local Course Administration Workflow, LCAW) is kapcsolatba lép. A LEW futása során használni fogja a távoli egyetem oktatási moduljának kurzusáthallgatási folyamatát (Remote Educational Workflow, REW), míg a REW végrehajtása során üzenetcserét folytat a távoli egyetem adminisztrációs moduljának kurzusáthallgatási folyamatával (Remote Course Administration Workflow, RCAW). A 2.5. ábrán a folyamatok együttes működése látható. Az egyes folyamatok leírásának grafikus reprezentációja a Függelékben található, a főfolyamat a ábrán látható, a LCAW folyamatot mutatja a ábra, a LEW folyamat a és ábrán található. A REW folyamat látható a ábrán, míg a RCAW folyamatot a ábra tartalmazza ábra. Az esettanulmány folyamatainak együttműködése A végrehajtás kezdetén a főfolyamat fogadja a kurzusáthallgatási kérelmet, majd egyidejűleg meghívja aszinkron módon a LEW-t és szinkron módon a LCAW-t, mindkettőnek elküldi a kérelem adatait. A LEW a kérelem alapján ellenőrzi a hallgató adatait, amennyiben megfelelőek, akkor aszinkron módon elküldi őket a LCAW-nek, majd megvárja a választ. A LEW elutasíthatja a kérelmet például akkor, ha a hallgatónak nem elég jó az átlaga. A LCAW ellenőrzi a hallgató adatait, majd a LEW-től kapott adatokat is figyelembe véve eldönti, hogy a helyi egyetemi oldalon engedélyezhető-e a kurzusáthallgatás, és az eredményt elküldi a LEW-nek. Az LCAW nem engedélyezi a kérést például abban az esetben, ha a hallgató adatai hiányosak. Ha engedélyezett a kurzusáthallgatás, akkor a LEW elküldi aszinkron módon a megfelelő adatokat a REW-nek. A REW fogadja az adatokat, majd ellenőrzi, hogy a kérelem elfogadható-e a távoli egyetem oldalán, amennyiben igen, akkor meghívja a RCAW-t, ellenkező esetben negatív választ küld a LEW-nek. A kérelem nem elfogadható például akkor, ha a kurzus betelt, vagy ha a hallgató tanulmányi eredményei nem megfelelőek. A RCAW eltárolja a kapott adatokat, majd visszaigazol a REW-nek és befejezi a futást, a REW ezután pozitív választ küld a LEW-nek és szintén befejeződik. A LEW a kapott adatokat eltárolja, majd megerősítést küld az LCAW-nek majd véget ér, a LCAW szintén eltárolja a megfelelő adatokat, majd visszaküldi a végleges választ a főfolyamatnak

23 2.4. BUSINESS PROCESSES EXECUTION LANGUAGE (BPEL) 23 és befejezi futását. A főfolyamat a válasz tartalma alapján pozitív vagy negatív választ küld a kérelmezőnek, ezzel a végrehajtás véget ér. Ebben a fejezetben bemutattuk a munkafolyamatok definiálásához szükséges szabványokat, továbbá röviden ismertettük a BPEL munkafolyamat leíró nyelv elemeit. Bevezettük azt a motivációs példát, amelyet a dolgozat során a módszer illusztrálására használunk. Végül a tanulmányi rendszer egy részfeladatát bemutató esettanulmány folyamatait és azok együttműködését ismertettük.

24 24 FEJEZET 2. MUNKAFOLYAMATOK

25 3. fejezet Modellellenőrzés Az előzőekben már bemutatott BPEL folyamatok vizsgálata során azt ellenőrizzük, hogy a folyamatok rendszere rendelkezik-e a kívánt tulajdonságokkal. Ez a modellellenőrzési probléma. A következő alfejezetekben bemutatjuk, hogy milyen matematikai módszerekkel lehet tulajdonságokat leírni, továbbá bemutatjuk, hogy miként írhatjuk le a munkafolyamatokat matematikai rendszerekkel, végül ismertetjük a modellellenőrzéshez használt keretrendszert Lineáris idejű temporális logika A munkafolyamatok tulajdonságainak leírására logikai kifejezéseket használunk, amely kifejezések nem csupán az elsőrendű logikában meghatározott konstansokat és változókat tartalmazhatják. A temporális logika szabályok és szimbólumok olyan rendszere, melynek segítségével ábrázolhatóak és következtethetőek idővel kapcsolatos tulajdonságok. Erre azért van szükség, hogy a munkafolyamatok működésének időbeliségét figyelembe tudjuk venni. A lineáris idejű temporális logika (LTL) kifejezései a Boole logikai operátorok mellett a temporális logika eszköztárát felhasználják. Az LTL esetén a logikai idő lineáris, az időpillanatok egy idővonal mentén követik egymást. A temporális operátorok erre az idővonalra vonatkoznak. Az LTL-ben kifejezhető például olyan formula, amely a jövő időpillanatokban bekövetkező állapotokra megadja, hogy egy adott feltétel szükségszerűen igaz lesz-e, vagy egy feltétel igaz, amíg egy másik tény igazzá nem válik. [28] Az LTL segítségével leírt tulajdonságokat diszkrét állapotokkal illetve akciókkal rendelkező rendszereken szeretnénk ellenőrizni, a jelen időpillanat az aktuális állapotot, a jövő időpillanatok pedig a rákövetkező állapotokat jelölik, tehát az egymás utáni időpillanatok az állapotok egymásutániságának felelnek meg. Az alábbiakban ismertetendő lineáris temporális logika kifejezéseit rendszerek futási útvonalain értelmezzük. Az útvonalakban az egymás utáni állapotok felelnek meg az idővonalon található időpillanatoknak. Megadjuk a rendszerindításnak megfelelő kezdő időpillanatot (kezdőállapotot), folyamatosan működő rendszer esetén a jövő pedig végtelen. Időpillanatok helyett a továbbiakban állapotokra fogunk hivatkozni. A LTL kifejezések atomi kijelentésekből, Boole logikai operátorokból és temporális operátorokból épülnek fel. Az atomi kijelentések tovább nem bonthatók, a rendszer állapotait címkézik, megadják azt az absztrakciós szintet, ahol a tulajdonságokat értelmezzük. A Boole logikai operátorok az (ÉS kapcsolat), (VAGY kapcsolat), és a (negálás). A temporális operátorokat az alábbiakban ismertetjük, az operátorokat p illetve q kifejezésekre vonatkozóan használjuk. 25

26 26 FEJEZET 3. MODELLELLENŐRZÉS F (Future) operátor: Az F p kifejezés jelentése valamikor p, vagyis egy jövőbeli állapotban igaz lesz a p kifejezés, de a bekövetkezésig eltelt idő nem végtelen. G (Globally) operátor: A G p kifejezés jelentése mindig p, azaz minden jövőbeli állapotban igaz lesz p (és igaz a jelen állapotban is). X (next time) operátor: Az X p kifejezés jelentése következő p, azt jelenti, hogy a következő állapotban igaz lesz p. U (Until) operátor: A p U q kifejezés jelentése p amíg q, azaz egy jövőbeli állapotban igaz lesz q, minden megelőző állapotban pedig igaz p. B (Before) operátor: A p B q kifejezés jelentése p mielőtt q", azaz p igaz egy jövőbeli állapotban és q csak később vagy sosem lesz igaz. A temporális operátorok intuitív jelentését útvonalak (idővonalak) segítségével ábrázolhatjuk, ahogy a 3.1. ábrán látszik ábra. LTL operátorok intuitív jelentése A LTL kifejezések segítségével leírt tulajdonságok több félék lehetnek, egy részük lokális, vagyis egy-egy aktuális időpillanathoz köthető, másik részük elérhetőségi, azaz a működés során jövőbeli időpillanatokra vonatkozik. Az elérhetőségi tulajdonságokat további kategóriákba soroljuk, ezek a biztonság és az élőség. A biztonsági tulajdonságok általában nemkívánatos, veszélyes, hibás helyzetek elkerülését írják elő. Ezért az ilyen tulajdonságokat legtöbbször G( p) kifejezések segítségével írhatjuk le, ez azt jelenti, hogy minden állapotban (időpillanatban) igaz, hogy a nemkívánatos helyzetet leíró p kifejezés hamis értékű. Az élőségi tulajdonságok tipikusan kívánatos helyzeteket adják meg, vagyis azt írják le, hogy a rendszer állapota valamely időpillanatban megegyezik egy konkrét állapottal. Az ilyen tulajdonságokat legtöbbször GF p vagy G(q F p) kifejezések segítségével írhatjuk le, előbbi azt adja meg, hogy a p kifejezés mindig igaz lesz valamelyik időpillanatban a jövőben, utóbbi pedig azt mondja ki, hogy mindig igaz, hogy ha q kifejezés igaz, akkor a jövőben valamelyik időpillanatban p igaz lesz.

27 3.2. TRANZÍCIÓS RENDSZEREK Tranzíciós rendszerek Az LTL modelljeként olyan struktúrát (formalizmust) használunk, amely egyszerű és matematikailag jól kezelhető. Ilyen struktúrára fogjuk megadni, milyen módszerekkel lehet egy kijelentés igazságát ellenőrizni. Ez az alapszintű matematikai struktúra szemantika alapján származtatható a mérnöki tervezéshez közelebb álló félformális modellekből is. [28] A tranzíciós rendszer leírásához meg kell adnunk a rendszer lehetséges állapotait, az állapotok közötti átmeneteket, és azokat az akciókat (feltételeket), amelyek az átmenetekhez rendelünk. Az aktuális állapotot általában nem egyetlen állapotváltozó segítségével írjuk le, hanem több állapotváltozó aktuális értékének kombinációjával. A lehetséges állapotok halmazát állapottérnek nevezzük. Az állapotváltozók számának és értékkészletük méretének növelésével az állapottér mérete könnyen olyan méretű lehet, amelynek kezelése triviális módszerek segítségével nem lehetséges, ezt a jelenséget állapottér robbanásnak nevezzük. Az átmenetek megadásának több módja van, ezek közül egy lehetőség, ha definiáljuk a konkrét kezdő- és végállapotot, amelyek között az átmenet vezet, másik lehetőség, ha feltételek segítségével leírjuk azt, hogy egyes állapotváltozóknak milyen értéket kell felvenniük az átmenet végrehajthatóságához, továbbá az átmenet végrehajtásakor milyen változások következnek be az állapotváltozók értékében. Az állapotátmeneti rendszerek formálisan egy (S, Act, ) hármassal adhatók meg, ahol: S = {s 1, s 2,..., s n }, az állapotok halmaza Act = {a, b, c,...}, az akciók (címkék) halmaza S Act S, a címkézett állapotátmenetek. Az állapotátmenetek szokásos jelölése: s 1 a s2 Ahhoz azonban, hogy az állapotátmeneti rendszereken az LTL formulákat értelmezni tudjuk, definiálnunk kell a π = (s 0, a 1, s 1, a 2, s 2, a 3,...) útvonalat, amely egy állapotsorozatot és az állapotok közötti akciókat írja le. Az LTL temporális operátorai az útvonalakra fognak vonatkozni. Összefoglalva, egy tranzíciós rendszer leírásához a következő három rész definiálása szükséges: Állapotváltozók: amelyek kombinációja megadja a rendszer aktuális állapotát. Őrfeltételes utasítások: amelyek leírják a lehetséges állapotátmeneteket. Kezdőállapot: amely leírja a rendszer állapotát az első időpillanatban. A 3.2. ábrán egy egyszerű tranzíciós rendszer látható. A körök az állapotokat jelölik, ahol a dupla kör (Initial State) jelenti a kezdő állapotot. A nyilak az állapotátmeneteket jelzik, a címkék az átmenetek mellett láthatóak A modellellenőrzési probléma Az előzőekben bemutatott lineáris temporális logikai kifejezések segítségével adhatjuk meg a tranzíciós rendszerek tulajdonságait. Azonban a rendszerek és tulajdonságok vizsgálatát többféle módon is el lehet végezni. A klasszikus logika kielégíthetőségi problémája azt vizsgálja, hogy van-e olyan rendszer, amelyre a kifejezés igaz lesz. Az igaz kifejezések keresésének problémája pedig azt adja meg, hogy egy kifejezés igaz-e minden rendszerre. Esetünkben adott egy rendszer és azt vizsgáljuk, hogy egy temporális logikai kifejezés igaz-e ezen a rendszeren, ezt modellellenőrzési problémának nevezzük.

28 28 FEJEZET 3. MODELLELLENŐRZÉS 3.2. ábra. Tranzíciós rendszer A modellellenőrzésnek két módja van, a globális modellellenőrzés során adott rendszer összes olyan állapotát keressük, amelyre a megadott kifejezés teljesül, ennek eredménye egy állapothalmaz. A lokális modellellenőrzés során a rendszer egy konkrét állapotára ellenőrizzük, hogy a vizsgált kifejezés igaz-e. Az ellenőrzés eredményeként vagy bizonyított, hogy a vizsgált kifejezés igaz, vagy egy ellenpélda formájában kaphatunk igazolást arra, hogy a kifejezés hamis. Azt az állapotot, amelyben a kifejezés hamissá válik, illegális állapotnak nevezzük. Az ellenpélda jól használható hibakeresésre is, mert megkapjuk azt az állapotátmenet sorozatot, amely az illegális állapotba vezet. A modellellenőrzés során már kisebb rendszerek vizsgálata esetén is összefuthatunk a tranzíciós rendszerek bemutatásakor már említett állapottér robbanás problémájával. A modellellenőrzéshez használt eszközök különböző megközelítéseket alkalmaznak az állapottér robbanás mértékének korlátozására és hatásának ellensúlyozására. Az egyik ilyen megközelítés a szimbolikus modellellenőrzés, amely a vizsgált rendszer viselkedését nem gráf formában ábrázolja, hanem kijelentéslogikai formulák segítségével implicit módon írja le. A vizsgálat végrehajtásához bináris döntési diagramokat (Binary Decision Diagram, BDD) használ. [22] Egy másik megközelítés a korlátos modellellenőrzés, mely a rendszer állapotátmeneti gráfját adott mélységig építi fel (bontja ki), és a kifejezés igazságtartalmát csak az adott mélységig vizsgálja. Átalakítások segítségével a modellellenőrzés problémáját visszavezeti a kielégíthetőségi (SAT) problémára. SAT problémának nevezik azt a feladatot, amikor egy adott logikai

29 3.4. SYMBOLIC ANALYSIS LABORATORY KERETRENDSZER (SAL) 29 formula változóinak olyan értéklekötését keressük, amelyek esetén a kifejezés igaz. A mélység korlát iteratív növelésével ismételt vizsgálatok során kizárhatók a kifejezés lehetséges megsértésének esetei. Az indukció használatával egyes kifejezések alacsony mélység korlát esetén is bizonyíthatóak. A részleges rendezés redukció (partial ordering reduction) megközelítés használata aszinkron rendszerek ellenőrzése esetén hasznos, mivel segítségével a konkurrensen végrehajtható állapotátmenetek összevonhatóak, amennyiben a végrehajtás sorrendje nem befolyásolja a végeredményt. Az absztrakció használatát előtérbe helyező megközelítés úgy próbálja kikerülni az állapottér robbanás problémáját, hogy egy kifejezés vizsgálatát a rendszer egy egyszerűbb (absztraktabb) változatán végzi el. Általában a rendszer absztrakt változata által teljesített tulajdonságok nem azonosak az eredeti rendszer tulajdonságaival, ezért a vizsgálat során szükség lehet az absztrakt modell finomítására Symbolic Analysis Laboratory keretrendszer (SAL) A modellellenőrzés elvégzéséhez szükség van egy olyan keretrendszerre, amely tartalmazza azokat az eszközöket, amik a vizsgált rendszer tulajdonságainak kiszámításához (szimbolikus analízis) szükségesek. Az általunk használt keretrendszer a Symbolic Analysis Laboratory (SAL), amely egyike az SRI International független kutatóintézet Számítástudományi Laboratóriuma által kifejlesztett automatikus verifikációhoz használható szoftver eszközöknek. A SAL keretrendszer kulcsfontosságú része az a közbenső nyelv, amely tranzíciós rendszerek leírására használható. Ez a nyelv használható olyan fordítók célnyelveként, amelyek más programozási vagy modellezési nyelvben leírt rendszerek tranzíciós rendszer leírását hozzák létre, továbbá forrásnyelvként különböző analízis eszközök meghajtásához. A SAL nyelv a tranzíciós rendszereket inicializáció és tranzíciós szabályok segítségével írja le. A SAL keretrendszerben többek között a következő eszközök találhatóak. A sal-wfc a SAL nyelvű leírások jól-formáltságát ellenőrzi, más SAL eszközök használata nem ajánlott, amíg a sal-wfc hibát jelez egy leírás esetén. A sal-smc BDD alapú szimbolikus modellellenőrző, véges állapotú rendszerek vizsgálatához. A sal-deadlock-checker holtpont kereső, amely a szimbolikus modellellenőrzőt használó kiegészítő eszköz. A sal-bmc SAT megoldón alapuló korlátos modell ellenőrző eszköz. Hiba és ellenpélda keresésen kívül alkalmazható k-indukció alapú verifikációhoz is. A sal-inf-bmc olyan korlátos modellellenőrző, amellyel végtelen állapotú rendszerek vizsgálata végezhető SMT megoldó segítségével. SAL leíró nyelv Ahogy az előző fejezetből kiderült, a SAL keretrendszer kulcsfontosságú része a tranzíciós rendszerek leírására használt nyelv, a következőkben egy példán keresztül mutatjuk be ennek a nyelvnek a struktúráját. A SAL nyelvben a rendszereket egy kontextus, vagyis rendszerkörnyezeten belül definiálhatjuk. A rendszerkörnyezet tartalmazza az állapotváltozókhoz használt típusok deklarációját, a rendszerleírást tartalmazó modulokat és a vizsgálni kívánt lineáris temporális logikai kifejezéseket. cc_root : CONTEXT = BEGIN scopestatetype : TYPE = { undertermination, faulthandling, running, skipped, notyetstartable, undercompensation, throwingfault, startable,

30 30 FEJEZET 3. MODELLELLENŐRZÉS END finished, compensated }; [...] process_ CourseChange : MODULE = BEGIN [...] END ; var_ used : THEOREM process_ CourseChange - NOT (F( var_input = writtenandread )); join_ fail : THEOREM process_ CourseChange - NOT (F( Process = throwingfault )); Részlet 3.1. SAL nyelvű leírás: rendszerkörnyezet A 3.1. példában szereplő scopestatetype egy felsorolásos típus, amely deklarálásakor megadjuk a lehetséges értékeket. A process_coursechange egy rendszermodul, amelyen belül a rendszer állapotváltozóit, állapotátmeneteit és kezdőállapotát adjuk meg. Definiálható olyan modul is, amely több más modul kompozícióját tartalmazza, ilyen kompozíció lehet aszinkron (amikor a modulok összes átmenete közül egyszerre csak egy hajtódhat végre) és szinkron (amikor egy állapotátmenet során minden modulban végrehajtódik egy átmenet). A var_used egy vizsgálni kívánt tulajdonság, amelyben megadjuk, hogy melyik rendszer modult vizsgáljuk és milyen LTL kifejezés igazságtartalmára vagyunk kíváncsiak. A megadott LTL kifejezések közül az első (var_used) azt jelenti, hogy nincs olyan állapotátmenet sorozat, amely során a var_input állapotváltozó writtenandread értéket vesz fel (vagyis az input BPEL változót a folyamat futása során soha nem olvassuk módosítás után). A második (join_fail) kifejezés azt írja le, hogy nincs olyan útvonal, amelyen a rendszer eljut egy olyan állapotba, ahol a Process változó értéke throwingfault (vagyis a folyamatban hiba keletkezett). A rendszermodulok leírása három részre osztható, ezek a változódeklarációk, a változó inicializáció és a tranzíciók. A változódeklarációs részben (a BEGIN után) a modulban használt állapotváltozók hatókörét, nevét és típusát adjuk meg. A változók hatóköre lehet globális, lokális, bemeneti és kimeneti, típusa pedig a típusdeklarációban definiált típusok egyike. A 3.2. részleten egy rendszermodul leírása látható. A változó inicializáció részben (az INITIALIZATION után) az állapotváltozók kezdőértéke adható meg. Végül tranzíciók leírása (TRANSITION rész) következik, amelyben az állapotátmeneteket írhatjuk le. Az átmeneteknek lehet neve, van egy őrfeltételük, amely meghatározza, hogy a rendszer milyen állapota esetén történhet meg az átmenet, és van értékadás rész, amely megadja, hogy az átmenet következtében hogyan változik a rendszer állapota (az állapotváltozók értéke). A részlet végén látható ELSE őrfeltételű tranzíció akkor tüzel, ha nincs más olyan tranzíció, ami tüzelhetne. Erre akkor van szükség, ha több rendszermodul szinkron kompozícióját használjuk, mert így elkerülhető a rendszerszintű holtpont kialakulása. rocess_ Local_ education : MODULE = BEGIN LOCAL CourseChange_ Process : scopestatetype LOCAL CourseChange_ sequence13 : sequencestatetype INITIALIZATION CourseChange_ Process = scopenotyetstartable ; CourseChange_ sequence13 = sequencenotyetstartable ; TRANSITION [ Process_ starts : ( CourseChange_ Process = startable ) --> CourseChange_ sequence13 = notyetstartable ; CourseChange_ Process = running ; [] [...] ELSE --> ]

31 3.4. SYMBOLIC ANALYSIS LABORATORY KERETRENDSZER (SAL) 31 ; END ; Részlet 3.2. SAL nyelvű leírás: rendszermodul Jelen fejezetben a lineáris temporális logika és a tranzíciós rendszerek elméletének bemutatása után a modellellenőrzés problémájával foglalkoztunk. Rámutattunk a modellellenőrzés jelentőségére és felsoroltuk azokat a megközelítéseket, amelyek segítségével a modellellenőrzés során jelentkező állapottér robbanás probléma hatása csökkenthető. Végül ismertettük azt a keretrendszert, amely tartalmazza a modellellenőrzés elvégzéséhez szükséges eszközöket, továbbá röviden bemutattuk a keretrendszer által használt tranzíciós rendszer leíró nyelvet.

32 32 FEJEZET 3. MODELLELLENŐRZÉS

33 4. fejezet BPEL 1.1 munkafolyamatok modellezése A 3.3. alfejezetben megmutattuk, hogyan lehet tranzíciós rendszerek tulajdonságait modellellenőrzés módszerével és lineáris temporális logikai kifejezések igazságtartalmának vizsgálatával ellenőrizni. A BPEL szabvány által definiált nyelv üzleti folyamatok leírására használható, míg az állapotátmeneti rendszerek elmélete egy formalizmus. Ahhoz, hogy egy munkafolyamat leírásból tranzíciós rendszert készítsünk, egyértelműen meg kell határozni, hogy az egyes nyelvi elemeket milyen tranzíciós rendszer részletekre képezzük le. A 4.1. alfejezetben először a változók adatmodelljét és az adatmanipulációkat ábrázoló átmeneteket írjuk le. Utána a 4.2. alfejezetben egyes tevékenységek állapotterét és a működésüket modellező átmeneteket ismertetjük, először az alaptevékenységeket, majd a 4.3. alfejezetben a strukturált tevékenységeket. Az itt leírt modellezési megközelítést Kovács Máté munkája alapján mutatjuk be. [19] [18] 4.1. Adatfolyam modellezése A folyamat vezérlésfolyama mellett fontos az adatfolyam modellezése is. A munkafolyamatokban használt változók tartalmazzák a teljes folyamat, továbbá az egyes tevékenységek be- és kimeneti adatait és vezérlési információit. Egy munkafolyamatban használt változók típusa lehet beépített típus (például egész szám, logikai változó, szöveg) vagy a munkafolyamat által használt webszolgáltatás specifikációkban meghatározott típusok bármelyike. Nem beépített típus használata esetén a változók tartalma egy XML fa, amelynek struktúrája definiálható lokálisan vagy származhat egy hivatkozott WSDL specifikációból is. A munkafolyamatot leíró SAL rendszerben minden BPEL változót egy állapotváltozó segítségével fogunk ábrázolni, ennek az állapotváltozónak az értéke a változó eredeti értéke helyett a változó állapotát fogja tárolni Ezt a megközelítést nem-interpretált modellezésnek nevezzük. A változóknak állapota lehet inicializálatlan (Uninitialized), ha még nem fért hozzá egy tevékenység sem, csak írt (Written), ha egy tevékenység csak módosította a tartalmát, olvasott (Read), ha egy tevékenység csak olvasta a tartalmát. Továbbá külön állapot jelöli, ha a változó írt és olvasott (WrittenAndRead), ha volt olyan tevékenység, amely módosította a tartalmát és később egy másik tevékenység olvasta a módosított tartalmat. Vizsgálataink során azt is figyelembe vesszük, hogy lehetséges, hogy egy tevékenység során a változóba hibás adat íródik, továbbá lehetséges, hogy ezt a hibás adatot egy másik tevékenység fel is használja (kiolvassa). Ennek ábrázolásához a változó állapotterében létrehozunk egy hibás állapotpartíciót, amelyben a hibásan írt (FaultyWritten) és a hibásan írt és olvasott (FaultyWrittenAndRead) állapotok szerepelnek. A hibás állapotpartícióból helyes adat írásának hatására lép ki a rendszer. 33

34 34 FEJEZET 4. BPEL 1.1 MUNKAFOLYAMATOK MODELLEZÉSE 4.1. ábra. Változók állapottere A 4.1. ábrán a változót reprezentáló állapotváltozó állapottere látható, az állapotok közötti átmeneteken fel van tüntetve, hogy minek a hatására következik be az állapotváltozás. Az adatmanipuláció modellezéséhez meg kell adnunk a változó olvasás, és a változó íráshoz tartozó értékadás kifejezéseket, amelyek a SAL átmenetek értékadás részére kerülnek. A változó olvasásához tartozó állapotváltozásokat a 4.1. ábráról leolvasva megadható, hogy az olvasás következtében adott aktuális állapot esetén mi lesz a következő állapot. A feltételes értékadást a SAL nyelvben úgy lehet leírni, hogy az állapotváltozó következő értékét az aktuális érték alapján egy feltételes struktúra segítségével adjuk meg. A 4.1. példán látható a változó olvasásához tartozó SAL leírás részlet. var_input = IF ( var_ input = read ) THEN Read ELSIF ( var_ input = written ) THEN writtenandread ELSIF ( var_ input = uninited ) THEN read ELSIF ( var_ input = faultywritten ) THEN faultywrittenandread ELSIF ( var_ input = faultywrittenandread ) THEN faultywrittenandread ELSE writtenandread ENDIF ; Részlet 4.1. SAL nyelvű leírás: változó olvasása A változó írásakor a következő állapot megadásánál különválasztjuk azt az esetet, amikor a vál-

35 4.2. ALAPTEVÉKENYSÉGEK MODELLEZÉSE 35 tozót egy konstans értékkel írjuk és azt az esetet, amikor egy másik változó tartalmát másoljuk a változóba. Az első esetben a változó írott állapotú lesz: var_output = Written;, a második esetben használt változó állapota alapján hibásan írt vagy írt lesz: var_adminrequest = IF ((var_input =FaultyWrittenAndRead)OR (var_input=read))then FaultyWritten ELSE Written ENDIF; Alaptevékenységek modellezése Alaptevékenységek neveztük azokat a tovább nem bontott tevékenységeket, amelyek a munkafolyamatokban az adatokat manipulálják, míg a strukturált tevékenységek felelősek a munkafolyamat vezérlésfolyamának kialakításáért. A BPEL sok alaptevékenységet definiál, ezek modellezésekor azonban több hasonlóságot is találni lehet, amelyek megkönnyítik a tranzíciós rendszerbe való leképezés megadását. Így például minden tevékenységnél megegyezik az a mód, ahogy a változók manipulációját végzik, egyes tevékenységek csak olvassák a változókat, mások csak írják őket, és vannak olyanok, akik olvasást és írást is végrehajtanak. A modellezés során megkülönböztetünk egyfázisú és kétfázisú alaptevékenységeket. Az egyfázisú alaptevékenységek olyan tevékenységek, amelyek végrehajtáskor indítható állapot esetén feladatuk elvégzésével azonnal a befejezett állapotba kerülnek. A kétfázisú alaptevékenységek esetén megkülönböztetjük a tevékenység azon állapotát, amikor éppen fut, ezért indítható állapotból előbb futó állapotba lép, majd onnan befejezett állapotba. A 4.2. és a 4.3. ábrákon látható az egyfázisú és kétfázisú alaptevékenységek tipikus állapottere, valamint az általános átmenetek ábra. Egyfázisú tevékenység modellezése 4.3. ábra. Kétfázisú tevékenység modellezése

36 36 FEJEZET 4. BPEL 1.1 MUNKAFOLYAMATOK MODELLEZÉSE A 4.2. és a 4.3. ábrákon látható állapottér állapotait a SAL leírásban a tevékenységhez tartozó állapotváltozó értékei tárolják, az állapotátmeneteket pedig tranzíciók segítségével modellezzük. A 4.2. SAL leírás részlet egy általános egyfázisú tevékenység modellezéséhez szükséges elemeket mutatja be. Ezek a használt állapotváltozó típus, állapotváltozó deklaráció és inicializáció. Továbbá az állapotátmeneteket leíró tranzíciók definíciói. receivestatetype : TYPE = { notyetstartable, startable, finished }; [...] LOCAL receive : receivestatetype [...] receive = notyetstartable ; [...] sequences_ first_ activity_ triggered : ((( process = running ) AND ( receive = notyetstartable )) AND ( sequence = running )) --> receive = startable ; [] receive_ writes : ( receive = startable ) --> receive = finished ; Részlet 4.2. SAL nyelvű leírás: egyfázisú tevékenység modellezése A 4.2. részletben látható, hogy a tevékenység csak akkor kerülhet indítható állapotba, ha az őt tartalmazó strukturált tevékenységek megfelelő állapotban vannak. A példában az üzenetfogadó (receive) tevékenység egy szekvenciális tevékenységen (sequence) belül van, amelyet pedig a teljes BPEL folyamat leírás gyökéreleme (process) tartalmazza. Ahhoz, hogy az üzenetfogadás megtörténhessen, a szülő tevékenységeknek futó állapotban kell lenniük. Kétfázisú alaptevékenységek esetén az feladat elvégzése hosszabb ideig tarthat, ezért előfordulhat, hogy a végrehajtás megszakad a tevékenység futása közben. Ennek a tulajdonságnak a modellezéséhez szükséges a futó állapot felvétele. A 4.3. SAL leírás részlet egy kétfázisú tevékenység modellezéséhez szükséges deklarációkat és tranzíciókat mutatja be. invokestatetype : TYPE = { startable, notyetstartable, finished, read }; [...] LOCAL invoke : invokestatetype [...] invoke = notyetstartable ; [...] sequence_ next_ activity_ triggered : (( invoke = notyetstartable ) AND ( Process = running )) --> invoke = startable ; [] invoke_ reads : ( invoke = startable ) --> invoke = read ; [] invoke_ writes : ( invoke = read ) --> invoke = finished ; Részlet 4.3. SAL nyelvű leírás: kétfázisú tevékenység modellezése 4.3. Strukturált tevékenységek modellezése A BPEL munkafolyamatokban a strukturált tevékenységek segítségével lehet a vezérlésfolyam gráfot kialakítani. E tevékenységek közös tulajdonsága, hogy további tevékenységeket tartalmaznak, és típusuk megadja, hogy a tartalmazott tevékenységeket milyen sorrendben és hányszor kell végrehajtani. A tevékenységek szekvenciális végrehajtásához a sequence tevékenység használható, párhuzamos végrehajtáshoz a flow, feltételes elágazás létrehozásához az if, ciklikus végrehajtáshoz például a while. A scope tevékenységnek különleges szerepe van, segítségével létrehozhatunk csak

37 4.3. STRUKTURÁLT TEVÉKENYSÉGEK MODELLEZÉSE 37 a folyamat egy részére vonatkozó változókat, esemény-, hiba-, kompenzáció- és megszakításkezelőket. A strukturált tevékenységek állapottere a kétfázisú alaptevékenységek állapotteréhez hasonló, ám típusuktól függően az állapottér kiegészül további állapotokkal és egyes esetekben a strukturált tevékenység működésének modellezéséhez több állapotváltozó szükséges. A tevékenységek modellezésekor figyelembe kell venni, hogy egy adott tevékenység csak akkor kerülhet indítható állapotba, ha az őt tartalmazó strukturált tevékenységek megfelelő állapotban vannak (például egy feltételes elágazás második feltételének belső tevékenysége akkor kerülhet indítható állapotba, ha a feltételes elágazás tevékenység éppen fut és az első feltétel nem teljesült). A modellezés során ezt az információt a tranzíciók őrfeltételének kiegészítésével illesztjük be a rendszerünkbe, ennek konkrét megvalósítását az egyes tevékenységek modellezésének leírásakor részletesen ismertetjük Szekvenciális végrehajtás Egy munkafolyamat tervezésekor legegyszerűbb esetben feladatok egymás utáni végrehajtásával írjuk le az elvégzendő munkát. A BPEL szabványban az ilyen vezérlés leírására a sequence tevékenységet definiálták, ebben az esetben egy részfeladat akkor kezdheti el a végrehajtást, ha az őt megelőző részfeladat befejeződött. A modellezés során szükség van egy állapotváltozóra, amely a szekvenciális tevékenység állapotát tárolja. Továbbá olyan tranzíciókat kell létrehozni, amelyek indítható állapotba teszik a tevékenységeket, ha az őket megelőző tevékenység befejeződött ábra. Szekvenciális végrehajtás modellezése A 4.4. ábrán látható, hogy két tevékenységet tartalmazó szekvenciális tevékenység esetén négy tranzícióval modellezzük a végrehajtást. Az ábrán az állapotokat (State) körrel jelöljük, az állapotátmeneteket (Transition) a függőlegesen elnyújtott téglalapok reprezentálják. A folytonos nyilak az éleket (Arcs) jelentik, amelyek állapotváltozást eredményeznek, míg a pontozott nyilak az olvasóéleket (őrfeltételeket, Condition) jelképezik. Az első tranzíció futó állapotba helyezi a szekvenciális tevékenységet. Az első tartalmazott tevékenység akkor lép indítható állapotba, ha a szekvenciális tevékenység futó állapotban van. Az első tevékenység befejeződése esetén a következő tevékenység kerül indítható állapotba. Az utolsó tartalmazott tevékenység befejeződése esetén a szekvenciális végrehajtás is befejeződik.

38 38 FEJEZET 4. BPEL 1.1 MUNKAFOLYAMATOK MODELLEZÉSE Párhuzamos végrehajtás Egy feladat végrehajtásának gyakran kulcsfontosságú tulajdonsága a végrehajtási idő, minél kevesebb idő kell egy kérés kiszolgálásához, annál több kérést tudunk egy adott idő alatt kiszolgálni. Egy feladat elvégzéséhez szükséges időt hatékonyan lehet csökkenteni, ha az egymástól független részfeladatokat párhuzamosan hajtjuk végre. A BPEL munkafolyamatokban a párhuzamosan végrehajtható tevékenységeket egy flow tevékenységen belül helyezzük el. A párhuzamos végrehajtás modellezéséhez a strukturált tevékenység állapotváltozóján kívül definiálni kell azokat a tranzíciókat, amelyek a párhuzamos tevékenység futó állapota esetén a tartalmazott tevékenységeket is indítható állapotba teszi, továbbá a tartalmazott tevékenységek befejeződése esetén a párhuzamos tevékenységet is befejezett állapotba helyezi ábra. Párhuzamos végrehajtás modellezése A 4.5. ábra bemutatja a párhuzamos tevékenység modellezéséhez szükséges tranzíciókat. Ha a párhuzamos tevékenység futó állapotban van, akkor a tartalmazott tevékenységek indítható állapotba váltanak. Ha a tartalmazott tevékenységek befejeződtek, a párhuzamos végrehajtás is véget ér Feltételes végrehajtás Sok esetben a munkafolyamat végrehajtása közben az aktuális adatok alapján kell döntést hozni, amely eredményének függvényében a további végrehajtás eltérő lehet. A BPEL nyelv bemutatásakor említettük az if és a pick tevékenységeket, az előbbi segítségével változók tartalma vagy függvények eredménye alapján lehet feltételes elágazást létrehozni, az utóbbi esetében a következő érkező üzenet típusa alapján kerül kiválasztásra a megfelelő döntési ág. A feltételes tevékenységek modellezése esetén nem csak a tevékenységhez kell állapotváltozót felvenni, hanem minden egyes döntési ághoz definiálni kell egy állapotváltozót, amelynek értéke megadja, hogy az adott ágat választottuk-e. A működés modellezésekor több tranzíciót is definiálunk, amelyek a feltételes tevékenység indítását, a megfelelő ág kiválasztását, továbbá a kiválasztott ág befejeződése esetén a feltételes tevékenység befejezését kezelik. A 4.6. ábrán megfigyelhetőek egy feltételes elágazás modellezéséhez használt tranzíciók. Ha a feltételes tevékenység indítható állapotban van, akkor az első tranzíció hatására kerül futó állapotba. Az adatok nem-interpretált modellezése miatt a feltétel kiértékelést nemdeterminisztikus végrehajtás segítségével írjuk le. Ez azt jelenti, hogy két tranzíció azonos őrfeltétellel rendelkezik,

39 4.3. STRUKTURÁLT TEVÉKENYSÉGEK MODELLEZÉSE ábra. Feltételes elágazás modellezése így egy futás során véletlenszerűen választ közülük a SAL keretrendszer. A példában csak két döntési ág van, az egyik a feltételes tevékenység által tartalmazott tevékenység, a másik pedig az "egyébként" ág, mely akkor kerül végrehajtásra, ha egyik feltétel sem teljesül. A feltételes tevékenység akkor lép befejezett állapotba, ha a döntési ágak közül az egyik befejezett állapotban van Ciklikus végrehajtás Gyakran előfordul, hogy egy kérés kiszolgálása közben bizonyos részfeladatokat többször kell végrehajtani, például egy több árut tartalmazó kérés esetén a raktárnyílvántartást minden áru esetén megnézzük, hogy az adott áruból van-e raktáron. Az ilyen végrehajtás leírásához használhatóak a BPEL bemutatásakor már említett ciklikus tevékenységek. A ciklikus tevékenység által tartalmazott tevékenységet ciklusmagnak is nevezzük, míg a feltételt, amely értékének függvényében hajtódik végre a ciklusmag, ciklusfeltételnek nevezzük. A ciklikus tevékenységek modellezése során az állapotváltozó mellett olyan tranzíciókra van szükség, amelyek a ciklikus tevékenység indítható állapota esetén futó állapotba teszik azt, valamint a ciklusfeltétel függvényében indítható állapotba helyezik a ciklusmagot vagy befejezett állapotba a ciklikus tevékenységet. A feltételes végrehajtáshoz hasonlóan itt is nemdeterminisztikus döntés segítségével modellezzük a feltétel kiértékelést. A 4.7. ábrán egy elöltesztelő ciklikus tevékenység modellezését illusztráló tranzíciók láthatók. A ciklus indítható állapota esetén, ha a ciklusfeltétel igaz, ekkor a ciklusmagot végre kell hajtani, a ciklikus tevékenységet futó állapotba helyezzük. Amennyiben a ciklusfeltétel hamis, akkor a ciklusmag nem kerül végrehajtásra, a ciklus befejezett állapotba kerül. A ciklus futó állapota esetén, a ciklusmag indítható állapotba kerül, végül a ciklusmag befejezett állapota esetén ismét indítható állapotba vált a ciklus, ekkor újra következhet a már leírt feltételvizsgálat Korlátozott műveleti hatókörű tevékenység A BPEL leíró nyelv bemutatásakor írtunk a scope tevékenységről, amelynek segítségével korlátozott műveleti hatókört definiálhatunk, ahol külön változókat, esemény-, hiba-, kompenzáció-, és megszakításkezelőket definiálhatunk. Ennek a tevékenységnek a modellezésekor minden itt definiált

40 40 FEJEZET 4. BPEL 1.1 MUNKAFOLYAMATOK MODELLEZÉSE 4.7. ábra. Ciklikus végrehajtás modellezése változóhoz és az eseménykezelőkhöz egy külön állapotváltozót kell felvenni, továbbá az alapértelmezett lefutást leíró tranzíciók mellett a kezelők működését leíró tranzíciókat is létre kell hoznunk. A scope esetén a befejezett állapot további állapotokra bontható, annak függvényében, hogy a scope kompenzálható-e, továbbá külön állapotváltozók szükségesek ahhoz, hogy hiba esetén a hiba típusát és a hibát okozó változót tároljuk. Itt említjük meg, hogy a 2.4 fejezetben már bemutatott, a folyamat gyökerét képző process elemet is úgy modellezzük mint egy scope tevékenységet. Továbbá a modellezés során felveszünk még egy scope állapotváltozót, amely a munkafolyamat végrehajtásának legfelső szintjét jelképezi. Erre az elemre processhost néven fogunk hivatkozni. Az eseménykezelők bármikor elindulhatnak, amikor a scope futó állapotban van, a hibakezelők csak akkor indulhatnak el, ha a scope által tartalmazott tevékenységek valamelyike hibát dobott. A megszakításkezelő akkor hajtódik végre, ha a scope végrehajtását idő előtt megszakítják, a kompenzációkezelő akkor futhat le, ha a scope befejezett állapotban van és a folyamat végrehajtása a scope kompenzációját rendeli el. A 4.8. ábrán a scope modellezéséhez használt állapottér látható. A scope saját állapotváltozóján kívül definiálunk állapotváltozót az eseménykezelőkhöz, a scope befejezett állapotához, továbbá az esetleges hiba típusának és változójának tárolására. scope_ starts : ( scope = startable ) --> scope = running ; onevent = startable ; onalarm = startable ; catchs_sequence = skipped ; empty = notyetstartable ; [] scope_ activity_ triggered : ((( empty = notyetstartable ) AND ( scope = running )) AND ( Process = running )) --> empty = startable ; [] scope_ finishes : ((( Process = running ) AND ( empty = finished )) AND ( scope = running )) --> scope = finished ; scope_finished = finishedcomp ; Részlet 4.4. SAL nyelvű leírás: Scope alapműködés modellezése A scope alapműködését modellező tranzíciókat mutatja be a 4.4. részlet. Az első tranzíció a scope indítható állapota esetén hajtható végre, hatására az eseménykezelők engedélyezetté válnak és a scope futó állapotba lép. A második tranzíció a scope futó állapota esetén a tartalmazott tevékenységet állítja indítható állapotba. A harmadik tranzíció a tartalmazott tevékenység befejezett

41 4.3. STRUKTURÁLT TEVÉKENYSÉGEK MODELLEZÉSE ábra. Scope tevékenység állapottere állapota esetén a scope állapotát is befejezettre állítja és a befejezett állapot típusát kompenzálhatóra állítja. Azért teszünk különbséget a sikeres és a sikertelen befejezés között, mert kompenzáció csak sikeres befejezés esetén alkalmazható. onevent_ starts : (( onevent = startable ) AND ( scope = running )) --> onevent = running ; scope2 = notyetstartable ; [] onevent_ disables : (( onevent = startable ) AND ( scope = finished )) --> onevent = finished ; [] onevent_ activity_ starts : (((( scope2 = notyetstartable ) AND ( scope9 = running )) AND ( Process = running )) AND ( onevent = running )) --> scope2 = startable ; [] onevent_ activity_ finishes : (( onevent = running ) AND ( scope2 = finished )) --> onevent = finished ; [] catch_ catching_ withname : ((( scope_ FaultCont = joinfailure ) AND ( scope = throwingfault )) AND ( scope_ FaultVar = none )) --> catchs_sequence = startable ; scope = faulthandling ; scope_ FaultCont = none ; [] catch_ finishing : (( catchs_ sequence = finished ) AND ( scope = faulthandling )) --> scope_finished = finishednotcomp ; scope = finished ; Részlet 4.5. SAL nyelvű leírás: Scope kezelők modellezése A 4.5. részlet egy eseménykezelő és egy hibakezelő működését modellező tranzíciókat mutatja be. Az eseménykezelő egy adott üzenet érkezésekor vagy adott időtartam kivárása után indul el, modellezés szempontjából ez egy véletlenszerűen bekövetkező esemény, ezért a scope futása közben bármikor elindulhat. Az első tranzíció végrehajtása jelzi a véletlenszerű esemény bekövetkezését,

42 42 FEJEZET 4. BPEL 1.1 MUNKAFOLYAMATOK MODELLEZÉSE ekkor az eseménykezelő futó állapotba kerül. Az eseménykezelő letiltásra kerül, ha az őt tartalmazó scope befejeződik, ezt írja le a második tranzíció. A harmadik tranzíció az eseménykezelő által tartalmazott tevékenységet állítja indítható állapotba, míg a negyedik tranzíció a tartalmazott tevékenység befejezett állapota esetén az eseménykezelőt is befejezett állapotba helyezi. Az utolsó két tranzíció a hibakezelő működését modellezi, a tartalmazott tevékenység akkor kerül indítható állapotba, ha a scope végrehajtásakor hiba keletkezett és a hiba típusa és változója megfelelő értékű. Az ötödik tranzíció hatására a scope hibakezelés állapotba kerül, a tartalmazott tevékenység pedig indítható állapotba. Az utolsó tranzíció a tartalmazott tevékenység befejezett állapota esetén a scope állapotát befejezettre, a befejezett állapot típusát pedig nemkompenzálhatóra állítja. Az előzőekben bemutattuk azt a modellezési módszert, amely lehetővé teszi BPEL1.1 alapú munkafolyamatok modellellenőrzését. A módszer ismertetése során kitértünk az munkafolyamatok adatfolyamának modellezésére, továbbá leírtuk az alaptevékenységek és strukturált tevékenységek modellezésének módját. A modellezés részletezése közben illusztrációs ábrák és kódrészletek segítségével igyekeztünk a módszer megértését megkönnyíteni.

43 5. fejezet BPEL 2.0 munkafolyamatok modellezése A 4. részben bemutattunk egy lehetséges modellezési megközelítést, amely a BPEL 1.1 alapú munkafolyamatok modell-ellenőrzéséhez volt használható. Jelen fejezetben ezt a modellezési megközelítést egészítjük ki BPEL 2.0 alapú munkafolyamatokra. A következőkben először megmutatjuk, hogy miként lehet a BPEL 2.0 szabványban bevezetett tevékenységeket és változásokat a már megismert tranzíciós rendszer leírás segítségével modellezni. Elsőként a változó inicializáció modellezését írjuk le az 5.1. részben, majd az adatmanipuláció kiterjesztését mutatjuk be az 5.2. részben. Ezután a hibaterjesztés modellezésére térünk ki az 5.3. részben. Az 5.4. részben a megszakításkezelés leképezését részletezzük, végül az 5.5. részben a párhuzamos végrehajtás részleges sorrendezését megvalósító összeköttetések modellezését ismertetjük Változó inicializáció modellezése A BPEL 2.0 egyik újdonsága, hogy a változóknak kezdőértéket lehet adni. Ez megakadályozza, hogy a munkafolyamat hibás állapotba kerüljön amikor egy olyan változóhoz kíván hozzáférni, amelyet még nem írt egyik tevékenység sem. A kezdőérték megadása nem kötelező, ezért a munkafolyamat végrehajtása során továbbra is előfordulhat a nem inicializált változó miatt okozott hiba. Az 5.1. részleten látható a változók kezdőértékének megadási módja BPEL leírásban. < variable name =" var "> <from > <literal >12 </ bpws : literal > </from > </ variable > < variable name =" var2 "> <from variable =" var "/ > </ variable > Részlet 5.1. BPEL leírás: változó kezdőérték megadása A munkafolyamat végrehajtása során a változók kezdőértéket az őket deklaráló process vagy scope tevékenység elindulásakor kapnak. Ezt úgy modellezzük, hogy a tevékenység indulását modellező tranzíciót kiegészítjük a kezdőértékkel rendelkező változók írását modellező értékadás részlettel. Az adatfolyam modellezésének bemutatásakor már leírtuk, hogy a változóírás két típusát különböztetjük meg, a változóból másolást és az adott érték beírását. Ezek a változó kezdőértékének írásakor is különbözőek. 43

44 44 FEJEZET 5. BPEL 2.0 MUNKAFOLYAMATOK MODELLEZÉSE 5.2. Adatmanipuláció modellezése Az XPath kifejezések támogatásával a BPEL 2.0 szabvány lehetővé tette, hogy a tevékenységek bemeneti adatai és vezérlési információi manipulálhatók legyenek külön assign tevékenység beiktatása nélkül, a létező változók értékeit felhasználva. Az 5.2. részlet egy példát mutat arra, hogyan lehet adatmanipulációt végezni nem assign típusú tevékenység esetén. Az invoke tevékenység bemenete (a küldött üzenet) ebben az esetben nem egy külön deklarált változó, hanem a folyamatot indító kérés által tartalmazott adat. < invoke name =" Invoke "> <toparts > < topart part =" payload " fromvariable =" input " / > </ toparts > </ invoke > Részlet 5.2. BPEL leírás: adatmanipuláció Az implicit adatmanipuláció alkalmazása a modellezés szempontjából annyit jelent, hogy a BPEL folyamatleírás feldolgozása során meg kell keresni az adott tevékenység által használt változókat. A változó írást és olvasást modellező tranzíció részleteket be kell illeszteni a tevékenység megfelelő tranzíciójának értékadás részébe Hibaterjesztés A munkafolyamatok tervezése során előfordul, hogy egy scope belsejében keletkezett hiba lokális kezelésén túl a folyamat további futását is meg kívánjuk akadályozni azzal, hogy a kezelt hibát propagáljuk a szülő scope vagy process felé. Ehhez a hibakezelő futása közben a rethrow használható az éppen kezelt hibaüzenet módosítás nélküli továbbterjesztéséhez. Ha a végrehajtás egy rethrow tevékenységhez érkezik, akkor az aktuális hibaüzenetet változtatás nélkül megpróbálja lekezelni a szülő tevékenységben. Az 5.1. ábra illusztrálja a hibapropagálás műveletét ábra. Hibaterjesztés A rethrow tevékenység modellezéséhez azt az állapotátmenetet kell definiálni, amely a rethrow indítható állapota esetén hajtódik végre és a tevékenységet befejezett állapotba viszi. Az aktuális scope hiba típust és változót tároló állapotváltozó értékét adjuk át a szülő scope vagy process hasonló állapotváltozóinak. Továbbá a szülő scope vagy process állapotát módosítjuk, hogy a hiba keletkezését jelezzük. Az 5.3. részlet a rethrow tevékenység végrehajtását modellező tranzíciót mutatja be.

45 5.4. MEGSZAKÍTÁSKEZELŐ MODELLEZÉSE 45 rethrowing_ fault : ( rethrow = startable ) --> Process = throwingfault ; Process_ FaultVar = scope_ FaultVar ; rethrow = finished ; Process_ FaultCont = scope_ FaultCont ; Részlet 5.3. SAL nyelvű leírás: hibaterjesztés 5.4. Megszakításkezelő modellezése A munkafolyamatok futása közben megtörténhet, hogy egy aktív scope végrehajtását meg kell szakítani. A megszakításkezelő biztosítja, hogy ilyen esetben is lehetőséget adjunk a scope futásának szabályozott leállítására. A scope explicit leállítása a scope belsejében használt exit tevékenység segítségével tehető meg. A megszakításkezelő hívódik meg abban az esetben is, ha egy scope hibakezelőjének indulásakor egy tartalmazott scope futó állapotban van, vagy ha a párhuzamos végrehajtású foreach tevékenység megszakítja a tartalmazott futó scope tevékenységeket amikor a befejezési feltétele igaz lesz. A megszakításkezelőhöz tartozó scope befejeződése után a megszakításkezelő már nem hajtódhat végre. Az 5.2. ábrán látható a megszakításkezelő engedélyezése az exit tevékenység használatával ábra. Megszakítás kezelő A megszakításkezelés modellezéséhez egyrészt az exit tevékenység működését, másrészt a megszakításkezelő végrehajtását kell állapotváltozók és tranzíciók segítségével leírni. A megszakításkezelés egy új állapot a scope estén is, ezért ezt felvesszük az állapotváltozója értékkészletébe. Az exit tevékenység modellezése az egyfázisú tevékenységeknél megismert módszert követi. A végrehajtást jelképező tranzíciót ki kell egészíteni a scope állapotváltozójának állításával. A megszakításkezelő működésének modellezéséhez a hibakezelők esetén már ismertetett módszer alkalmazható. Ha a scope megszakításkezélés állapotba kerül, akkor a megszakításkezelő által tartalmazott tevékenységet indítható állapotba tesszük. Ha a tartalmazott tevékenység befejeződött, akkor a scope is befejezett állapotba kerül, a befejezett állapot típusa nem kompenzálható lesz (csak sikeres lefutású scope kompenzálható). Az 5.3. ábra az exit tevékenység és a megszakításkezelő működését illusztrálja Flow linkek modellezése A 4.3. fejezetben bemutattuk a párhuzamos végrehajtás modellezésének módszerét. A BPEL lehetőséget ad arra, hogy a párhuzamos végrehajtású ágak tevékenységei között sorrendi összeköttetéseket adjunk meg. Ez azt jelenti, hogy megadható, hogy az egyik ág adott tevékenysége nem kezdődhet el addig, amíg a másik ág adott tevékenysége befejezett állapotba nem kerül. A BPEL

46 46 FEJEZET 5. BPEL 2.0 MUNKAFOLYAMATOK MODELLEZÉSE 5.3. ábra. Megszakításkezelés modellezése szabvány az ilyen kapcsolatokat linkeknek nevezi. Minden linknek egy kezdő és egy végpontja lehet (mindkettő egy tevékenység), viszont egy tevékenységnek több kimenő és több bemenő éle is lehet. A linkek használata korlátozott, a korlátok a statikus analízist részletező táblázatban olvashatóak a Függelék fejezetében. Az 5.4. ábrán egy linkeket tartalmazó flow tevékenység látható ábra. Párhuzamos végrehajtás részleges sorrendezése A linkek a sorrendi összeköttetésen túl engedélyezési információt is hordozhatnak. Egy link állapota tiltott (disabled), ha a linket definiáló flow tevékenység nincs futó állapotban. A flow tevékenység elindulásakor a hozzá tartozó linkek állapota határozatlan (unset) értékű lesz. Ha egy flow elemen belüli tevékenység kezdőpontja linknek, akkor a tevékenység befejeződésekor a link állapota felveszi a kezdőpontban megadott átviteli feltétel kiértékelésekor kapott értéket (igaz vagy hamis). Ha a flow tartalmaz olyan tevékenységet amely végpontja linknek, akkor a tevékenység csak akkor kerülhet futó állapotba, ha a bemenő linkjei mind igaz vagy hamis értéket kaptak és a linkekre megadott kapcsolódási feltétel kiértékelése után igaz értékű lesz. A feltétel hamis értéke

47 5.5. FLOW LINKEK MODELLEZÉSE 47 esetén a folyamat kapcsolódási hibát dob. A további végrehajtás attól függ, hogy a kapcsolódási hibák elnyomásra kerülnek-e, ez a BPEL folyamatban globálisan és lokálisan is definiálható. Ha az adott tevékenység esetén a hiba elnyomásra kerül, akkor a tevékenység nem kerül végrehajtásra, ellenkező esetben hiba keletkezik (típusa joinfailure) amelyet a szülő scope lekezel Tevékenységek kihagyása Ahogy már említettük, a linkek alkalmazása esetén előfordulhat, hogy egy tevékenység nem hajtódik végre. Ennek a működésnek a modellezéséhez szükség van a tevékenységekhez tartozó állapotváltozók értékkészletének kibővítésére. Felvesszük a kihagyott (Skipped) állapotot, amely azt jelzi, hogy az adott tevékenység nem hajtódott végre. Az 5.5. ábrán látható a kibővített állapottér egy példa tevékenység esetén ábra. Tevékenységek kibővített állapottere Linkek állapottere Jelen alfejezet bevezető részében ismertettük a linkek lehetséges állapotait. Az állapottér modellezéséhez gyűjtsük össze ismét az állapotokat és azokat az állapotátmenetek, amelyek a végrehajtás során előfordulhatnak. A link állapota a munkafolyamat futásának kezdetén letiltott (disabled). A linket definiáló flow tevékenység elindulásakor az állapot határozatlan (unset) lesz. A link kezdőpontját képző tevékenység lefutása után a link igaz (true) vagy hamis (false) értéket vesz fel. A flow tevékenység befejeződésekor a definiált linkek állapota ismét letiltottra vált. Az 5.6. ábra illusztrálja a link állapotterét. A linkek viselkedésének modellezéséhez egyrészt definiálni kell a szükséges állapotváltozó típust a SAL leírásban, másrészt minden linkhez szükséges egy állapotváltozó deklaráció és inicializáció. Továbbá az állapotátmenetekhez tartozó tranzíciókat ki kell egészíteni a linkek állapotának kezelésével. Az 5.4. részlet bemutatja egy link modellezéséhez szükséges deklarációkat, továbbá a flow indulását és befejezését jelző tranzíció linkekkel kiegészített változatát. A linkek működésének bonyolultsága miatt a szükséges további tranzíciókat később mutatjuk be.

48 48 FEJEZET 5. BPEL 2.0 MUNKAFOLYAMATOK MODELLEZÉSE 5.6. ábra. Link állapottere INITIALIZATION link1 = disabled ; link2 = disabled ; [...] flow_ starts : ( flow = startable ) --> link1 = unset ; link2 = unset ; flow = running ; flow_ finishes : ( activity1 = finished ) AND ( activity2 = finished ) AND ( flow = running ) --> flow = finished ; link1 = disabled ; link2 = disabled ; Részlet 5.4. SAL nyelvű leírás: linkek Átviteli és kapcsolódási feltétel modellezése A linkek értéke akkor lesz határozott (igaz vagy hamis), ha a kezdőpontjukat képző tevékenység befejeződik. A kezdőpontban megadható minden linkhez egy átviteli feltétel, amely a tevékenység befejezésekor kiértékelődik és az eredmény lesz a link értéke. Előfordulhat, hogy az átviteli feltétel kiértékelésekor hiba keletkezik, ebben az esetben a link értéke nem változik és az adott tevékenység további linkjei sem kapnak értéket. Ha egy linkhez nincs átviteli feltétel definiálva, akkor értéke igaz lesz a tevékenység befejeződése után. Az 5.5. részlet a BPEL leírásban a feltétellel rendelkező és feltétel nélküli kimenő linkre is mutat példát. <assign > <sources > < source linkname =" link ">

49 5.5. FLOW LINKEK MODELLEZÉSE 49 < transitioncondition >P: gettranscondvalue () </ transitioncondition > </ source > < source linkname =" link2 "/ > </ sources > [...] </ assign > Részlet 5.5. BPEL leírás: átviteli feltétel Az átviteli feltétel esetén is nem-interpretált modellezést használunk, ez azt jelenti, hogy ha meg van adva ilyen feltétel, akkor a modellezett rendszerben két konkurrens tranzíciót definiálunk, egyik esetben igaz, másik esetben hamis értéket kap a link. Ha nincs feltétel megadva, akkor mindenképpen igaz lesz a link értéke. Az 5.6. részleten mindkét fajta tranzíció megfigyelhető. assign_ writes : ( assign = read ) --> assign = finished ; link = true ; [...] assign_ writes_ transc_ true : ( assign = read ) --> assign = finished ; link = true ; assign_ writes_ transc_ false : ( assign = read ) --> assign = finished ; link = false ; Részlet 5.6. SAL nyelvű leírás: átviteli feltétel Ha egy tevékenység rendelkezik bemenő linkekkel, akkor minden ilyen linknek határozott értéket kell kapnia mielőtt a tevékenység végrehajtása megtörténhet. Lehetőség van megadni a bemenő linkekre egy kapcsolódási feltételt, amely olyan logikai kifejezés, amelyben csak a bemenő linkek értéke és a logikai operátorok (ÉS, VAGY, NEM) használhatóak. Ha nincs ilyen feltétel definiálva, akkor a bemenő linkek közül legalább egynek kell igaz értékűnek lennie ahhoz, hogy a tevékenység elkezdődhessen. Ha nincs feltétel és minden bemenő link értéke hamis, vagy van feltétel és értéke hamis, akkor a munkafolyamatban joinfailure típusú hiba keletkezik. A munkafolyamat tervezésekor lehetőség van megadni azokat a tevékenységeket, amelyeken belül ez a típusú hiba elnyomásra kerül, vagyis a szülő scope hibakezelője nem hívódik meg. Ha a hiba olyan tevékenység esetén keletkezik, ahol a hibát el kell nyomni, akkor hibajelzés helyett a tevékenység nem hajtódik végre, és a tevékenység kimenő linkjei hamis értéket kapnak. Ha egy tevékenység ilyen módon kihagyásra kerül, akkor szekvenciális szülő tevékenység esetén a szekvenciában következő tevékenység kerül indítható állapotba. Az 5.7. részletben egy kapcsolódási feltétellel rendelkező és egy feltétel nélküli tevékenység BPEL leírása látható. A második tevékenység esetén a hiba elnyomását vezérlő paraméter is meg van adva (suppressjoinfailure). <assign > <targets > < target linkname =" link1 "/ > < target linkname =" link2 "/ > </ targets > </ assign > [...] < invoke suppressjoinfailure =" yes " > <targets > < joincondition >\ $link1 and \ $link2 or \ $link3 </ joincondition > < target linkname =" link1 "/ > < target linkname =" link2 "/ > < target linkname =" link3 "/ > </ targets > </ empty > Részlet 5.7. BPEL leírás: kapcsolódási feltétel

50 50 FEJEZET 5. BPEL 2.0 MUNKAFOLYAMATOK MODELLEZÉSE A modellezés során a tevékenységek indítását kezelő tranzíciókat kell kiegészíteni a linkek kezeléséhez szükséges feltételekkel és értékadásokkal. Elsőként azt kell megvizsgálnunk, hogy egy tevékenységnek vannak-e bemenő linkjei. Ha van, akkor az indítási tranzíciót ki kell egészíteni. Ezután megnézzük, hogy van-e kapcsolódási feltétel definiálva, mert ha van, akkor a kapcsolódási feltételt fel kell dolgozni, és létrehozni a logikai kifejezés megfelelőjét a SAL leírásban. Ha nincs kapcsolódási feltétel, akkor létrehozzuk azt a kifejezést, amely akkor igaz, ha legalább egy link igaz és mindegyik értéke határozott, és azt a kifejezést, amely akkor igaz, ha mindegyik link értéke hamis. Végül a hiba elnyomását vezérlő paraméter függvényében hozzuk létre a két lehetséges tranzíciót amelyek a tevékenység indítható állapotában alkalmazhatóak. Az egyik tranzíció őrfeltételéhez hozzáadjuk a kapcsolódási feltétel igaz értékét leíró kifejezést, továbbá létrehozunk egy másik tranzíciót, amelynek őrfeltételéhez a kapcsolódási feltétel hamis értékét megadó kifejezést fűzzük hozzá. Az első tranzíció végrehajtása esetén a tevékenység elindulhat, míg a második tranzíció esetén a tevékenységet kihagyjuk (ha hibát el kell nyomni) vagy hibát dobunk (ha a hibát nem kell elnyomni). Az 5.8. részlet bemutatja a tranzíciók felépítését a különböző esetekben. Az első esetben sem kapcsolódási feltétel, sem hibaelnyomás nincs. A második esetben van feltétel és a hiba is elnyomható. assign_ reads : ( assign = startable AND ( link1 = true OR link2 = true ) AND link2 /= unset AND link1 /= unset --> assign = read ; [] assign_ failsjoin : ( assign = startable AND link12 = false AND link = false ) --> Process_ FaultVar = none ; Process = throwingfault ; Process_ FaultCont = joinfailure ; [...] invoke_ executes : ( invoke = startable AND ( link1 = true AND link2 = true OR link3 = true ) AND ( link1 /= unset AND link2 /= unset AND link3 /= unset ) --> invoke = finished ; [] invoke_ skips_ by_ links : ( invoke = startable AND NOT ( link1 = true AND link2 = true OR link3 = true ) AND ( link1 /= unset AND link2 /= unset AND link3 /= unset )) --> invoke = finished ; Részlet 5.8. SAL nyelvű leírás: kapcsolódási feltétel Az átviteli feltétel működésének ismertetésekor már utaltunk rá, hogy abban az esetben, ha a feltétel kiértékelése során hiba keletkezik, a link értéke határozatlan marad. Kivételt képez ez alól az az eset, amikor a link végpontja nem az aktuális scope által tartalmazott tevékenység. Az összes olyan linknek az értéke hamis lesz, amelynek végpontját nem tartalmazza az aktuális scope, és kiértékelésük egy másik link átviteli feltételének kiértékelése során keletkezett hiba miatt nem történt meg Holt utak eltávolításának modellezése Ahogy az előzőekben már utaltunk rá, a linkek használata esetén előfordul, hogy egy tevékenység végrehajtása nem történik meg, mert a kapcsolódási feltétel hamis, de a végrehajtás továbbhalad, mert a hibát elnyomtuk. Szintén előfordul, hogy egy tevékenység nem kerül végrehajtásra, mert például egy olyan döntési ágban helyezkedik el, amely egy adott futás során nem kerül kiválasztásra.

51 5.5. FLOW LINKEK MODELLEZÉSE ábra. Párhuzamos végrehajtás során tevékenységek kihagyásának hatása Eddig nem kellett ezekkel a tevékenységekkel foglalkozni, elég volt annyit tudni, hogy hatásuk nem fog érvényesülni. Képzeljük el azt a helyzetet, ha ez a döntési ág egy flow által tartalmazott tevékenységben van és van olyan link, amelynek kezdőpontja a döntési ágon belül van, de végpontja a feltételes tevékenységen kívül. Az 5.7. ábrán egy példa látható erre. Ebben az esetben az, hogy a tevékenység nem kerül végrehajtásra, maga után vonja, hogy a kimenő link nem kap értéket. Ha a link nem kap értéket, akkor a végpont tevékenység kapcsolódási feltétele nem vizsgálható és ennek következményeképp a tevékenység nem indulhat el. Ez a munkafolyamat futásának megakadását okozná, ami nem megfelelő viselkedés. A BPEL szabvány meghatározza, hogy azoknak a tevékenységeknek a kimenő linkjeit hamis értékűre kell állítani, amelyek biztosan nem kerülnek végrehajtásra egy adott lefutás során. Ilyenkor előfordulhat, hogy a link érték beállításának hatására egy másik tevékenység kapcsolódási feltétele kiértékelhető lesz. A kihagyott tevékenységek linkjeinek kezelése ezért egy iteratív folyamat, amely addig tart, amíg el nem jutunk egy olyan tevékenységhez, amelynek kapcsolódási feltétele igaz értékű. Ez a linkkezelési megközelítés a holt utak eltávolítása (Dead-Path-Elimination, DPE). A DPE működését két részre oszthatjuk, az egyik rész a nem végrehajtható tevékenységek megtalálása, a másik rész a kimenő linkek kezelése. Az első rész modellezéséhez meg kell vizsgálnunk azokat a helyzeteket, amikor egy tevékenység nem kerül végrehajtásra. A második rész modellezésekor össze kell gyűjteni az adott tevékenységhez tartozó kimenő linkeket, és ezeket hamis értékűre kell állítani akkor, ha a tevékenység bemenő linkjei határozott értékűek és a tevékenység már biztosan nem kerül végrehajtásra. A következő helyzetekben lehetséges, hogy egy tevékenység nem kerül végrehajtásra: Kapcsolódási feltétel hamis értékű és a hiba elnyomásra kerül Feltételes elágazás nem végrehajtott ágaiban helyezkedik el Pick tevékenység nem végrehajtott ágaiban helyezkedik el

52 52 FEJEZET 5. BPEL 2.0 MUNKAFOLYAMATOK MODELLEZÉSE Scope tevékenységen belül egy hiba keletkezési helye után vannak Nem végrehajtott hibakezelők és megszakításkezelő tartalmazza A tranzíciós rendszerünk modelljét tehát ki kell egészíteni úgy, hogy a felsorolt esetekben a tartalmazott tevékenységek állapotát kihagyottra állítsuk. Amikor a végrehajtás során egy tevékenység kihagyott állapotba kerül és a bemenő linkjei határozott értéket kapnak, a DPE működésével megegyezően a kimenő linkeket hamis értékűre állítjuk. Fontos, hogy ezt a lépést csak akkor tehetjük meg, ha a kimenő linkek értéke még határozatlan, ellenkező esetben a lépés ismételten végrehajtható lenne, ami ciklikus működést eredményezne a tranzíciós rendszerben. Ez pedig hibás eredményt okozhat a modellellenőrzés elvégzésekor. Az 5.8. ábrán illusztráljuk a DPE működését a modellezett rendszerben ábra. Holt utak eltávolításának modellezése Ebben a fejezetben részletesen ismertettük a BPEL 2.0 szabvány azon elemeit, amelyek a BPEL 1.1 szabványban még nem szerepeltek. Bemutattuk azokat a modellezési döntéseket, amelyeket a dolgozatban ismertetett módszer kialakításakor meghoztunk. Először a változók inicializációjának modellezését részleteztük, majd az adatmanipuláció és a hibaterjesztés működésének modellezési módját írtuk le. Ezután kitértünk a megszakításkezelés leképezésére, végül a párhuzamos végrehajtás vezérléséhez használt összeköttetések modellezését mutattuk be. Részletesen foglalkoztunk a linkek használatának következményeivel, továbbá azokkal a mechanizmusokkal, amelyeket szintén modellezni kell, ha módszerünkben az összeköttetések használatát támogatni kívánjuk. A jelen fejezetben leírt modellezési megoldások kidolgozása a dolgozatban bemutatott módszer kialakításának egyik létfontosságú része. A most leírtak segítségével nyílik lehetőség a BPEL 2.0 munkafolyamatok modellellenőrzésére. A következő fejezetben bemutatott absztrakt munkafolyamat kooperáció modell ellenőrzéséhez elengedhetetlen az önálló folyamatok vizsgálata BPEL modellezéséhez kapcsolódó munkák A 4 fejezetben bemutatott módszer természetesen nem az egyetlen lehetséges út BPEL folyamatok modellezésére. Röviden bemutatnánk, hogy milyen jelentős megoldások ismertek még. Bár a Petri-hálók egyfajta lingua franca a folyamatok modellezése terén, a Petri-hálók adottságaiból azonban két probléma következik. Egyrészről nagyon korlátozottak a modellel szemben támasztott kritériumok ellenőrzési lehetőségei. Rendszerint elérhetőség, élőség, korlátosság és fairség vizsgálata lehetséges az így előállított hálókon. A tranzíciós rendszerünk ezeknél a vizsgálatoknál doménspecifikusabb kritériumok ellenőrzésére is lehetőséget ad. Másrészt a BPEL-ben megtalálható elemek egy részének Petri-háló modellje olyan mértékű komplexitás-növekedést jelent, amely a teljesítmény rovására megy. Így például problémás a Scope elem, a hibák, az események és a kompenzáció kezelése, amelyeket tartalmaz a mi megoldásunk. Van der Aalst és Verbeek megoldása [33] le tudja képezni a lehetséges tevékenységek nagy részét, így a Linket is, de nincs Scope, hibakezelő és correlation kezelés. A BPEL szemantikát

53 5.6. BPEL MODELLEZÉSÉHEZ KAPCSOLÓDÓ MUNKÁK 53 szinte teljes egészében lefedi [14] illetve [32], kivétel ez alól csak a példányazonosító correlation. Utóbbi munkák segítségével immáron automatizálható módon alakíthatók BPEL folyamatok Petrihálókká. Az eddigiek bármelyikében használt változó modellezésnél precízebb adatmodellt kínál a megoldásunk. Egy másik figyelemreméltó megközelítés [34], amely a folyamatokat hierarchikus, színezett Petri-hálókra képezi le. Az utóbbi megoldás előnye, hogy annak hierarchizáltsága miatt az ellenőrzés ideje nagyságrenddel csökkenthető, hátránya, hogy szintén csak a Petri-hálók jellemző tulajdonságait tudja vizsgálni. A Petri-hálókkal történő modellezésre kialakított eszköz [27] jelenleg háromfajta ellenőrzést támogat: olyan elemek felderítése, amelyek sosem kapják meg a vezérlést; olyan üzenetfogadó tevékenységek párjait deríti fel, amelyek konfliktusban állnak; illetve olyan metaadatok előállítására alkalmas, amely segítségével kimutathatók feldolgozatlan üzenetek. Szintén népszerű megoldás a munkafolyamatok Promela modellbe történő transzformálása. Ide tartozik [19] előfutáraként tekinthető [17], illetve [24] és [25]. Előbbi változójának értékkészlete csupán a defined és undefined elemekből áll, az eljárás pedig nem fedi le a hibakezelést és a kompenzációkezelést. A mi megoldásunkban nem fellelhető kiegészítést tartalmaz [25]. Ebben Promela nyelvre fordított BPEL-ek adataihoz biztonsági szinteket rendelnek, így állapítható meg, hogy történt-e jogosulatlan-e egy adathozzáférés a folyamat során. Ez a kiegészítést nem célje dolgozatunknak, ám könnyedén integrálható az általunk elkészített modellbe. Ezek a megoldások a SPIN ellenőrzővel vizsgálják modelljeiket, amely a mi tapasztalatunk szerint teljesítmény szempontjából kevesebbet nyújt, mint a SAL modellellenőrző rendszer. Az eddig ismertetett munkák mindegyike a BPEL 1.1-es szabványának megfelelő BPEL folyamatok modellezését tűzte ki célul. A közelmúltban megjelent 2.0-ás szabványban található újdonságokat is lefedő megoldást nyújt [20]. Ez a módszer [32] egyfajta kiegészítésének tekinthető, így a modellezési eljárás azonos. Ebből adódóan a Petri-hálók adta lehetőségek hasolóan behatárolják a vizsgálhatóságot. Hozzánk hasonlóan [11] is tranzíciós rendszerrel modellezi a BPEL folyamatokat. Folyamatai még az 1.1-es szabványt követik, és nem kezel eseménykezelőket, kompenzációkezelőket, nem modellezi a változók értékkészletét, illetve nem tér ki dolgozatában az iterációban lévő Scope problémájára. Annak ellenére, hogy széles körben elfogadott szemlélet, hogy futási idő előtt célszerű a munkafolyamat modelljének ellenőrzése, mégis léteznek olyan kezdeményezések, amelyek futási időben próbálják megtalálni a hibát. Utóbbi eset is két részre osztható. Egyik rész igyekszik futási időben monitorozni[6]. A másik esetben igyekeznek olyan teszteseteket találni, amelyek implementációs hibákat lelnek meg, és nem tervezési hibákra mutatnak rá. Mi arra az álláspontra helyezkedtünk, hogy előnyösebb tervezési időben elvégezni a modellellenőrzést, így költséghatékonyabb megoldásokra van lehetőség.

54 54 FEJEZET 5. BPEL 2.0 MUNKAFOLYAMATOK MODELLEZÉSE

55 6. fejezet Kooperáló munkafolyamatok modellezése Dolgozatunk célja nem csak az előző fejezetben részletezett elméleten alapuló BPEL modellek készítése és formális verifikációja, hanem a BPEL folyamatokból felépülő hálózat modelljének ellenőrzése is, amit ebben az fejezetben taglalunk. Először, a 6.1. alfejezetben bemutatjuk, hogy mi a célunk a kooperáció modellezésével, majd a 6.2. alfejezetben részletezzük, hogyan állítottuk elő a kooperáció modelljét, azon belül is a pontban a finomító lépéseket Kooperáció modellezésének célja Az előző 5. alfejezetben azt vázoltuk, hogyan modellezünk az önálló BPEL folyamatokat, ahhoz hogy formálisan verifikálhassuk őket. Mivel a BPEL folyamatok web szolgáltatásokként érhetők el, általában nem egy önálló folyamat, hanem több BPEL folyamat egymással kommunikálva és együttműködve biztosít egy adott, komplex szolgáltatást. Ezért szükséges az izolált folyamatok modellellenőrzésén túl, több folyamat kooperációjának a vizsgálata is. Lehetséges hibákra és azok felderítésére a 7.2. alfejezetben térünk ki A kooperáció modellezése A korábbiakban bemutatott módon a kooperáció modellezésekor is minden BPEL folyamatnak megfeleltetünk egy véges állapotgépet. Egy naiv megközelítés lenne, ha a folyamatok kooperációja ezeknek a véges automatáknak a keresztszorzata lenne, amelyet kiegészítenénk azokkal az átmenetekkel és feltételeikkel, amelyek a kommunikációból adódnak. Ilyen módszerrel viszont már néhány folyamat együttműködése robbanásszerű növekedést jelentene az állapottérben, ami nem csak a teljesítmény és a kezelhetőség rovására menne, hanem teljességgel felesleges. Ehelyett azt a megközelítést választottuk, hogy a kooperáció modellezése során egy absztrakt folyamatot hozunk létre. Ebben az absztrakt modellben nem modellezzük a BPEL folyamatokat teljes egészében, hanem csak egy redukált modellt alkalmazunk. Az egyes BPEL-eknek ekkor csak a kommunikációban résztvevő tevékenységeit ábrázoljuk, illetve ezek kapcsolatát. Amíg az egymással kommunikációs kapcsolatban álló tevékenységek közötti viszony egyértelműen azonsítható, addig egy folyamat belső struktúrájáról semmit sem feltételezünk. Így egy folyamat tevékenységei között lévő precedenciáról sincsen információnk, ezért első lépésben a tevékenységek bármilyen szekvenciáját megengedjük. Ez a konkrét BPEL modellek felülről történő becslése. Ezzel azt tudjuk garantálni, hogy az absztrahált modell megőrzi a konkrét modell viselkedését. Az absztrahálásból adódóan viszont olyan tulajdonságok is igazak az együttműködés modelljére vonatkozóan, amelyek 55

56 56 FEJEZET 6. KOOPERÁLÓ MUNKAFOLYAMATOK MODELLEZÉSE a konkrét modellek alapján nem lehetségesek. Ezért ki kell szűrnünk a kooperáció modelljének azon részeit, amelyek nem részei a valódi viselkedésnek. Ez a lépés az absztrakt modell finomítása. Az absztrakt modellen iteratív módon hajtjuk végre a finomító lépéseket A folyamat modellje Első közelítésben csak annyit tudunk egy folyamatról, hogy milyen kommunikációs kimenetei illetve bemenetei vannak. Ehhez a modellhez tehát csak annyit kell tudnunk, hogy a folyamat hogyan kommunikál a külvilággal. A benne rejlő üzleti logikára nincsen szükségünk. Így olyankor is lehetőségünk van BPEL folyamatok közötti kommunikációt modelleznünk, amikor a BPEL tulajdonosa nem szeretné nyilvánosságra hozni folyamatának belső működését. Csak azt kell megadnia, hogy milyen kommunikáló tevékenységek és PartnerLinkek találhatóak meg benne, és azok attribútumait illetve az OnAlarm tevékenyégeket. 1 Ezek alapján megadható, hogy milyen kommunikációs lánc alakul ki a folyamatok között. A redukált BPEL-t leíró állományokból előállítjuk a folyamatcsonkok modelljét. Az előző pontban említett részeire van csupán szükségünk a leíró állománynak. A kooperáció modelljének kialakítása ezen folyamatcsonk modellek alapján történik. A modellező transzformáció minden egyes folyamatnak egy csomópontot feleltet meg. Majd kikeresi a BPEL folyamat kommunikációs tevékenységeit, úgy mint: Invoke, Receive, Reply, OnMessage, OnEvent és mindegyikhez egy kommunikációs portot rendelünk. A kommunikációs portok kétfélek lehetnek: input és output. Minden olyan kommunikációs tevékenységhez, amely fogad üzenetet, rendelünk egy input portot. Hasonlóan minden tevékenységhez, amely üzenetet küld valakinek, rendelünk egy output-ot. A kommunikációs portok segítségével fogjuk tudni létrehozni azokat a függőségetek, amelyek a kapcsolat jelent. Az alábbi táblázat foglalja össze azt, hogy milyen BPEL elemhez milyen portot rendelünk ábra. Absztrakciós ábra 1 Az OnAlarm tevékenység nem valódi kommunikációs tevékenység, mivel azonban szorosan kapcsolódik az input tevékenységekhez, ezért az egyszerűség kedvéért a dolgozatunkban a továbbiakban az OnAlarmot is kommunikációs tevékenységnek tekintjük.

57 6.2. A KOOPERÁCIÓ MODELLEZÉSE táblázat. BPEL tevékenységek megfeleltetése portoknak Tevékenység input output callback Invoke aszinkron Invoke szinkron Invoke Receive Reply OnMessage OnEvent 6.2. ábra. Absztrakt Invoke állapottere Egy olyan gráfban, ahol a folyamat minden kommunikáló tevékenységét egy csomópont és két ilyen tevékenység precedenciáját pedig egy irányított él jelenti, kezdetben tehát egy irányított teljes gráffal rendelkezünk. Minden automatikus vizsgálódás előtt azonban természetesen némi egyszerűsítést is végezhetünk. Ugyanis az biztos, hogy amennyiben van a folyamatban olyan Receive, amelynek createinstance attribútumának értéke yes, akkor mivel szabvány szerint belőle csak egy lehet a folyamaton belül, biztosan ez lesz az első elem, tehát a folyamaton belül más tevékenység nem mutathat rá. Modellünkben nem ábrázoljuk a Pick tevékenységeket, mivel ezeknek nincs valódi kommunikációs szerepük. Ennek ellenére felhasználjuk a Pick createinstance attribútumát. Ezt implicite a Pick által tartalmazott OnMessage és OnAlarm tevékenységekhez rendeljük, így a Receive-hez hasonló egyszerűsítéseket végezhetünk a Pick esetében is, ha biztosan ez a folyamat első tevékenysége. Eddig csak azokról az átmenetekről beszéltünk, amelyek a folyamaton belül zajlanak. A kommunikáció tényéből adódóan van olyan átmenet, amely abból következik, hogy különböző folyamatok kommunikálnak egymással. Ezek a precedenciák adottak, így egy outputhoz tartozó tevékenységnek meg kell előznie egy vele kommunikáló input tevékenységet A tevékenységek állapottere Nem csak a folyamatot absztraháljuk, hanem a kommunikációs tevékenységek állapotterét is. Az absztrakt modellben nem foglalkozunk tehát a tevékenységek teljes állapotterével, hanem csak azon

58 58 FEJEZET 6. KOOPERÁLÓ MUNKAFOLYAMATOK MODELLEZÉSE 6.3. ábra. Absztrakt OnMessage és OnAlarm állapottere részével, amely elégséges a vizsgálatunkhoz, ennek megfelelően a 6.2. táblázat azt foglalja össze, hogy melyek azok az állapotok, amelyeket megörököl a konkrét állapottérből a tevékenység, és melyeket hagyjuk figyelmen kívül. Hasonlóan a a 6.3. ábrán mutatjuk be, milyen precedencia kapcsolatban állnak egymással az OnMessage, OnEvent illetve OnAlarm állapotai. Hasonlóan a 6.2. ábrán láthatók az Invoke állapotai táblázat. Absztrakt tevékenységek megfeleltetése portoknak Tevékenység Örökölt állapot Elhagyott állapot Invoke startable, read, notyetstartable finished interrupted Receive startable, finished notyetstartable Reply startable, finished notyetstartable OnMessage startable, running notyetstartable finished interrupted OnEvent startable, running, notyetstartable finished interrupted OnAlarm startable, running, notyetstartable finished interrupted Az absztrakt állapottérben tehát csak azt jelöljük, hogy egy BPEL tevékenység lefutott-e, illetve egy input tevékenység esetén azt, hogy fogadni képes-e egy üzenetet. Egy állapotváltás tehát azt jelzi, hogy egy tevékenységre sor került-e, illetve sor kerülhet-e Adatmodell Hasonlóan ahhoz ahogyan eddig egy vezérlési gráfot alakítottunk ki a konkrét modellekből kinyert információk alapján, úgy egy adatmodell is tartozik az absztrakt folyamathoz. A változó állapotterét is egy absztraktabb állapottérben értelmezzük. Ellentétben a vezérlési gráffal, itt névleg sem azonosak ezek az állapotok. Két állapotot különböztetünk meg: hibás (faulty) és nem hibás (healthy) adatot tárol a változó. A hibás állapot azokat a konkrét modellbeli állapotokat fedi, amikor nem kívánt esemény történik, ilyen, amikor hibás adattal írt változót

59 6.2. A KOOPERÁCIÓ MODELLEZÉSE 59 olvasunk (variablefaultywrittenandread), minden más esetben nem olvastuk a hibás adatot (variablefaultywritten), vagy nem is került hibás adat írásra (variablewrittenandread, variablewritten, variableuninited). Íratlan változót olvasasásakor (variableread), statikus hibát dob a BPEL 2.0, így ezzel külön nem kell foglalkoznunk. (A hibásan írt adat és annak olvasása ebben a szemléletben a hiba (error) fogalmának felel meg. Az injektált hiba a meghibásodás (fault), míg az eredeti hívó által megkapott hibás adat a hibajelenség(failure). A variablefaultywritten tehát nem feltétlenül jelenti azt, hogy a működés nem a specifikációnak megfelelő lenne.) Mivel teljesen kötetlenek vagyunk a változók állapotait illetően (hiszen nem tudunk semmit két kommunikációs tevékenység közötti tevékenységek változókezeléséről, továbbá több tevékenység is használhatja ugyanazt a változót), ezért a változónak az absztrakt állapottere szabadon bejárható. Ezt a 6.4. ábrán jelöljük ábra. Absztrakt változó állapottere Legyen két egymást követő tevékenység A és B, egy teljesen absztrakt modell esetén nem ismerhetjük kezdetben var A változó értékét, és nem ismerhetjük var B -t sem. Mivel arról sincsen információnk, hogy a kettő között lévő, nem kommunikációs tevékenységek módosítják-e, és ha igen, hogyan módosítják a két változót. Így egy A B átmenet jelentheti az alábbi átmeneteket az adatmodellben: var A = faulty var B = faulty var A = faulty var B = healthy var A = healthy var B = faulty var A = healthy var B = healthy Látható, hogy a var B értéke független az var A -tól. Ezért ezt egyszerűsítjük úgy, hogy négy tranzíció helyett csak kettő legyen és a tranzíciónak nincsen adatmodellbeli feltétele és var B új értéke nem determinisztikusan lehet healthy vagy faulty. Ezt a tetszőleges változást úgy adjuk meg, hogy minden vezérlési gráfon történő, folyamaton belüli állapotváltást jelképező tranzícióból kettő darab lesz a modellben, az egyikben az aktívvá váló tevékenység változójába hibás adat kerül, a másikban pedig hibátlan. Így jelképezzük azt, hogy mindkét eset megtörténhet. Érezhető, hogy érdemes először a vezérlési gráfot finomítani, hiszen egy esetleg nem valós állapotátmenet azonnal két tranzíció törlését jelenti. A folyamatok közötti kommunikáció esetén viszont egyértelmű, hogy ha a küldő oldal változója hibás, akkor a fogadó oldal változója is hibás lesz. Ha az adat helyes, akkor a túloldali adat is helyes lesz, amint az a ábrán látható Finomítási lépés Ahhoz, hogy a valódi modellhez eljussunk fokozatos finomító lépésekre van szükség. Ezt úgy tesszük meg, hogy a 7. fejezetben leírt hibamodellnek megfelelő eseteket keresünk. Ehhez igyekszünk

60 60 FEJEZET 6. KOOPERÁLÓ MUNKAFOLYAMATOK MODELLEZÉSE 6.5. ábra. Hiba terjesztése olyan LTL kifejezéseket megadni, amelyekre ellenpéldát várunk, az ellenpélda pedig egy olyan lefutás, aminek eredményeképp annak végén előáll a hibás állapot. Ennek az az előnye, hogy mivel ellenpéldára számítunk, ezért egyrészt várhatóan hamarabb végez az ellenőrzés, de legalábbis nem tart tovább, mintha igazolná az ellentétes állításunkat; másrészt egy olyan állapotsorozatot kapunk, amin végigkövethetjük, hogy mely állapotváltások történtek meg addig, amíg elértünk a nem kívánt állapotba. Ezeket az állapotváltozásokat kell jobban szemügyre vennünk. A 6.6. ábrán egy finomítási lépés előtti állapotot látunk ábra. Állapottér finomítás előtt Ebben a részegységben a részletes taglaláskor az alábbi jelöléseket használjuk: Q i : a modell egy állapota, Q i Q j : közvetlen precedencia áll fenn Q i és Q j között, tehát nincs olyan Q k állapot, amely szükséges lenne ahhoz, hogy Q i -ből Q j -be jussunk. (Q i, Q i+1 ): egylépéses állapotátmenet Q i -ből Q i+1 -be, egy egylépéses állapotátmenet csak akkor lehetséges, ha Q i Q i+1 lehetséges.

61 6.2. A KOOPERÁCIÓ MODELLEZÉSE 61 Ekkor tegyük fel, hogy Q i állapotból közvetlenül eljuthatunk a Q i+1 és Q i+2 állapotba is. Feltételezzük továbbá, hogy a SAL arra a követelményre, hogy nem juthatok el egy hibás állapotba, ad egy Z ellenpéldát. Ebben a Z ellenpéldában Q j állapotokon halad végig, ahol 1 j k, Q 1 a kezdeti állapot és Q k a hibás állapot. Ilyenkor azt kell megvizsgálunk, hogy ez az állapotsorozat lehetséges-e a konkrét modellben. Ezt úgy tesszük meg, hogy egyenként megvizsgáljuk a (Q j, Q j+1 ) állapotátmenetet, ha ezt korábban még nem tettük volna meg. Precedencia vizsgálata. Mivel az absztrakt modellben olyan állapotátmenetek vannak, amik azt jelzik, hogy éppen melyik tevékenység futott le, így a vizsgálat célja az lesz, hogy egy A tevékenység után közvetlenül következhetett-e B tevékenység úgy, hogy semmilyen más tevékenység nem volt aktív a kettő között. (Az absztrakt modellezési szinten a közvetlenül követés azt jelenti, hogy a konkrét modellben a két tevékenység között természetesen lehettek aktívak egyéb tevékenységek is, de ezek nem lehettek kommunikációs tevékenységek.) Ekkor meg kell vizsgálnunk az adott, konkrét modellen, hogy ez a precedencia lehetséges-e. Ezt a következő alakban tesszük meg: G(A = finished ξ BEF ORE(κ, B = startable)). (6.1) Ahol ξ = i C i finished, κ = i C i = finished ahol i : C i tevékenység a folyamatban, C i A, C i B és a C i A precedencia még nem igazolt. A BEF ORE(a, b) kifejezés úgy fordítható le, hogy a igaz lesz b előtt és b biztosan bekövetkezik a jövőben. (BEF ORE(a, b) azonos a NOT (U(NOT (a), b)) alakkal.) Az egész kifejezés tehát azt jelenti, hogy minden olyan állapotban, ahol A már bekövetkezett, és semelyik C i nem következett még be (ξ), akkor azelőtt, hogy B bekövetkezne valamelyik C i aktív lesz (κ). ( i C i = finished átalakítható i (C = f inished) alakra.) Ha ez az állítás igaz, az azt jelenti, hogy mindenképp aktívnak kell lennie egy tevékenységnek A és B között, így nem lehetséges közvetlen precedencia közöttük, tehát az absztrakt modellből ez az átmenet törölhető. Fontos, hogy ne tudjuk még biztosan, hogy C i -nek meg kell előznie A-t. Mert ha C i A igazolt akkor biztosan nem fog A után végrehajtódni, ekkor ξ-ből ki kell venni ezt a C i -t. Az ellenőrzések eredményeképpen elvégzett finomítás a 6.7. ábrán látható ábra. Állapottér finomítása

62 62 FEJEZET 6. KOOPERÁLÓ MUNKAFOLYAMATOK MODELLEZÉSE Amennyiben az állítás nem igaz, akkor a közvetlen precedencia lehetséges és az átmenet megtartható. A későbbiekben ezt az állítást már nem kell vizsgálnunk és továbbléphetünk a következő vizsgálandó átmenetre. A vizsgálat eredményeképpen, ha az eredeti BPEL folyamatban szekvenciálisan követte egymást A és B tevékenység, akkor a finomítások után A-ból csak B-be vezethet átmenet. Ha párhuzamos elágazás, vagy döntés több ágában van több kommunikáló tevékenység, úgy ezek mindegyikébe továbbra is vezetni fog átmenet. Hibaterjedés vizsgálata. Hibakeresés esetén azt vizsgáljuk meg, hogy egy adott változó lehet-e hibás. Ha erre egy lehetséges lefutást ad számunkra a SAL, akkor meg kell vizsgálnunk, hasonlóan a vezérlési gráf vizsgálatához, hogy lehetséges-e ilyen állapotértékekkel állapotváltások sorozata a konkrét modellben. Ha nem lehetséges, úgy ez a tranzíció az absztrakt modellből törlendő. Természetesen a kérdezendő LTL kifejezés ebben az esetben valamivel egyszerűbb, mert csak azt kérdezzük meg, hogy ha egy A tevékenység lefutott, akkor az őt követő B tevékenység lefutása után a későbbi tevékenység V változója lehet-e az adott állapotban. Mivel az absztrakt modellben a változó állapotai több valós modellbeli állapotot fednek le, ezért ezek mindegyike előfordulhat. Az alábbi egy példa arra, hogy hibás adatot gyanítunk: és G(A = finished F (B = finished φ)) (6.2) φ = (V = faultyw rittenandread). (6.3) A 6.2. kifejezés azt mondja, hogy ha A tevékenység véget ért, akkor a jövőben B tevékenység is lefut és a változójának értéke mindig φ lesz. Ha hibás adatra számítunk akkor a 6.3. kifejezés adjuk meg. Ha azt feltételezzük, hogy az adat helyes, akkor φ = (V = faultyw ritten V = uninited (6.4) V = written V = writtenandread). Az ellenőrzések mindannyiszor iterációja mindannyiszor szükséges, ameddig a kérdéses állításról biztosan be nem láttuk igaz, vagy hamis voltát. Szélsőséges esetben ez azt is jelentheti, hogy minden átmenetet ellenőriznünk kell. Ebben a fejezetben láthattuk, miként modelleztük a BPEL folyamatok együttműködését, ehhez milyen absztrakciós szintet választottunk, illetve egy általános módszert mutattunk arra, hogyan finomítható az absztrakt modellünk. Az iteratív finomító lépések segítségével pontosíthatjuk egyre jobban absztrakt modellünket, amelyen a következő fejezetben taglalt hibák keresését végezhetjük BPEL kooperáció modellezéséhez kapcsolódó munkák A BPEL, mint önálló folyamatnak a modellezésével ellentétben a folyamatok kooperációjának vizsgálata a BPEL-nél absztraktabb szinten, web szolgáltatások szintjén terjedt el. Így [2] és [29] protokoll konformancia vizsgálata arra szolgál, hogy biztosítsuk, hogy a folyamatokat csak interfészeik alapján azonosítsuk. Így vizsgálható, hogy az egymással kommunikálni kívánó hívó és hívott fél megfelelő protokoll információkkal rendelkeznek-e. Ezáltal megállapítható, hogy lehetséges-e a kommunikáció. Erre építve építhető ki egy komplexebb modellellenőrző megoldás. A kooperáló BPEL folyamatok vizsgálatát legtöbbször az egyéni folyamatokat modellező eljárás kiterjesztésével szokás megoldani. Ebből adódóan [21] együttműködő BPEL folyamatokat színezett Petri-hálókkal vizsgál. Automatizált módszere képes annak vizsgálatára, hogy van-e olyan partner, amellyel együtt tud működni, illetve meg tudja állapítani, hogy egy folyamatban két folyamat viselkedése kizárja-e a kapcsolat megfelelő létrejöttét. Továbbá lehetséges annak kiderítésére, hogy

63 6.3. BPEL KOOPERÁCIÓ MODELLEZÉSÉHEZ KAPCSOLÓDÓ MUNKÁK 63 megfelelően ér-e véget egy kérés kiszolgálása. Nem használt komponensek felderítését nem oldja meg, és csak két együttműködő folyamatra tud csupán vizsgálódni. Módszerében a BPEL 1.1-es folyamatait vizsgálja. Az 5.6. alfejezetben bár említett [11] nem csak önálló folyamatok, hanem azok kooperációjának modellezésben is hozzánk hasonló elveket követ. A folyamatok kommunikációs felületén egy interfészt definiál a kommunikációs tevékenységekből. Ezek adják meg a kooperáló folyamatok között lévő összeköttetést. Így a kommunikációs tevékenységek információi alapján eldönthető, hogy mely folyamatok képesek az együttműködésre. Ez a megoldás figyelmen kívül hagyja az eseménykezelőket, így az ezt feltételező kooperációt, illetve nem modellezi a változó értékének helyességét, ebből adódóan a hibaterjedés vizsgálatát sem tekinti szempontnak. Hozzánk hasonlóan megoldatlan probléma számára a folyamatok a példányosítása, ha több azonos példány is részt vesz a kooperációban.

64 64 FEJEZET 6. KOOPERÁLÓ MUNKAFOLYAMATOK MODELLEZÉSE

65 7. fejezet Kooperáló BPEL 2.0 munkafolyamatok analízise Az előző fejezetben bemutattuk, hogyan modellezünk egyéni folyamatokat, illetve ezek együttműködéséből előálló lazán csatolt kooperációt. A modellezés célja az volt, hogy a munkafolyamatok működését olyan rendszerként írjuk le, amelyen modellellenőrzés végezhető. A modellellenőrzés célja annak ellenőrzése, hogy a vizsgált folyamatok megfelelnek-e bizonyos kritériumoknak. Ebben a fejezetben azt részletezzük, hogyan ellenőrizhető néhány olyan általános kritérium, amelyek teljesülését a munkafolyamatok helyes működése érdekében, tervezési időben figyelembe kell venni. A kritériumoknak két csoportját különböztetjük meg, aszerint, hogy önálló folyamatokra, vagy a folyamatok kooperációjára vonatkoznak. Az önálló folyamatokra definiált kritériumok vizsgálatakor a folyamat részletes SAL leírásán végezzük a modellellenőrzést. Az együttműködő folyamatokkal szemben támasztott kritériumok esetén a modellellenőrzést a kooperáció absztrakt modelljén végezzük el. A 7.1. fejezetben az önálló folyamatokra adott kritériumokat ismertetjük, míg a 7.2. fejezetben az együttműködő folyamatokra vonatkozókat Önálló folyamat vizsgálata Biztonsági kritériumok formalizálása A bemutatott modellezési módszer használata lehetőséget nyújt önálló folyamatok modellellenőrzésére. Az ellenőrzés segítségével mind általános, mind folyamat-specifikus kritériumok teljesülése vizsgálható egy adott munkafolyamat esetén. Az általános kritériumok által meghatározott tulajdonságok bármelyik munkafolyamat esetén vizsgálhatók. Ellenben a folyamat-specifikus kritériumok egy adott felhasználási területen (például banki folyamatok vagy oktatási rendszerek) értelmezhetőek és ilyen típusú folyamatokra vizsgálhatók. Az önálló folyamatokra a következő általános kritériumok ellenőrzését ismertetjük: a) Nincs inicializálatlan változó olvasás. A vizsgált munkafolyamat végrehajtásakor nem következhet be olyan helyzet, amikor egy változó tartalmát felhasználjuk, mielőtt a változót írtuk volna. Ha a folyamat nem teljesíti ezt a kritériumot, akkor létezik olyan változó, amelyet előbb olvasunk mint írunk. A modellellenőrzés segítségével ez kiszűrhető és a tulajdonságot sértő változó megtalálható. b) Nincs soha nem olvasott változó. Teljesítése esetén kimondhatjuk, hogy nincs felesleges változó a rendszerben. Ez azt jelenti, hogy minden változót módosítunk és a változó tartalma felhasználásra kerül. Az a munkafolyamat, amelyben a tulajdonság nem teljesül, tartalmaz felesleges változót, amely eltávolítható. 65

66 66 FEJEZET 7. KOOPERÁLÓ BPEL 2.0 MUNKAFOLYAMATOK ANALÍZISE c) A folyamat futása mindig befejeződik. A kritérium fennállása biztosítja, hogy a folyamat minden esetben véget ér. Az előző kritériumokkal ellentétben ez a tulajdonság nem egy hibás állapot elkerülését írja elő, hanem azt mondja ki, hogy a folyamat elindulása esetén végül mindenképpen eljut a befejezett állapotba. Azt az állapotot, ahonnan egy folyamat nem képes továbblépni, holtpontnak (deadlock) nevezzük. A modellellenőrzés segítségével megtalálhatóak azok a lefutások, amelyek a folyamat holtpontra jutását eredményezik. Az ellenőrzés a holtpont létezésének ténye mellett a folyamat holtpontra jutását okozó lefutást is megadja. A felsorolt kritériumok elsősorban olyan tulajdonságokat fogalmaznak meg, amelyek nem teljesülése esetén a vizsgált folyamatnak létezik olyan lefutása, ami hibás működést eredményez. Az a), b) és c) kritériumok biztonsági tulajdonságokat határoznak meg. Az ismertetett kritériumokat a következő módon írhatjuk fel LTL kifejezések segítségével: a) G(var A read) Az a) kifejezés azt jelenti, hogy az A változó állapota soha nem kerül csak olvasott állapotba. Ha létezik a munkafolyamatnak olyan lefutása, amelyben az A változó csak olvasott állapotba kerül, akkor az ellenőrzés ellenpélda formájában visszaadja azt az akciósorozatot, ami az illegális állapotba vezet. Az ellenpélda segítséget ad a folyamat javításához. b) (F (var A = writtenandread)) A b) kifejezés azt mondja ki, hogy nincs olyan lefutás, amelyben az A változó állapota írt és olvasott lesz a végrehajtás valamely pontján. Ha az ellenőrzés ellenpéldát szolgáltat, akkor biztosan felhasználjuk a változóba írt értéket, míg ha bizonyítható az állítás, akkor az A változóba írt értéket nem használjuk soha. c) G(process = startable F (process = finished)) A c) kifejezés azt írja le, hogy mindig igaz, hogy amennyiben a folyamat indítható állapotban van, akkor a jövőben valamikor befejezett állapotba kerül. Az ellenőrzés által szolgáltatott ellenpélda megmutatja azt a lefutást, amely esetén a folyamat holtpontra jut. Ha a kifejezés igaz, akkor a folyamat mindig befejeződik. Ha a vizsgált folyamat ciklust tartalmaz, akkor a c) kifejezés ellenőrzése során olyan ellenpéldát kaphatunk, amelyben a ciklus végtelen számú végrehajtása megakadályozza a folyamat befejeződését. Ilyen esetben a kifejezés módosítása szükséges, ám a módosítás előtt további ellenőrzések végrehajtása szükséges. A szükséges kifejezéseket az alábbi felsorolás tartalmazza. c 1 ) G(P rocess = startable F (while = startable)) c 2 ) G((P rocess = startable F (while = finished)) F (P rocess = finished)) c 3 ) G(Cyclecore = startable F (Cyclecore = finished)) A c 2 ) kifejezés feltételezi, hogy a ciklus valamikor befejeződött, tehát először ellenőriznünk kell, hogy a rendszer minden esetben eljut-e arra pontra, ahol a ciklus indítható állapotban van. Érezhetően nem elég, ha tudjuk, hogy a folyamat mindig eljut a ciklus kezdetéig (c 1 )), és hogy a ciklus befejezése esetén eljut a befejezett állapotba (c 2 )). Meg kell vizsgálni, hogy a ciklusmag végrehajtása közben kerülhet-e holtpontra a rendszer, továbbá azt, hogy a ciklus biztos véges számú iterációt végez. Az ciklusmag vizsgálatához használt kifejezés (c 3 )) az eredeti c) kifejezéshez hasonló, azt mondja ki, hogy a ciklusmagot alkotó tevékenység indítható állapotból minden esetben eljut befejezett állapotba. Végül annak ellenőrzése, hogy véges számú iteráció után véget ér a ciklus, már nem tehető meg modellellenőrzés segítségével, ehhez a konkrét BPEL folyamatleírást kell megvizsgálni. Előfordulhat, hogy egy folyamatban több ciklus található, amelyek akár egymásba ágyazottan is elhelyezkedhetnek. Abban az esetben, ha szekvenciális elhelyezkedésű ciklusok vannak a rendszerben, a fent bemutatott módszer alkalmazható további kifejezések felvételével. Az új kifejezések a ciklusok közötti holtpontmentességet vizsgálják, továbbá azt, hogy a ciklusok belsejében nincs

67 7.1. ÖNÁLLÓ FOLYAMAT VIZSGÁLATA 67 holtpont. Ha egymásba ágyazott ciklusokat is tartalmaz a folyamat, akkor a bemutatott ellenőrzést úgy kell végrehajtani, hogy a külső ciklusra írjuk fel a c 1 )-c 3 ) kifejezéseket. Hasonlóan kezelhetőek az elágazások különböző ágaiban elhelyezkedő és párhuzamosan végrehajtott ciklusok is, a c 2 ) kifejezésben található implikáció bal oldalának módosításával Hibainjektálás A munkafolyamatok ellenőrzésekor sok esetben arra vagyunk kiváncsiak, hogy egy adott helyen bekövetkező hiba milyen hatással van a munkafolyamat lefutására. Az általunk használt modellezési megközelítés használatával az ilyen vizsgálatok egyszerűen elvégezhetőek. Kihasználva, hogy a BPEL leírás XML alapú, egyes tevékenységekhez kiegészítő attribútumokat definiálunk, amelyek megadásával a létrehozott SAL leírás változtatható. Ennek megfelelően megadhatjuk például egy szolgáltatás használatot leíró tevékenység (invoke) esetén, hogy a használt szolgáltatás meghívása után a válaszként kapott adat hibás-e, vagy a szolgáltatás nem megfelelő működése miatt a folyamat hibát dobjon-e. Ezt a fajta megközelítést hibainjektálásnak nevezzük. Hibás adat fogadását jelző kiegészítő attribútum (writesfaultydata) megadásának módját mutatja a 7.1. részlet. A 7.1. ábrán a hibás adat írásának modellezése látható. < invoke name =" Check Student s Educational Status " inputvariable =" status_ input " output_ variable =" status_ output " writesfaultydata =" yes "/ > Részlet 7.1. BPEL leírás: hibainjektálás kiegészítő attribútummal 7.1. ábra. Hibainjektálás modellezése Az invoke tevékenység mellett hasonló kiegészítő attribútumokat definiálunk a változók validációját végző tevékenység (validate) esetén is. Alapesetben a validáció nem dob hibát a modellezett folyamatban, de ez megváltoztatható. Ha a validáció hibát dob, akkor a hiba típusa invalidvariables lesz míg a hibát okozó változó a validáció során vizsgált változó lesz. Az linkek tárgyalásakor (5.5. fejezet) említettük, hogy ha van átviteli feltétel, akkor a kiértékelést nemdeterminisztikusan modellezzük és a link értéke igaz vagy hamis lesz. A kiegészítő attribútum használatával megadható, hogy az átviteli feltétel kiértékelésének eredménye mi legyen. Az attribútum értékétől függően a link értéke lehet mindig igaz, mindig hamis, vagy az átviteli feltétel kiértékelésekor hiba keletkezik, ekkor a link értéke a már ismertetett módon határozatlan vagy hamis lesz. A 7.2. részlet mutatja a kiegészítő attribútum (semantics) megadását. Ebben

68 68 FEJEZET 7. KOOPERÁLÓ BPEL 2.0 MUNKAFOLYAMATOK ANALÍZISE az esetben az átviteli feltétel értéke mindig hamis lesz. A 7.2. ábrán látható a kiegészítés hatása a létrehozott tranzíciós rendszer működésére. <assign > <sources > < source linkname =" link "> < transitioncondition semantics =" false " > P: gettranscondvalue () </ transitioncondition > </ source > < source linkname =" link2 "/ > </ sources > [...] </ assign > Részlet 7.2. BPEL leírás: átviteli feltétel megkötése 7.2. ábra. Megkötött átviteli feltétellel rendelkező link modellezése A hibaterjedés vizsgálatához megadott kritériumok olyan tulajdonságokat írnak le, amelyek a folyamat hibatűrő képességét adják meg. A hibatűrő képesség vizsgálatához a folyamat működését úgy módosítjuk, hogy egyes lefutások esetén hiba kerül a folyamatba és ennek a hibának a hatását követjük végig. Az 1)-3) kritériumok élőségi tulajdonságokat írnak le. 1) Nem kerül hibás adat a válaszüzenetbe. Azt mondja ki, hogy a hiba bekövetkezése nem eredményez hibás válaszüzenet küldést. Ennek teljesülése azt jelenti, hogy a hibát kezeli a folyamat és a hiba nincs hatással a kimenetre. 2) Nem küldünk hibás adatot más szolgáltatásnak. A második aleset annyiban finomabb, mint az előző kritérium, hogy nem csak a válaszüzenetben küldött hibás adatot vizsgálja, hanem a folyamaton belüli szolgálat hívások esetén is ellenőrzi az küldött adatok állapotát. 3) Nincs nem kezelt folyamatszintű hiba. A harmadik aleset nem az adatok állapotát ellenőrzi, hanem a folyamat állapotát. A kritérium kimondja, hogy a folyamat az adott hibát képes kezelni. Ha a tulajdonság fennáll, akkor nem fordul elő olyan eset, amikor a válaszüzenet helyett hibaüzenetet küld a folyamat válaszként. A fent megfogalmazott kritériumokat a következő lineáris temporális logikai kifejezésekkel írhatjuk le formálisan.

69 7.2. KOOPERÁLÓ FOLYAMATOK VIZSGÁLATA 69 1) (F (var output = faultyw rittenandread reply = finished) Az 1) kritériumhoz tartozó kifejezés azt jelenti, hogy nincs olyan végrehajtási útvonal, amelynek végén a válasz üzenetet tartalmazó változó értéke hibásan írt és olvasott lesz. Ha az ellenőrzés ellenpéldát szolgáltat a kifejezés vizsgálatakor, akkor az ellenpéldán végigkövethetjük azt a lefutást, amelynek végén a kimeneten hibás adat távozna. 2) (F (var A = faultyw rittenandread invoke A = read) A 2) kritérium vizsgálatához az 1) alesethez hasonló kifejezés szükséges. A kifejezés azt adja meg, hogy egy adott üzenetküldő tevékenységhez tartozó változó értéke ne legyen hibásan írt és olvasott amikor a tevékenység elküldte az üzenetet. Ha található olyan lefutás, amely nem teljesíti ezt a kritériumot, akkor a folyamat végrehajtása során lehetséges, hogy az adott üzenet küldéskor hibás adat van az elküldött üzenetben. 3) (F (processhost = throwingf ault)) A 3) kritériumhoz megadott kifejezés azt mondja ki, hogy a folyamat legfelső szintjét jelképező scope tevékenység nem kerül hiba keletkezését jelző állapotba. Ha előfordul olyan lefutás, amelynek során a kifejezés nem teljesül, akkor keletkezhet olyan hiba a folyamatban, amelyet nem kezelünk le. A le nem kezelt folyamatszintű hiba következménye az lesz, hogy a válaszüzenet helyett hibaüzenetet küld a folyamat Kooperáló folyamatok vizsgálata Egymással kommunikáló folyamatok absztrakt modelljének ellenőrzésekor a következő hibákat keressük: a) Hibás adat továbbterjedése Azt vizsgáljuk, hogy egy tevékenység által használt változók értéke lehet-e hibás a végrehajtás futása során. b) Soha nem használt komponensek felderítése Ellenőrizzük, hogy egy adott folyamat részt vesz-e a kooperációban, vagyis valamikor a végrehajtás során lesz olyan tevékenysége, amely lefut. c) Holtpont alakul ki egy üzenetre történő várakozás miatt A kritérium azt mondja ki, hogy létezik olyan végrehajtás, amely azért nem fejeződik be, mert az egyik folyamat olyan üzenetre vár, amely az adott végrehajtás során nem kerül elküldésre. A 6. fejezetben részletezett okokból nincsen pontos tudásunk az együttműködésben résztvevő folyamatok belsejéről, ezért a kritériumok ellenőrzése sem végezhető el az absztrakt modellen finomítás nélkül. A finomítás során nem minden állapotátmenet helyességét vizsgáljuk meg, csak azokét, amelyek egy kritérium bizonyíthatósága során szükségesnek mutatkozik. Kezdetben egy olyan LTL állítást adunk meg a modellellenőrző számára, amely tagadja a hiba előfordulásánák lehetőségét. a) Hibaterjedés: G(var A faulty) Ahol a) azt jelöli, hogy mindig igaz, hogy az A tevékenységhez tartozó változó értéke soha sem lesz hibás. Tehát nem képzelhető el olyan állapotátmenetsorozat, amely során bármikor hibás lenne a változó értéke. Amennyiben a SAL egy olyan akciósorozatot talál, amelynek végén ebbe az illegális állapotba jut, akkor az állítás hamis. b) Használatlan komponens: G( (A = f inished B = f inished )) A b) állításban A,B... jelölik azokat a tevékenységeket, amelyek egy folyamaton belül vannak. Az állítás azt mondja, hogy egy folyamat egyik tevékenysége sem kerül finished állapotba, tehát egyik tevékenység sem futott le. Ha viszont egyik tevékenység sem lesz aktív, akkor a komponenst nem is használjuk a kommunikáció során és így felesleges.

70 70 FEJEZET 7. KOOPERÁLÓ BPEL 2.0 MUNKAFOLYAMATOK ANALÍZISE c) Holtpont: G((A = finished) (F (B = finished C = finished ))) A c) állításban az A tevékenység a folyamat kezdő üzenetet fogadó tevékenysége, B, C pedig az erre a bejövő üzenetre adott válaszokat küldő tevékenységek. A kifejezés azt fejezi ki, hogy ha a kezdő tevékenység lefutott, akkor arra nem fog válaszolni a folyamat. Amennyiben igaz az állítás, akkor deadlock van a rendszerben. Hiszen soha nem tud választ adni a rendszer a bejövő kérdésre. Az a) és b) esetekre a vizsgálat menete hasonló. A modellellenőrző válaszolhatja, hogy a kifejezés bizonyított, így az állításunk igaz lesz. Abban az esetben, ha a válasz egy ellenpélda, akkor annak egyes lépéseit kell megvizsgálnunk sorban. Amennyiben az ellenpélda mindegyik átmenete lehetséges, akkor találtunk egy olyan akciósorozatot, amelyik eljutott a keresett, illegális állapotba. Amennyiben valamelyik lépésről kiderülne, hogy nem lehetséges, akkor annak törlése után a finomított modellnek újra beadjuk a bizonyítandó állítást. Amennyiben találtunk egy olyan akciósorozatot, amely valóban lehetséges, akkor abból megállapítható, hogy honnan származik a hibás adat. Hasonlóan járunk el egy nem használt komponens felderítésénél: ha találunk egy olyan akciósorozatot, ahol legalább az egyik komponens lefutott, akkor meg kell vizsgálnunk, hogy annak minden lépése valódi-e. Ha minden tranzíciója az ellenpéldának lehetséges, úgy megállapíthatjuk, hogy nem redundáns a komponens a kooperációban. Ellenkező esetben, ha az állítás bizonyított, akkor a komponens valóban felesleges. (Egy példa egy nem használt komponens esetére az, amikor egy üzenet küldés vagy csak egy nem aktivált catch ágban, vagy csak a catch által kezelt ágban a hiba dobás után történne meg, de a catch ágában nem.) Holtpont keresése. Egy kicsit más megközelítéssel vizsgáljuk a c) állítást. Holtpont (Deadlock) keresésénél, ha az állítás bizonyítható, akkor minden esetben deadlock helyzetbe kerül a rendszer. Amennyiben ellenpéldát ad, akkor létezik egy olyan akciósorozatunk, amely bekövetkezésekor választ tud adni a bejövő kérésre a folyamat. Ezeket az állapotátmeneteket kell megvizsgálnunk, hogy valóban létező állapotátmenetek-e. Ha ezek mindegyike lehetséges, akkor nem feltétlenül következik be deadlock. Ez viszont nem zárja ki azt, hogy bár nem mindig, de bizonyos akciósorozatok eredményeképpen kialakulhat deadlock. Ennek oka, hogy a kooperáció absztrakt modelljének elkészítésekor felülről becsültük a konkrét modellt, így ha abban nem alakul ki deadlock, akkor a kooperáció modelljében sem alakul ki biztosan deadlock. Fordított irányba ez viszont nem igaz a felülről történő becsléskor. Ekkor a G((A = finished) F (B = finished C = finished )) (7.1) alakú kifejezést ellenőriztetése nem feltétlenül hozza meg a várt eredményt. Ez azt fejezi ki, hogy ha a folyamat kezdőtevékenysége lefutott, akkor az erre adandó válasz biztosan bekövetkezik. Lehetnek viszont még olyan akciósorozatok az absztrakt modellben, amelyek nem valósak. Képzeljük el a 7.3. ábrán látható helyzetet. Ekkor A a kezdőtevékenység, X pedig az erre választ adó záró tevékenység. A b) állítása egy ellenpélda a A B X. Megállapítható, hogy minden egyes átmenet, tehát mind A B és B X átmenet valós. Az ábrán jól látszik, hogy van egy A C X akciósorozat is, ahol szintén eljuthatunk az X záró tevékenységbe. A A C és C X átmenetek viszont még nem bizonyítottak. Ha a erre a modellre feltennénk a kérdést, hogy lehetséges-e deadlock, azt a választ kapnánk, hogy nem. Holott elképzelhető, hogy a A C átmenet valódi, a C X átmenet viszont nem. Ekkor C-be érkezve deadlockba jutnánk. A tranzíciós rendszer a c) re ellenpéldaként viszont a B-n keresztül vezető akciósorozatot adja, így nem sejthetjük, milyen egyéb tranzíciósorozat van A és X között. Ezt kiküszöbölendő minden még megmaradt és be nem bizonyított átmenetre be kell látunk, hogy valós-e vagy sem. Ezzel egy olyan absztrakt modellt hozunk létre, amely csak valós átmenetet tartalmaz. Erre a modellre már megkérdezhető, hogy minden esetben eljut-e a válaszoló tevékenységbe. (A gyakorlatban viszonylag ritkán fordul elő olyan szituáció, amikor minden absztrakt tranzíciót ellenőriznünk kell, ám elméletileg lehetséges ilyen eset is.) Itt jegyezzük meg, hogy hasonlóan, kezdetben nem tehetjük fel

71 7.3. MODELLELLENŐRZÉS VÉGREHAJTÁSA ábra. Be nem bizonyított utak veszélye a G((A = finished) F (B = finished C = finished )) kérdést, mert az absztrakt modellben minden folyamaton belüli tevékenységsorrend megengedett, így természetes módon mindig ad választ a folyamat. Viszont ekkor nem adja meg számunkra azokat az akciósorozatokat, amelyek egyes lépéseinek valódiságát vizsgálnunk kell. Így nem ad valódi információt. Az együttműködő folyamatokat reprezentáló modellen keresett deadlock azzal egészíti ki az önálló folyamaton keresett deadlockot, hogy felderíthetőek azok az esetek, amikor egy meg nem érkező üzenet miatt reked meg egy folyamat végrehajtása. Míg az önálló folyamatokon minden kommunikációs tevékenységet végrehajthatónak feltételezünk, addig az kommunikáló folyamatok összeségének modelljében már csak a valóban lezajlott üzenetküldések és fogadások szerepelnek. Ennek ára, hogy extrém esetben minden lehetséges átmenetet meg kell vizsgálnunk ahhoz, hogy biztosan állíthassuk, hogy nincs deadlock a rendszerünkben Modellellenőrzés végrehajtása A 7.1. fejezetben olyan általános kritériumokat mutattunk be, amelyek önálló folyamatokon értelmezhetőek. A részben ismertettük hogyan lehetséges a munkafolyamatok futása során keletkező hibák hatását megfigyelni. A 7.2. részben a kooperáló munkafolyamatok modellellenőrzéséhez használható kifejezéseket részleteztük. A következő alfejezetben bemutatjuk az ismertetett ellenőrzési módszerek egy gyakorlati alkalmazását a dolgozatban használt esettanulmány vizsgálatával. Először az önálló folyamatokra definiált kritériumokat ellenőrizzük, majd a hibaterjedést vizsgáljuk meg a hibainjektálás módszerének felhasználásával. Végül az együttműködő folyamatokkal szemben támasztott kritériumok alkalmazását írjuk le Mintafolyamat ellenőrzése Először tehát a tanulmányi rendszer mintapélda egy folyamatán végzünk modellellenőrzést. A vizsgált folyamat a helyi egyetem információs rendszerének oktatási modulján futó kurzusáthallgatási folyamat (LEW) lesz. A Függelék a és a ábráján látható a folyamat megvalósítása.

72 72 FEJEZET 7. KOOPERÁLÓ BPEL 2.0 MUNKAFOLYAMATOK ANALÍZISE Az ellenőrzéshez szükséges tranzíciós rendszer leírásának előállítása a Függelék a részében olvasható. A folyamaton a következő kritériumokat fogjuk ellenőrizni: a) Nincs inicializálatlan változó olvasás: G(var output read)) Kimondja, hogy nincs olyan lefutás, amely során a folyamat a válaszként küldött üzenetet tartalmazó változót üresen olvassa. b) Nincs felesleges változó: (F (var status_output = writtenandread)) Ha a kifejezés igaz, akkor a folyamat futása nem függ a var status_output változótól. c) Nincs holtpont: G(P rocess = startable F (P rocess = f inished)) A kifejezés akkor igaz, ha a folyamat minden esetben eljut a kezdőállapotból a végállapotba. A felsorolt kifejezéseket a 3.4. részben ismertetett formában hozzáadjuk a generált SAL tranzíciós rendszer leíráshoz. A SAL keretrendszer eszközeinek segítségével az így elkészült leírás ellenőrizhető. Minden új állomány esetén érdemes a jól-formáltság ellenőrzőt futtatni, mielőtt a modellellenőrző eszközöket használnánk. Ha a jól-formáltság ellenőrző nem talál hibát, akkor elkezdhetjük a kritériumok ellenőrzését a SAL szimbolikus modellellenőrző eszközével. a) Igaz Az a) kritérium esetén az ellenőrző megvizsgálja a lefutási útvonalakat és egy idő után kiírja, hogy a kifejezést bizonyította. Tehát a válaszüzenetet tároló változót a folyamat nem fogja üresen olvasni. b) Ellenpélda A b) kifejezés vizsgálata esetén az ellenőrző kiírja, hogy ellenpéldát talált a kifejezésre és ki is írja a talált lefutást leíró állapotátmenet sorozatot. Tehát van olyan lefutás, amelyben a var status_output változó tartalmát használja a folyamat. c) Igaz A c) kritérium választásakor az ellenőrző az összes lehetséges lefutást megvizsgálja és ebben az esetben is sikeresen bizonyítja a kifejezést. A 7.1. táblázatban összefoglaljuk a futási eredményeket. Az oszlopokban megadott adatok sorban: a vizsgált kritérium, az ellenőrző által megvizsgált csomópontok számát, a verifikációhoz szükséges idő, a teljes futásidő és a vizsgálat eredménye táblázat. Önálló folyamat ellenőrzésének eredményei Kritérium Vizsgált csp.# Verfikáció [s] Teljes futás [s] Eredmény Nincs inicializálatlan ,5 4,6 Igaz változó olvasás Nincs felesleges ,3 5,8 Ellenpélda változó Nincs holtpont ,2 6,0 Igaz Hibaterjedés vizsgálata A részben leírtaknak megfelelően a folyamat működése hibainjektálás segítségével is vizsgálható. A most vizsgált folyamat esetén az egyik webszolgáltatást felhasználó invoke tevékenységet fogjuk úgy átalakítani, hogy a válaszüzenet hibás adatot fog tartalmazni. Az ellenőrzés során megvizsgáljuk milyen hatása van ennek a hibás adatnak a folyamat lefutására. A ábrán Check Student s Educational Status névvel szereplő tevékenység kimenete fog hibás adatot tartalmazni. A hiba hatását a következő kifejezések ellenőrzésével vizsgáljuk:

73 7.3. MODELLELLENŐRZÉS VÉGREHAJTÁSA 73 H 1 ) Nem terjed át a hiba a válaszüzenetre: (F (var output = faultyw rittenandread invoke = read) A kritérium teljesülése esetén nincs olyan lefutás, amelyben a válaszüzenet hibás adatot tartalmaz. H 2 ) Nem küldünk hibás adatot: (F (var A = faultyw rittenandread invoke A = read) A kifejezés igaz, ha nem küldünk hibás adatot egy adott webszolgáltatás meghívásakor. H 3 ) Nincs nem kezelt hiba: (F (processhost = throwingf ault)) A tulajdonság teljesülése esetén a folyamat lekezel minden olyan hibát, amely a hibás adat következtében keletkezik. A SAL leírás kiegészítése és jól-formáltság ellenőrzése után a következő eredményeket kapjuk az ellenőrző eszköztől: H 1 ) Ellenpélda Az ellenőrző ellenpéldát talál, tehát van olyan lefutás amely során a válaszüzenetbe hibás adat kerül. H 2 ) Ellenpélda A következő esetben egy olyan webszolgáltatás hívást ellenőrzünk, amely felhasználja a hibás adatokat, ezt az ellenőrző által talált ellenpélda igazolja. H 3 ) Igaz A folyamat végrehajtása során a hibás adat ellenére sem keletkezik olyan hiba, amelyet nem kezel le a folyamat. A 7.2. táblázat összefoglalja a futási eredményeket, az oszlopok tartalma az előzővel megegyező táblázat. Hibaterjedés vizsgálatának eredményei Kritérium Vizsgált csp.# Verfikáció [s] Teljes futás [s] Eredmény Nem terjed át a hiba ,6 6,2 Ellenpélda a válaszüzenetre Nem küldünk ,4 5,8 Ellenpélda hibás adatot Nincs nem ,8 5,4 Igaz kezelt hiba Az itt felsorolt kritériumok és kifejezések csak néhány példa arra, hogy milyen tulajdonságok modellellenőrzése végezhető el a bemutatott modellezési módszer segítségével Kooperáló folyamatok ellenőrzése A 7.2. alfejezetben ismertettünk néhány olyan kritériumot, amelyek ellenőrzése kooperáló munkafolyamatok vizsgálatakor lehetséges. A következőkben egy példa kritérium vizsgálatával bemutatjuk azt a modellfinomítást alkalmazó módszert, amelyet az együttműködő folyamatok modellellenőrzésére használunk. A példához az esettanulmány két folyamatát használjuk fel, az egyik a távoli egyetem oktatási moduljának kurzusáthallgatási folyamata (REW), a másik a távoli egyetem adminisztrációs moduljának kurzusáthallgatási folyamata (RCAW). A folyamatok megvalósítása a Függelék a és a ábráin látható. A REW és RCAW közötti kooperáció a 7.4. ábrán is megfigyelhető (az REW felhasználja a RCAW által nyújtott szolgáltatást). A vizsgálathoz a transzformációk segítségével létre kell hoznunk a két munkafolyamatot leíró tranzíciós rendszer leírást, továbbá az együttműködést modellező absztrakt rendszer leírást. Ezután először az absztrakt tranzíciós rendszer leíráshoz kell hozzáadni a következő vizsgált kritériumot:

74 74 FEJEZET 7. KOOPERÁLÓ BPEL 2.0 MUNKAFOLYAMATOK ANALÍZISE 7.4. ábra. Az esettanulmány folyamatainak együttműködése Hibaterjedés vizsgálata. G(var A faulty), ahol A esetünkben legyen a REW folyamat Store Course Change tevékenység, var A pedig a hozzá tartozó változó. A kritériumban megadott kifejezés igaz, ha nincs olyan lefutás, amely során a változó hibás értéket vesz fel. Az absztrakt rendszer leírás működése felülről becsüli a valódi rendszer működését. Ezért lehetséges, hogy a kritérium vizsgálatakor a modellellenőrző olyan ellenpéldát talál, amely tartalmaz a valódi rendszerben nem létező állapotátmeneteket. Az állapotátmenetek létezését az önálló folyamatok vizsgálatával ellenőrizhetjük. Ha olyan állapotátmenet szerepelt az ellenpéldában, amely bizonyítottan nem létezik, akkor ezt az állapotátmenetet eltávolíthatjuk az absztrakt tranzíciós rendszerből. A nem létező állapotátmenetek eltávolítása után a kritériumot ismét ellenőrizzük. Ha a modellellenőrző nem talált ellenpéldát (tehát bizonyította a kritériumot), akkor kimondhatjuk, hogy nincs olyan lefutás, amely során a var A változóban tárolt adat hibás és ezt az adatot a folyamat használja. Ez a kritérium azonban nem csak az absztrakt tranzíciós rendszerre, hanem a valódi rendszerre is igaz lesz ekkor. Ha a modellellenőrzés során olyan ellenpéldát találunk, amelynek minden állapotátmenete létezik az önálló folyamatok tranzíciós rendszerében is, akkor a kritérium nem teljesül. Ekkor elmondható, hogy van olyan lefutás, amelyen a változó hibás adatot tartalmaz, és a hibás adat hatással van a folyamat futására. Ellenőrzés a kezdeti absztrakt modellen. A SAL keretrendszer szimbolikus modellellenőrző eszközét használva ellenőrizzük a kritérium teljesülését. Az ellenőrző eszköz által talált ellenpélda a kezdeti modell vizsgálatakor mindössze egy állapotátmenetből fog állni, amely a kezdőtevékenység (Receive Course Change Request, RCCR) és a vizsgált tevékenység (Store Course Change, SCC) közötti precedenciát jelző átmenet, amelynek eredményeképp var A hibás állapotot vesz fel. Eredmény ellenőrzése az önálló folyamatok modelljén. A kapott ellenpélda átmeneteit a folyamatok SAL leírásain elvégzett modellellenőrzés segítségével vizsgáljuk meg. Az RCCR SCC átmenet vizsgálatához a részben leírtak szerint a következő kifejezés ellenőrzése szük-

75 7.3. MODELLELLENŐRZÉS VÉGREHAJTÁSA 75 séges: G(RCCR = finished (CCD finished SDA finished CLE1 finished CLE2 finished) BEF ORE((CCD = finished SDA = finished CLE1 = finished CLE2 = finished), SCC = startable)). Ha a kifejezés igaz, akkor az RCCR tevékenység befejezése után és az SCC tevékenység végrehajtása előtt mindenképpen lefut egy másik kommunikációban is részt vevő tevékenység. A kifejezésben a rövidítések jelentése a következő: Check course data (CCD), Send Data to Admin WF (SDA), Call local Edu WF, a Course change acceptable ágon (CLE1), Call local Edu WF, az Else ágon (CLE2). Az ellenőrző eszköz bizonyítja a kifejezést, ezért az RCCR SCC nem létező átmenet, mert nincs olyan lefutás, amelyben RCCR után SCC lesz a következő absztrakt modellben is szereplő tevékenység. Absztrakt rendszer finomítása. Mivel az ellenpéldáját talált átmenet nem létezik a valódi rendszerben, ezért az átmenet az absztrakt modellből törölhető. Az absztrakt rendszerre definiált kritérium ellenőrzésének ismétlésével a rendszer tovább finomítható. A finomítást addig kell folytatni, amíg olyan ellenpéldát nem találunk, amelyben csak létező átmenetek vannak, vagy ha a kritérium kifejezése igaz a finomított modellen. Amikor a finomítás során egy létező átmenetet találunk, akkor a hibaterjedés vizsgálata esetén azt is meg kell vizsgálni, hogy az átmenet során a tevékenység változója hibás értéket vehet fel a valódi rendszerben. Ehhez az önálló folyamatot leíró rendszeren a következő kifejezés igazságértékét kell ellenőrizni: G((RCCR = finished) F (SCC = finished var A = faultyw rittenandread) (7.2) A 7.2. kifejezés akkor igaz, ha van olyan lefutása a folyamatnak, amely során az RCCR tevékenység végrehajtása után valamikor az SCC tevékenység is befejeződik és ekkor a változója hibásan olvasott állapotban van. Eredmény. A modellfinomítási lépések végrehajtása után eljutunk egy olyan absztrakt rendszer leíráshoz, amelyen az ellenőrző bizonyítani tudja a megadott kritériumot. Ez azt jelenti, hogy a valódi rendszerben is igaz a kritérium, vagyis a folyamatok együttműködése során nincs olyan lefutás, amelyben az SCC tevékenység változója hibás adatot tartalmaz és ezt az adatot a folyamat fel is használja. A 7.3. táblázatban megadjuk a vizsgálat során futtatott ellenőrzések eredményeit. Ebben a fejezetben ismertettük azokat a kritériumokat, amelyek kooperáló BPEL2.0 folyamatok vizsgálatához használhatóak. Külön tulajdonságokat fogalmaztunk meg az önálló folyamatok általános működésének ellenőrzésére, továbbá a folyamatokban előforduló hibák hatásának megfigyelésére. Ezután néhány olyan kritériumot részleteztünk, amelyek együttműködő munkafolyamatok vizsgálata esetén használhatóak. Végül az esettanulmány folyamatait felhasználva bemutattunk néhány példa ellenőrzést és azok eredményét. Jelen fejezet a dolgozat fontos részét képezi, mely bemutatja, hogy az általunk kidolgozott modellezési módszer hogyan használható gyakorlati célokra. A leírt kritériumok alkalmazhatóak tetszőleges munkafolyamatokra és kiterjeszthetőek további tulajdonságok vizsgálatához.

76 76 FEJEZET 7. KOOPERÁLÓ BPEL 2.0 MUNKAFOLYAMATOK ANALÍZISE 7.3. táblázat. Kooperáló folyamatok ellenőrzésének eredményei Kritérium Vizsgált csp.# Verfikáció [s] Teljes futás [s] Eredmény Nincs RCCR SCC ,1 2,0 Igaz átmenet Nincs RCCR CCD ,05 2,0 Ellenpélda átmenet SCC nem olvas ,12 2,2 Igaz hibás adatot

77 8. fejezet Megvalósítás Az előző fejezetekben ismertettük az üzleti folyamataink közötti együttműködés vizsgálatának elméleti oldalát. Ebben a fejezetben az implementációs részére szeretnénk kitérni. Először a megvalósítás technológiáját mutatjuk be röviden, majd egyenként bemutatjuk, hogy ezeket hogyan használtuk fel esetünkben. Itt jegyeznénk meg, hogy az implementáció követi a modell alapú fejlesztés (Model-Driven Architecture, MDA) elveit. Ennek lényege, hogy a fejlesztés három szinten történik: az első szint egy platformtól független modell (platform-independent model, PIM), amelyet a vizsgálandó platformnak megfelelő modellre transzformálunk. Ez már a célplatform modellje (platform-specific model). Ezt az átmenetet adja az a lépés, amikor az importált BPEL2.0 modellt egy SAL modellbe transzformáljuk. A kooperáció esetén ez a lépés a kooperáció modelljének transzformálása SAL modellé. Ezt megelőzi egy PIM-PIM transzformáció, ami a BPEL2.0 modellt egy kooperációs modellbe absztrahálja. Az MDA záró lépése, amikor a PSM-ből futtatható kódot generálunk. Mindkét esetben ekkor állítjuk elő a futtatható SAL kódot ábra. A módszer végrehajtási fázisai A 8.1. ábrán láthatóak azok a lépések, amelyeket a módszer végrehajtásakor el kell végezni. Továbbá mutatja a lépések bemenetét és kimenetét. A 8.1. alfejezetben tárgyaljuk a metamodellezést, amelyen a gráftranszformáció alapszik. Magának a gráftranszformációnak az elméletébe a 8.2. alfejezet nyújt betekintést. A transzformációt a VIATRA keretrendszerben implementáltuk és hajtottuk végre. A VIATRA lehetőségeit a 8.3. pontban részletezzük. A következő, 8.4. részben szemléltetjük, hogyan alkalmaztuk az előző pontokban bemutatott technológiák lehetőségeit. Végül pedig a pontban azt is bemutatjuk, hogy hogyan használható az általunk elkészített eszköz. 77

78 78 FEJEZET 8. MEGVALÓSÍTÁS 8.1. Metamodellezés A metamodellezés célja, hogy az elkészíthető modelljeink számára egy keretet biztosítson. Oly módon, hogy absztrakt leírást ad arra, hogy milyen szabályoknak kell megfelelniük a modelljeinknek. A metamodellben specifikált kényszerek azok, amelyeket ki kell elégítenie egy konkrét modellezési nyelvnek és az alapján létrehozott modellnek. Akár jelölésrendszerként, akár konkrét szintaxisként az UML nyelv osztálydiagramjait és objektum-diagramjait szokás használni. [26] A könnyebb érthetőség kedvéért mi is így teszünk. Egy metamodell (MM) az alábbi elemekből állhat: Az osztály (class) a metamodell azon eleme, amely azonosítja a modellezési nyelv entitását. Hasonlóan az UML-hez vannak absztrakt osztályok is, amelyek közvetlenül nem példányosíthatók. Örökléssel alosztályok származtathatók az osztályokból. A konvenciók ekkor az eredeti osztályt szülőosztálynak nevezik. Ebben az esetben a származtatott osztály példánya egyben a szülőosztály példánya is. Továbbá a származtatott osztály megtartja a szülőosztály struktúráját, amelyet természetesen ki is bővíthet. Az osztályok példányai között úgynevezett asszociáció (association) hozható létre, ami egy bináris reláció. Az asszociáció kétfajta lehet: aggregáció (aggregation) és referencia (reference). Amennyiben tartalmazás jellegű, aggregáció, ha nem, akkor referencia. Az attribútum (attribute) egy tulajdonságot jelképez, amely az osztály paramétere. A metamodell alapján elkészített modell (M) a következő elemekből épülhet fel: Az objektumok (object) a metamodell nem absztrakt osztályainak példánya. Az objektumok egyedi azonosítókkal rendelkeznek. Az objektumokat kapcsolatok (link) köthetik össze, amelyek a metamodellbeli asszociáció példányai. A rekeszek (slot) a metamodellben definiált attribútumok tároló helyei az egyes objektumokban. Egy modellbeli elem típusa egy metamodellbeli elem. A típus tehát értelmezhető egy olyan függvényként, amely egy modellbeli elemhez egy metamodellbeli elemet rendel. Ez a függvény az alábbi megkötésekkel rendelkezik: Egy objektum típusa csak osztály lehet. Egy kapcsolat típusa csak asszociáció lehet. Azon belül is - értelemszerűen - vagy aggregáció, vagy referencia. Egy rekesz típusa pedig csak attribútum lehet. A 8.2. ábra szemlélteti a metamodellbeli osztályok és asszociációk, illetve a modellbeli objektumok és kapcsolatok összefüggését. Az ábra fenti részében látható két metamodellbeli osztály, köztük egy asszociációval. Az ábra alján pedig a modell két objektuma látható a köztük lévő referenciával. Az öröklési relációnak megfelelően egy objektumnak lehet közvetett típusa. Ez, az öröklés során, kapott típus az objektum szupertípusa (supertype). Így egy elem a közvetlen típusán túl megkapja az összes olyan osztálynak megfelelő típust, amelynek a közvetlen típus osztály leszármazottjai. A közvetlen típus az a metamodellbeli osztály, amelynek példánya az objektum.

79 8.2. GRÁFTRANSZFORMÁCIÓ Gráftranszformáció 8.2. ábra. A metamodell - modell kapcsolat A gráftranszformáció egy olyan módszer, amely szabályok és minták segítségével egy gráfból egy másik gráfot állít elő. Egy szabálynak bal és jobb oldala van. A bal oldalán található minta egy illeszkedését a gráfban a szabály jobb oldalán lévő mintára illeszkedő részgráfra cseréli le. A szabály akkor alkalmazható, ha talál a transzformálandó gráfban egy olyan részgráfot, amelyre illeszkedik a bal oldal, illetve nem illeszkednek a megadható negatív feltételek. A negatív feltételek tetszés szerinti mélységben egymásba ágyazhatók. Egy gráftranszformáció szabályt egy hattagú ennes ír le. Legyen r egy gráftranszformációs szabály, ahol r = (LHS, Neg, RHS, Cond, Assign, Par). A jelölések feloldása a következő: LHS a szabály bal oldalán lévő gráf. Ez a szabály végrehajtásának pozitív feltétele. Neg a negatív feltételeket jelképező gráfok halmaza. Ezek teljesülése megakadályozhatja a szabály végrehajtását. RHS a szabály jobb oldalán található gráf. Cond olyan logikai feltételek halmaza, amely az LHS illetve Neg-beli gráfokon túl további feltételeket támaszthat az LHS illetve Neg gráfjainak csúcsaiban található objektum attribútumaival szemben. Assign olyan értékadások halmaza, amely egy RHS csúcsbeli objektum attribútumait felülírhatja. Par pedig egy olyan függvény, amely fa struktúrába rendezve az LHS és Neg-beli gráfokat mint csúcspontokat megadja a fastruktúra bármely csúcspontjának közvetlen szülőjét. Ebben a fastruktúrában az LHS lesz a gyökérelem. A gráftranszformáció szabályainak bal illetve jobb oldalainak, gráfjainak csúcsai és élei nem kell, hogy diszjunkt halmazokat alkossanak. Tehát ugyanaz az objektum megjelenhet egy szabály bal és jobb oldalán egyaránt. Ezen túl pedig a bal oldalon a Par függvény által fa struktúrába rendezett gráfok között, ha két gráf között fennáll a szülő-gyerek viszony, akkor egy objektum mindkettőnek tagja lehet. A Par által képzett fa struktúra azonos szinten lévő csúcsai által reprezentált feltételek egymással ÉS kapcsolatban van. A fa struktúra egy szülő-gyerek kapcsolatában a szülő feltételének a negatív feltétele lesz a gyerek csúcs feltétele. Ez azt is jelenti, hogy tetszőleges mélységben egymásba ágyazhatók a negatív feltételek.

80 80 FEJEZET 8. MEGVALÓSÍTÁS A gráftranszformáció talán legfontosabb lépése a gráfmintaillesztés. A gráfmintaillesztés keresi meg a gráfunkon azokat a részeket, ahol alkalmazhatók a gráftranszformációs szabályok. Az alkalmazhatóságnak pozitív illetve negatív feltételei vannak. Legyen G gráf LHS, vagy Neg halmaznak egy gráfja. Pozitív minta esetén léteznie kell G gráfnak egy izomorf, de legalább homomorf képének az M modellben, azaz a gráftranszformáció szabály kizárólag akkor alkalmazható a pozitív mintára, ha: G minden csúcsa típushelyesen leképezhető egy M modellbeli csúcsra. Ha izomorf a mintaillesztés, akkor az M-beli objektumoknak különbözőnek kell lenni; G minden éle típushelyesen illeszkedik egy M modellbeli élre; G egy tetszőleges csúcsának attribútumaira megadott feltételt kielégítenek a csúcsnak megfelelő M modellbeli objektum attribútumai. Negatív minta esetén legyen G egy tetszőleges gráf Neg-ben. Minden G -re igaz, hogy nem lehet M modellben olyan objektumhalmaz, amelyre illeszkedik G illetve G-nek közvetlen leszármazottja lenne, tehát par(g ) = G. Amikor ezeket az illesztéseket vizsgáljuk, akkor a szülő gráfok mindegyikén elvégzett illesztéseket megőrizzük, és szükség esetén kibővítjük. Egy gráftranszformációs szabály alkalmazása során egy M modellt egy M modellre transzformál azzal, hogy a szabály bal oldalát (LHS) lecseréli a szabály jobb oldalára (RHS). A szabály alkalmazásának lépései a következők 1. Gráfmintaillesztés. Megkeressük az M modellben az LHS egy illeszkedését, ez az illeszkedés már magában foglalja Neg negatív feltételeit és a Cond által támasztott extra attribútum feltételeket. 2. Eltávolítás. Minden olyan elemet törlünk a modellből, amire illeszkedik LHS, de nem illeszkedik RHS. 3. Behelyettesítés. RHS-t hozzákapcsoljuk az M modellhez ezzel létrehozva M modellt. A hozzákapcsolás praktikusan úgy történik, hogy új objektumokat és kapcsolatokat hozunk létre azon elemek számára, amelyek RHS-ben benne vannak, de LHS-ben nincsenek. Továbbá az Assigban leírt attribútum frissítéseket végrehajtjuk. Általában szokás az RHS-t utófeltételnek is hívni, hiszen az általa meghatározott objektumoknak és a köztük lévő kapcsolatnak jelen kell lennie a transzformáció eredményeképpen kapott modellben. Amennyiben olyan gráftranszformációs szabályt szeretnénk írni, amely nem törli ki a szabály LHS-jét, úgy ugyanazt a gráfot a RHS-ban is el kell helyeznünk. Ha M modell több helyén is illeszthető a minta, akkor nemdeterminisztikus módon döntendő el, hogy melyik illeszkedést cseréli le a jobb oldalra. Vizsgálódásunk során három helyen használunk gráftranszformációt. Először akkor, amikor a BPEL2.0 munkafolyamatokat reprezentáló modelleket a nekik megfelelő SAL modellekbe alakítjuk át. Másodszor akkor, amikor az egyes BPEL2.0 modellekből egy közös, absztraktabb kooperációs modellt hozzunk létre. Végül pedig akkor, amikor a kooperáció modelljéből egy SAL modellt hozunk létre. Voltaképpen technikai szempontból egy negyedik és ötödik alkalommal is használunk gráftranszformációt, de ezek teljesen automatikusak, és nem hoznak létre új modellt, csak a vizsgálható állományt bocsátják rendelkezésünkre. A transzformációs programunk a gráftranszformáció ezen fejezetben ismertetett elméletén alapul. A következő alfejezetben ismertetett VIATRA keretrendszer modelltere lesz számunkra az a gráf, amelyen a gráftranszformációk szabályait használjuk, hogy így hozzunk létre új, a vizsgálódás szempontjából értékes modelleket.

81 8.3. VIATRA 2 MODELLTRANSZFORMÁCIÓS KERETRENDSZER 81 Felmerülhet a kérdés, hogy a modelltranszformációs módszerek közül miért pont a gráftranszformációt választottuk. Imperatív nyelvekkel szemben, mint például a Java óriási előnyt jelent, hogy a mintaillesztések megtalálása deklaratív módon megadható így nem kell bonyolult mintaillesztési kódot implementálnunk, hiszen ezek a VIATRA rendszerében már megtalálhatók. Egy másik elterjedt, szintén transzformációs eszközzel, az Extensible Stylesheet Language Transformations (XSLT) szemben előnye, hogy utóbbinak skálázhatósági és bonyolultabb mintaillesztési feladatoknál teljesítménybeli gyengeségei vannak. [10] 8.3. VIATRA 2 modelltranszformációs keretrendszer A Visual Automated model Transformations (VIATRA2 R3) keretrendszer segítségével valósítottuk meg a programunkat. A VIATRA maga egy nyílt forrású Eclipse alapú eszköz, integrációs (tool integration) környezet, amely így könnyedén bővíthető további komponensekkel. A VIATRA biztosít bővítési pontokat számunkra, amelyekhez tetszés szerint illeszthetjük saját komponenseinket. A VIATRA a Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnikai és Információs Rendszerek Tanszékénen fejlesztett hivatalos Eclipse alproject. [1] Modelltér A VIATRA egy hierarchiukus modelltérben tárolja azokat az elemeket, amelyek a transzformációk tárgyai lesznek. A modelltérben a ModelElement absztrakt ősosztályból két típus származtatható: az entitás (entity) és a reláció (relation). Az alábbi képen mutatja meg a három elem közötti viszonyt ábra. VIATRA modelltér elemei Egy ModelElement lehet egy másik ModelElementnek példánya és ősosztálya. Minden Model- Elementnek egy String típusú attribútuma van, a neve. Ezen kívül van egy származtatott attribútuma, amely egy egyedi azonosító (fully qualified name fqn). A modelltér szigorú hiearchiájában azonos szinten lévő elemek lokális neve egyedi kell, hogy legyen. Egy elem egyedi azonosítóját úgy kaphatjuk meg, hogy a tartalmazó hierarchia szintjeinek lokális neveit összevonjuk, pontokkal elválasztva őket. Így előfordulhat, hogy bár két elemnek azonos a lokális neve, de az FQN különbözősége miatt egyértelműen azonosítható marad. A fa struktúra úgy áll elő, hogy egy entitás tartalmazhat egy másik entitást és relációt, amit az ábrán a contains él mutat. Ebből adódik az a megkötés, hogy a containment kapcsolatok mentén nem lehet kör a modelltérben. Egy entitáshoz

82 82 FEJEZET 8. MEGVALÓSÍTÁS rendelhetünk egy értéket, amit a String típusú value attribútum tárol. Egy reláció két ModelElement közt teremt kapcsolatot. Egy reláció felfogható egy irányított élként, ahol a gráf csomópontjai az entitások. Ennek megfelelően van egy ModelElement, amelyből kiindul és egy amelybe mutat. A relációkat automatikusan a kiinduló elemhez rendeljük ebben a hierarchiában. A relációknak két tulajdonságuk lehet: isaggregation és Mulitplicities. Előbbivel megadható, hogy a relációt birtokló elem tartalmazza-e a reláció célelemét. A Multiplicities tulajdonsággal megadható egy reláció multiplicitása. A multiplicitás lehet egy-egy (one-to-one), egy-több (one-to-many), több-egy (many-to-one) vagy több-több (many-to-many) Navigáció a modelltérben Ahhoz, hogy egy VIATRA modelltérben található elemek segítségével a célunknak megfelelő modelleket építhessünk, két fajta állomány elkészítése szükséges. Létre kell hoznunk azokat a metamodelleket, amelyek fontosságát a 8.1. részben részleteztük. A metamodellek alapján létrehozott modellekben történő navigáláshoz illetve módosításához pedig szükségünk lesz egy vagy több vezérlő állományra. Metamodellek A VIATRA2 által biztosított metamodellezési nyelv Viatra Textual Metamodeling Language(VTML), amely a Visual and Precise Metamodeling (VPM) metamodellezési megközelítést alkalmazza. A metamodell az entitás és reláció alapelemekből áll. Az entitás jelöli a doménspecifikus modellezés elemeit, míg a reláció a köztük lévő viszonyokat. Az entitásokhoz rendelt literál típusú értékek alkalmazás-specifikus információt hordozhatnak. Egy entitás deklarálása a type(name) formában történik, ahol type az elem típusa, a name pedig egy eddig nem használt név. A reláció deklarálásának formája a type(name, source, target), ahol a type és a name az entitás deklarálásához hasonlóan a típus és a név, míg a source a reláció kiinduló vége, a target pedig a célelem. Minden modellelem deklarálásakor kötelező típust megadni. A típusok hierarchiába szervezhetők, amelynek tetején a VPM alap entitása (entity) és relációja (relation) áll. A VTML lehetővé teszi az öröklés és a példányosítás jelölését is. Előbbi a supertypeof (szupertípus, öröklő típus) formában adható meg. A példányosítás az instanceof(példány,típus) formában adható meg. A példán jól látszik, hogy külön meg kell adnunk azt, hogy egy reláció tartalmazás típusú-e, alapértelmezetten nem tekintjük annak. Vezérlő állományok A VIATRA modellek kezelésére minta és szabály alapú nyelv a Viatra Textual Command Language (VTCL). A VTCL definiál tehát mintákat, gráftranszformációs szabályokat, valamint a vezérlési szerkezetet definiáló absztrakt állapotgép programok elemeit: változók, szabályok és asm függvények. Ezen túl a VTCL lehetővé teszi úgynevezett natív függvények (native function) használatát, melyet a felhasználó Java nyelven írhat meg a VIATRA keretrendszerben. A VTCL állományok tartalmazzák tehát a transzformáció megvalósítását, itt adjuk meg, hogy milyen mintákra keresünk illeszkedést és ez milyen formában módosítja a transzformáció eredményeképpen kapott modellt. Ha egy szabály mintája több helyen is illeszkedik a gráfban, akkor két különböző stratégiát választhatunk a végrehajtására. Ez a két konstrukció a choose és a forall. A choose nem-determinisztikus módon választja ki a több illeszkedés közül az egyiket. Ezt megismételtethetjük iteratív módon, ebben az esetben, addig hajtja végre a megadott szabályt, ameddig talál illeszkedést. Ezzel ellentétben a forall összegyűjti az összes illeszkedést és végrehajtja minden

83 8.4. MEGVALÓSÍTÁS 83 egyes esetben a szabályt. Felhívjuk a figyelmet, hogy a kettő nem ugyanaz. Az iterate-choose párossal minden esetben megnézzük, hogy továbbra is fennállnak-e más illeszkedési lehetőségek Megvalósítás Ebben a részegységben fogjuk részletezni, a korábbi fejezetekben ismertetett koncepció megvalósítását. Nem célunk, hogy részletekbe menően dokumentáljuk a programkódok részeit. Nagyobb vonalakban bemutatjuk a tervezői döntéseket és apróbb részletekkel illusztráljuk azokat BPEL 2.0 A BPEL2.0 alapú munkafolyamatok modellezéséhez a 4. és az 5. fejezetekben részletezett módszer szerint a munkafolyamatok leírása alapján tranzíciós rendszer leírást készítünk. A következőkben bemutatjuk azokat a metamodelleket, modell előállító programokat, és transzformációkat amelyek segítségével létrehozzuk a vizsgálható rendszert. Metamodellek Ahhoz, hogy a munkafolyamat leírásokat és tranzíciós rendszereket modellezni tudjuk, szükség van azokra a metamodellekre, amelyek meghatározzák a modellekben létrehozható elemeket és a modellbeli elemek közötti relációkat. A munkafolyamatok leírásának szabályait a BPEL2.0 szabványban megadott XML séma definíció határozza meg. Ez a séma tartalmazza azokat az elem definíciókat és tartalmazási szabályokat, amelyek alapján létrehozhatók a munkafolyamatok helyes XML leírása. A BPEL2.0 metamodell létrehozásakor ezt a sémát használtuk fel. Mivel a metamodellek definiálása a VIATRA-ban hasonló módon történik, mint az XML sémák definiálása, ezért a metamodell létrehozásakor nem az alapelemek meghatározása jelentette a kihívást, hanem azoknak a kiegészítő relációknak a létrehozása, amelyek a transzformáció végrehajtásához szükségesek. Ilyen relációk segítségével kötjük össze az egyes tevékenységeket és az általuk használt változókat. A BPEL2.0 metamodell létrehozásával azonos módon készítjük el a webszolgáltatások specifikációját tartalmazó WSDL leírás metamodelljét. Ebben az esetben is rendelkezésre áll az XML séma definíció, amely alapján a metamodell létrehozható. Mivel a BPEL2.0 és a WSDL is XML alapú leírás, ezért érdemes létrehozni egy absztrakt XML metamodellt, amely a metamodellek alapjául szolgáló EMF metamodellt elfedi. Az XML metamodellben definiáljuk az XML elemet, továbbá az attribútum és a tartalmazás relációkat. A BPEL2.0 metamodell létrehozásakor így csak az XML metamodell elemeire kell hivatkoznunk. A 8.1. részlet a BPEL2.0 metamodellben egy elem definícióját mutatja. entity ( tassign ){ // Containments relation ( containment_ copy, tassign, tcopy ); isaggregation ( containment_ copy, true ); supertypeof ( containment, tassign. containment_ copy ); relation ( containment_ extensionassignoperation, tassign, textensionassignoperation ); isaggregation ( containment_ extensionassignoperation, true ); supertypeof ( containment, tassign. containment_ extensionassignoperation ); // Attributes relation ( attribute_ validate, tassign, datatypes. String ); supertypeof ( element. attribute, tassign. attribute_ validate ); } supertypeof ( element, tassign );

84 84 FEJEZET 8. MEGVALÓSÍTÁS supertypeof ( tactivity, tassign ); Részlet 8.1. BPEL elem metamodellbeli definíciója A tranzíciós rendszerek metamodelljének létrehozásához szintén egy létező definíciót használtunk fel. A SAL nyelvhez elérhető az XML alapú dokumentum típus definíció (DTD), amely a séma definícióhoz hasonló. A felhasznált DTD meghatározza a felhasználható elemeket, azok attribútumait és a tartalmazási relációkat. A metamodell a DTD-ben meghatározott elemeken és relációkon kívül mást nem tartalmaz, mivel a SAL modellben nincsenek név alapú referenciák, amelyekhez kiegészítő relációk felvétele szükséges lenne. Egy példa elem metamodellbeli megfelelője olvasható a 8.2. részleten. EMF. EClass ( TRANSDECL ){ EMF. EClass. EAttribute ( place, TRANSDECL, PLACE ); isaggregation ( place, true ); EMF. EClass. EReference ( definitionorcommand_, TRANSDECL, DEFINITIONORCOMMAND_ ); isaggregation ( definitionorcommand_, true ); } Részlet 8.2. SAL tranzíció metamodellbeli definíciója A transzformáció során szükség van egy olyan modellre, amelyben a használt BPEL2.0 modell egyes elemei és a létrehozott SAL modellbeli megfelelőik közötti kapcsolatokat tároljuk. Erre azért van szükség, mert a végrehajtás modellezésekor a megfelelő BPEL2.0 elemeket reprezentáló SAL változókat ezen relációk alapján találjuk meg. Egy ilyen megfeleltetés definíciója látható a 8.3. részleten. entity ( tactivity2identifier ) { relation ( tactivity_side, tactivity2identifier, textensibleelements ); relation ( IDENTIFIER_side, tactivity2identifier, IDENTIFIER ); } Részlet 8.3. Referencia elem metamodellbeli definíciója Az eddig említett metamodellek mellett használunk egy kiegészítő metamodellt, amely a SAL metamodellt egészíti ki. Ebben a metamodellben olyan elemeket definiálunk, amelyek SAL metamodellbeli elemek leszármazottai (tehát öröklik az eredeti tartalmazásokat és relációkat), de megkülönböztető nevet kapnak. A transzformáció során ez a megoldás sok esetben megkönnyíti az elemek megtalálását. Emellett olyan elemeket is létrehozunk, amelyek összetett nyelvi szerkezeteket jelképeznek és a SAL sémában nincsenek explicit definiálva. Ilyen például a feltétel értékadáshoz használt szerkezet, vagy az infix műveletet leíró elem, melynek definícióját mutatja a 8.4. részlet. entity ( INFIXOPERATION ){ relation ( leftop, INFIXOPERATION, EXPRESSION_ ); isaggregation ( leftop, true ); relation ( rightop, INFIXOPERATION, EXPRESSION_ ); isaggregation ( rightop, true ); relation ( operator, INFIXOPERATION, EXPRESSION_ ); isaggregation ( operator, true ); } Részlet 8.4. Kiegészítő SAL elem metamodellbeli definíciója

85 8.4. MEGVALÓSÍTÁS 85 Modellek előállítása A vizsgált munkafolyamatok modelljét a metamodellek alapján építhetjük fel. A modell létrehozást automatizálhatjuk a VIATRA bővíthetőségének köszönhetően. Az automatizálást egy Java nyelven írt importáló program segítségével valósítjuk meg. A munkafolyamatok leírása és a webszolgáltatások specifikációja is XML állományok formájában áll rendelkezésünkre, amelyek feldolgozásához a Java beépített Document Object Model (DOM) alapú megvalósítását használjuk. A program a feldolgozó segítségével rekurzívan végighalad az összes elemen és létrehozza a megfelelő modellelemeket a VIATRA modelltérben. A séma definícióban szereplő elemeket és relációkat generikus módon, míg a kiegészítő relációkat az elem típusától függően hozzuk létre. A 8.5. részleten a BPEL2.0 leírás alapján modellt előállító program egy része látható. String relationname = vclass. getfullyqualifiedname () + ". containment_ " + getlocal ( xnodechildren. item (i). getnodename ()); IRelation vrelation = m. getrelationbyname ( relationname ); IEntity vtoclass = ( IEntity ) vrelation. getto (); IEntity vnewnode = m. newentity (" bpel2_ "+ getlocal ( xnodechildren. item ( i). getnodename ()) + elementid, model ); if ( vtoclass. getfullyqualifiedname (). equals (" datatypes. String ")) { m. setvalue ( vnewnode, xnodechildren. item (i). gettextcontent ()); } m. newinstanceof ( vtoclass, vnewnode ); Részlet 8.5. BPEL2.0 modell előállító Transzformációk A metamodellek alapján létrehozott BPEL2.0 modelleknek megfelelő tranzíciós rendszer modelleket egy VTCL állományban megvalósított transzformáció segítségével készítjük el. A transzformációban ASM szabályokat és mintákat használunk. A transzformáció egyszerűsített folyamata látható a 8.4. ábrán. A transzformáció futtatásakor ki kell választani a megfelelő BPEL2.0 modellt, ezután a tranzíciós rendszer modellje automatikusan létrejön. A végrehajtás kezdetén lefut a porttype- Resolver szabály, amely megkeresi a BPEL2.0 modellhez tartozó WSDL modellt és annak tartalma alapján kiegészíti a BPEL2.0 modellt webszolgáltatás specifikus elemekkel. Ezután létrejön egy új entitás a tranzíciós rendszer modellnek. Majd a makeindependents szabály hívódik meg, amely a BPEL2.0 modelltől független elemeket hozza létre az új modellben (a rendszerkörnyezet és a típusdeklarációk). Következő lépésként a makeprocesshost szabály létrehozza a folyamat legfelső szintjét jelző processhost elemet. Végül a transformprocess szabály alkalmazása következik, amely transzformáció lényegi részét képző, modellfüggő tranzíciós rendszer részleteket hozza létre. A transformprocess szabály futása három szakaszra bontható, amelyek megfelelnek a tranzíciós rendszerben létrehozott modulban megfigyelhető három résznek. Az első rész az állapotváltozók definiálása, amelyet a declarex Var szabályok segítségével hajt végre a transzformáció (ahol X az adott BPEL2.0 elem). A második rész az állapotváltozók inicializációjának létrehozása, amelyre az initx Var szabályok használhatóak. Végül a harmadik rész a tranzíciók elkészítése, amelyeket az impx Trans szabályok hoznak létre. Kódgenerálás. Ahhoz, hogy az elkészített tranzíciós rendszer modellen ellenőrzéseket futtathassunk, először létre kell hoznunk a modellből a szöveges leírást. Ehhez egy másik transzformációt használunk, amely a kiválasztott tranzíciós rendszer modellből SAL leírást generál. A transzformáció a modell gyökéreleméül szolgáló Context elemmel kezdi a végrehajtást. Ez a tranzíciós rendszerben a rendszerkörnyezetnek felel meg. Ezután a transzformáció végighalad a modellen és

86 86 FEJEZET 8. MEGVALÓSÍTÁS 8.4. ábra. Transzformáció folyamata a SAL nyelvtannak megfelelően létrehozza a rendszerleírást, amelyet egy külön állományban helyez el. A transzformáció elvégzése után a létrejött állomány már használható a SAL keretrendszer eszközeivel és a modellellenőrzés elkezdhető Kooperáció A kooperáció modellezése során a 6. alfejezetben részletezettek szerint BPEL források importálásával előállított BPEL modellekből állítunk elő egy olyan absztrakt modellt, amely az egyes BPEL folyamatok együttműködését adja meg úgy, hogy mindeközben a modellfinomítás megkezdése előtt a BPEL folyamat belső viselkedéséről semmit nem tudunk. Ebben a pontban azt mutatjuk be, hogy milyen metamodelleket és transzformációkat használunk ehhez. Metamodellek A kooperáció modellezése során a BPEL folyamatokat, mint absztrakt fekete dobozokat tekintjük. Ezeket a dobozokat csomópontoknak nevezzük a kooperáció gráfjában. Egy csomópontot jelképező modellelem node típusú. Minden ilyen csomópontnak vannak bemenő és kimenő pontjai. Egy bemenő ponton érkezik egy üzenet, míg egy kimenő ponton távozik. Egy bemenő pont típusa input, míg a kimenő típusa output. Ennek megfelelően egy BPEL Receive, szinkron Invoke, OnMessage tevékenységnek felelhet meg egy-egy input, míg bármilyen Invoke, és Reply tevékenységnek egy output. Ennek megfelelően egy szinkron Invoke-nak egy input-output pár felel meg, míg egy aszinkron invoke egy output-nak felel meg. A node és az input és output közötti élek tartalmazás jellegűek. Ezt a 8.5. ábrán adtuk meg. A metamodell másik része azt hivatott megjeleníteni, hogy az egyéni BPEL folyamatok a kommunikációs tevékenységeiken keresztül hogyan kapcsolódnak össze. Egy összekapcsolódás egy input

87 8.4. MEGVALÓSÍTÁS 87 és egy output elem között létezik. Egy ilyen összekapcsolódás a kommunikációs csatorna szimbolizálása révén a channel nevet kapta. Egy channel minden esetben egy input és egy output elemhez kapcsolódik. A reláció nem tartalmazás jellegű ábra. Az absztrakt modell metamodellje Mivel a kooperációt elemző állományt is SAL nyelven vizsgáljuk, ezért a kooperáció modelljéből egy SAL modellt állítunk elő. Ehhez szükséges egy SAL metamodell is, amely azonos a BPEL2.0 modellezésénél használt metamodellel. Ezen kívül vannak még speciális metamodelljeink, amik a modellezésben annyi szerepet játszanak, hogy megfeleltetést adnak egy BPEL elem és egy kooperációbeli elem, illetve egy kooperációbeli elem és egy SAL elem között. Ezt a részben, a Referenciamodelleknél tárgyaljuk. Transzformációk A BPEL2.0 munkafolyamatok halmazából először egy BPEL-hálózatmodellt kell transzformálni. Majd azután kell egy neki megfelelő SAL modellt generálni, végső lépésként pedig előállítjuk a futtatható állományt. A transzformációkat egy közös transzformációban egyesítve a 8.6. ábra mutatja be. A main a transzformáló machine belépési pontja. Első lépésben létrehozzuk az kialakítandó modell azon részét, amely független az együttműködésben résztvevő folyamatoktól. Ebben a szakaszban hozzuk létre a modellek keretét (createmodel), a modellezés során használt típusokat és azok értékkészleteit (createtypes), amelyek a 6.2. táblázatban már részletezett állapotoknak felelnek meg. Ezt követően rekurzív módon előállítjuk a kooperáció absztrakt modelljét (create- Cooperation). Ez az első modelltranszformáció, amikor az önálló folyamatcsonkokból 1 az együttműködés egy absztrakt reprezentációját állítjuk elő. A program indításakor 2 megadott folyamat transzformálódik elsőként (transformprocess) egy absztrakt csomóponttá (abstractprocess). Amennyiben van a folyamatnak Invoke eleme, úgy annak mentén megkeresi a folyamatcsonkok modelljei között a kommunikáló partnert. Amennyiben nincsen Invoke eleme, úgy a szabvány előírásai szerint nem kezdeményez kommunikációt más webszolgáltatásokkal. Az Invoke-nak az alábbi attribútumaira van szükségünk: partnerlink A kommunikációs partnert azonosítja myrole: a kommunikáló folyamat saját szerepe, 1 Megjegyezzük, hogy a 6. alfejezetben részletezett okokból nincsen szükségünk a teljes BPEL állományra, hanem annak egy redukált változata is elegendő számunkra. Természetesen a teljes BPEL állomány ismeretében is ugyanúgy elvégezhető az absztrakció. 2 A megoldásunk használatát részletesen a alfejezetben tárgyaljuk.

88 88 FEJEZET 8. MEGVALÓSÍTÁS 8.6. ábra. A kooperáció transzformációja partnerrole: a kommunikációs partner szerepe és partnerlinktype: a kapcsolat típusa alapján. operation Ez az attribútum adja meg, hogy milyen műveletet hív meg, illetve, melyikre válaszol a folyamat. A kommunikáció során nincs szükségünk a porttype attribútumra, mivel a BPEL 2.0 szabványa alapján az opcionális. Ezt az indokolja, hogy a partnerlinktype WSDL-ben megadott definíciójában kell egyértelművé tenni a hívandó porttype-ot. A transzformáció minden Invoke-ra megvizsgálja, hogy az egy hagyományos invoke, vagy callback Invoke-e. Ez azért fontos, mert a callback Invoke mentén nem található meg a másik kommunikáló fél, ő ugyanis arra szolgál, hogy egy aszinkron kérésre választ adjon. Így az ő esetében nem keressük meg a vele kommunikáló BPEL folyamat modelljét, hiszen a kérést küldő folyamatot már egy rekurzióval korábban transzformáltuk. Egy hagyományos aszinkron és szinkron invoke tevékenység esetében megkeressük az Invoke Operationjét és PartnerLinkjét, utóbbinak pedig PartnerLinkType, PartnerRole és MyRole tulajdonságát. Ezek alapján megtalálható a hívott szolgáltatás WSDL-je. Amennyiben nincsen ilyen WSDL, úgy tekintjük, hogy a hívott web-szolgáltatás

89 8.4. MEGVALÓSÍTÁS 89 mögött nem egy BPEL üzleti folyamat van. Így a kooperáció analízise során ez a web szolgáltatás nem vesz részt. A szabványnak megfelelően, legalább a partnerrole, vagy a myrole attribútumnak definiálva kell legyen egy Invoke-ban. Az Invoke által biztosított információk alapján megtalált WSDL-nek megfelelő BPEL-t megkeressük a BPEL-modellek között (seekcooperatingbpel), majd megvizsgáljuk, hogy létezik-e a folyamatnak megfelelő csomópont a kooperáció modelljében (Not transformed?). Amennyiben van, akkor nincs további dolgunk vele, rátérhetünk az eredeti BPEL többi Invoke-jának vizsgálatára. Amennyiben még feldolgozatlan, a kooperációban résztvevő BPEL-re találtunk, úgy azt is transzformálnunk kell egy csomóponttá és rekurzívan elvégezzük a részletezett vizsgálatokat az Invoke elemeire. Még mielőtt továbblépnénk azonban minden Invoke tevékenységhez az általa biztosított információk alapján megkeressük a neki megfelelő inputot illetve szinkron Invoke esetén a neki megfelelő outputot is. Majd létrehozunk minden ilyen kommunikációs párhoz egy channel típusú elemet(createchannels). A kooperáció modelljéből egy SAL modellt állítunk elő a vizsgálható forrás előállításához. Ezt a transformcooperation transzformáció végzi el. Minden node csomópont egy BASEMODULE modulnak felel meg(transformnode). Minden folyamathoz, tevékenységhez és minden tevékenységhez tartozó BPEL változóhoz egy SAL változót rendelünk(declarevariable). Ezek deklarációja globális lesz, hiszen azt szeretnénk, hogy másik folyamatok BASEMODULE-jai is módosíthassák azokat, ha egy kommunikációs interakció során ezekben változás állna be. A változók típusa azonos a BPEL 2.0 SAL-beli modellezésével. Az inicializáláskor a tevékenységek startable állapotba kerülnek, a változók pedig variableuninited-nek megfelelő healthy értéket veszik fel. A folyamatokat jelképező modulokba kerülnek azok a tranzíciók (createabstracttransitions), amelyek a tevékenységek precedenciáját definiálják. Ezek a következő alakban szerepelnek: Local_ education_ receive39_ precedes_ Local_ education_ reply19 : ( Local_ education_ receive39 = finished AND Local_ education_ reply19 = startable ) --> Local_ education_ reply19 = finished ; var_ Local_ education_ reply19 = healthy ; Részlet 8.6. Két tevékenység precedenciája Ezen túl van egy speciális BASEMODULE, amelynek nincsenek saját változói, hanem a többi module változóit módosíthatja. Ez a különleges module reprezentálja a csatornát (transform- Channels), ebben találhatók meg azok a tranzíciók, amelyek két folyamat közötti vezérlésátadást jelzik. Local_ administration_ invoke24_ triggers_ CourseChange_ receive17 : ( CourseChange_ invoke24 = read AND Local_ administration_ receive17 = startable ) --> Local_ administration_ receive17 = finished ; var_ Local_ administration_ receive17 = IF ( var_ CourseChange_ invoke24 = healthy ) THEN healthy ELSE faulty ENDIF ; Részlet 8.7. Két tevékenység precedenciája Végezetül pedig a kész SAL modellt a codegeneration transzformációval egy forrásfájlba generáljuk kód formájában. Referenciamodellek A referenciamodellek arra szolgálnak, hogy különböző metamodellek alatti elemeket rendeljenek össze. Így azonos típusú elempárok esetén is pontosan tudjuk, hogy az egyik modellbeli elemhez egy másik modellben melyik elem tartozik. Például minden BPEL2.0 folyamat modelljéhez tartozik egy node típusú csomópont.

90 90 FEJEZET 8. MEGVALÓSÍTÁS entity ( Process2Node ){ relation ( process_side, Process2Node, bpel. metamodels. bpel2_metamodel. tprocess ); relation ( node_side, Process2Node, coop. metamodels. coop_metamodel. node ); } Részlet 8.8. Folyamat megfeleltetése csomópontnak Hasonlóan minden tevékenységhez tartozik egy input vagy output. Például Receive esetén: entity ( Receive2Input ){ relation ( receive_side, Receive2Input, bpel. metamodels. bpel2_metamodel. treceive ); } relation ( input_side, Receive2Input, coop. metamodels. coop_metamodel. input ); Részlet 8.9. Receive megfeleltetése inputnak A referenciát feloldó elemek relációi természetesen nem tartalmazás jellegűek, csak egy-egy mutatóval jelzik, hogy mely elemek felelnek meg egymásnak. Az elemeket egy külön referenciamodellben tároljuk a kooperáció modelljén belül. A BPEL2.0 és a kooperációt összekötő referenciamodell és a BPEL2.0 modelljének transzformálásakor létrehozott, azt a SAL-lal összekötő referenciamodell segítségével implicit módon megtalálhatjuk a kapcsolatot egy kooperációbeli elem és egy SAL-beli elem között, anélkül, hogy emiatt egy új modellt kelljen létrehozni.

91 9. fejezet Értékelés Dolgozatunk célja az volt, hogy kidolgozzunk egy olyan módszert, amellyel együttműködő és önálló folyamatok BPEL 2.0 nyelvű leírása alapján matematikai precizitással és a tervezőmérnökök által automatikusan ellenőrizhető azok működése. Ezekből a leírásokból felépített modellekből SAL nyelvű tranzíciós rendszer leírást készítünk transzformációk végrehajtásával. Az eredményül kapott SAL tranzíciós rendszer leíráson lineáris temporális logikai kifejezésekkel megfogalmazott követelményeket vizsgáltunk modellellenőrzéssel. A munkafolyamatok esetünkben a BPEL 2.0 szabványnak megfelelő munkafolyamatok leírása nem alkalmas formális verifikáció elvégzésére. Tulajdonságok precíz vizsgálathoz szükséges tehát egy olyan megoldás kialakítása, amellyel a munkafolyamatok és a velük szemben támasztott követelmények egyaránt formalizálhatók. Koncepcionális eredmények A korábbi kutatások során [17] kidolgozásra került egy olyan módszer, amely automatikusan transzformálja a munkafolyamatokat Promela nyelvre, továbbá emberi beavatkozás nélkül képes a formalizálásra. Az ennek segítségével előállított állományok egy SPIN [16] nevú eszközzel már formálisan ellenőrizhetőek voltak. Az általunk bemutatott megoldás a következőkben nyújt többet ennél: A BPEL legújabb 2.0-s szabványban felhasználható elemek jelentős részét képes modellezni. Képes munkafolyamatok együttműködésének formalizálására és ellenőrzésére Lehetőség van a munkafolyamatokban esetlegesen előforduló hibák hatásának vizsgálatára hibainjektálás segítségével. A dolgozatban használt esettanulmány folyamatain ellenőrzéseket végeztünk annak érdekében, hogy a módszer használhatóságát demonstráljuk. Az végrehajtott ellenőrzéseket és azok eredményeit részletesen ismertettük. A folyamatokat két szinten modellezzük, a konkrét modellek önálló folyamatok működését írják le, míg az absztrakt modellek az együttműködő folyamatok ellenőrzéséhez használhatóak. Ez újszerű megközelítés, melyet a BPEL folyamatok ellenőrzésében eddig nem használtak. A kooperáló munkafolyamatok ellenőrzéséhez kidolgozott modellfinomításon alapuló módszer lehetőséget ad arra, hogy egy kezdetben teljesen nemdeterminisztikus modellel közelítsük a valódi viselkedést. Az iteratív finomító lépéseket amelyek segítségével egyre pontosabbá tehetjük absztrakt modellünket egyénileg végezheti el az együttműködő folyamat tulajdonosa. 91

92 92 FEJEZET 9. ÉRTÉKELÉS Ezzel tettük lehetővé, hogy üzleti partnerek közötti kooperáció esetén is lehetséges legyen a formális verifikáció, anélkül, hogy a partnereknek fel kellene fedniük az üzleti logikájukat tartalmazó BPEL forrásuk teljes tartalmát. Implementációs eredmények A VIATRA2 keretrendszer segítségével megvalósítottuk a módszerben használt programokat és transzformációkat. Elkészítettük a BPEL 2.0 munkafolyamatok és az absztrakt rendszer metamodelljét (összesen 2000 kódsor) a VIATRA2 metamodellezési nyelvében. Elkészítettük a BPEL 2.0 munkafolyamat leírása alapján folyamat modellt generáló Java programot (1000 kódsor), amely a VIATRA2 keretrendszer kiegészítése. Elkészítettük a folyamat modell alapján tranzíciós rendszer modellt készítő transzformációt (8200 kódsor), amely automatikus és könnyen használható. A létrehozott tranzíciós rendszer leírásokat a robosztus SAL modellellenőrző eszköz segítségével vizsgáltuk. Továbbfejlesztési irányok Módszerünk a SENSORIA project Sensoria Development Environmentbe történő integrálásával járulhat hozzá ahhoz, hogy a szolgáltatás-orientált architektúrák részeként szélesebb körben nyújtson verifikálási lehetőséget. A modellezés során nagy hangsúlyt fektettünk arra, hogy a vizsgálható BPEL folyamatok halmazát később kiterjeszthessük azokra az esetekre, amelyek jelenleg megoldatlan problémákat vetnek fel. Jövőbeli terveink között szerepelnek a következő irányok: Fontos szempont lesz a jövőben, hogy az absztrakt modell finomítása automatikusan történjen. Így a felhasználónak már ténylegesen csak a folyamatok forrásait, illetve kooperáció vizsgálata esetén a folyamatcsonkokat kell megadnia és a rendszerünk az ellenőrzés végén automatikusan prezentálja a végeredményt. A felhasználói kényelem érdekében terveink szerint egy grafikus felületen adhatók meg a követelményspecifikációk és jeleníthetők meg azok végeredményei. Szintén jelentős szerepet szánunk annak, hogy a felhasználó ne csak az előre specifikált hibákat ellenőrizhesse, hanem maga adhasson meg egy doménspecifikus hibamodellt, amelyet a rendszerbe injektálva az adott kooperáció sajátos hibáit deríthesse fel. Például banki folyamatok esetén a bankszámla adatokra, tranzakciókra összetett hibákat lehet definiálni.

93 Irodalomjegyzék [1] The Viatra-I Model Transformation Framework Users Guide, org/viewcvs/indextech.cgi/gmt-home/subprojects/viatra2/index.html. [2] W. Aalst, M. Dumas, C. Ouyang, A. Rozinat, and H. M. W. Verbeek. Choreography conformance checking: An approach based on BPEL and petri nets (extended version). BPM Center Report BPM-05-25, BPMcenter.org, [3] A. Alves, A. Arkin, S. Askary, C. Barreto, B. Bloch, F. Curbera, M. Ford, Y. Goland, A. Guízar, N. Kartha, C. K. Liu, R. Khalaf, D. Koenig, M. Marin, V. Mehta, S. Thatte, D. Rijn, P. Yendluri, and A. Yiu. Web services business process execution language version 2.0 (OASIS standard). WS-BPEL TC OASIS, [4] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana. Business Process Execution Language for Web Services Version 1.1. IBM, BEA Systems, Microsoft, SAP AG, Siebel Systems, [5] A. Balogh and D. Varró. Advanced Model Transformation Language Constructs in the VI- ATRA2 Framework. In ACM Symposium on Applied Computing Model Transformation Track (SAC 2006), pp ACM Press, Dijon, France, [6] L. Baresi and S. Guinea. Towards dynamic monitoring of WS-BPEL processes. In B. Benatallah, F. Casati, and P. Traverso (eds.), ICSOC, vol of Lecture Notes in Computer Science, pp Springer, URL [7] Business Process with BPEL4WS: Understanding BPEL4WS, Part 1, ibm.com/developerworks/webservices/library/ws-bpelcol1/. [8] BPEL Project, [9] E. Christensen, F. Curbera, and G. M. S. Weerawarana. Web Services Description Language (WSDL) 1.1. The World Wide Web Consortium, [10] K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches. IBM Systems Journal, vol. 45(3):pp , URL journal/sj/453/czarnecki.html. [11] H. Foster. A Rigorous Approach To Engineering Web Service Composition. Ph.D. thesis, Inperial College London, [12] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, and H. Frystyk Nielsen. SOAP version 1.2 part 1: Messaging framework. World Wide Web Consortium, Recommendation RECsoap12-part , [13] H. Haas and A. Brown. Web services glossary. W3C note, W3C,

94 94 IRODALOMJEGYZÉK [14] S. Hinz, K. Schmidt, and C. Stahl. Transforming BPEL to Petri Nets. In W. M. P. v. d. Aalst, B. Benatallah, F. Casati, and F. Curbera (eds.), Proceedings of the Third International Conference on Business Process Management (BPM 2005), vol of Lecture Notes in Computer Science, pp Springer-Verlag, Nancy, France, URL \url{http: // [15] M. Hölzl. SENSORIA Deliverable D8.4.a: University management and e-learning case study: Requirements modelling and analysis of selected scenarios. Tech. rep., October [16] G. Holzmann. The SPIN Model Checker: Primer and Reference Manual. Addison-Wesley, Boston, Massachusetts, USA, [17] M. Kovács. Munkafolyamatok szimulációja és formális analízise. TDK dolgozat, Budapest, [18] M. Kovács, D. Varró, and L. Gönczy. Formal Modeling of BPEL Workflows Including Fault and Compensation Handling. In Proc. of Engineering Fault Tolerant Systems (EFTS2007). Dubrovnik, Croatia, [19] M. Kovács, D. Varró, and L. Gönczy. Formal Analysis of BPEL Workflows with Compensation by Model Checking. International Journal of Computer Systems Science and Engineering, To Appear. [20] N. Lohmann. A feature-complete Petri net semantics for WS-BPEL 2.0 and its compiler BPEL2oWFN. Informatik-Berichte 212, Humboldt-Universität zu Berlin, [21] N. Lohmann, P. Massuthe, C. Stahl, and D. Weinberg. Analyzing Interacting BPEL Processes. In Business Process Management, 4th International Conference, BPM 2006, Vienna, Austria, September 5-7, 2006, Proceedings, vol of Lecture Notes in Computer Science, pp Springer-Verlag, URL [22] K. L. McMillan. The SMV system, symbolic model checking - an approach. Tech. Rep. CMU-CS , Carnegie Mellon University, [23] N. Mitra. SOAP version 1.2 part 0: Primer. World Wide Web Consortium, Recommendation REC-soap12-part , [24] S. Nakajima. Model-checking behavioral specification of BPEL applications. Electr. Notes Theor. Comput. Sci, vol. 151(2):pp , URL entcs [25] S. Nakajima. Model-Checking Behavioral Specification of BPEL Applications. Electr. Notes Theor. Comput. Sci., vol. 151(2):pp , [26] Object Management Group. UML Profile for Schedulability, Performance and Time. http: // [27] C. Ouyang, E. Verbeek, W. M. P. van der Aalst, S. Breutel, M. Dumas, and A. H. M. ter Hofstede. WofBPEL: A Tool for Automated Analysis of BPEL Processes. In ICSOC, pp [28] A. Pataricza, T. Bartha, G. Csertán, S. Gyapay, I. Majzik, and D. Varró. Formális módszerek az informatikában. Typotex, In Hungarian. [29] A. Schroeder and P. Mayer. Verifying interaction protocol compliance of service orchestrations. In Proceedings of the 6th International Conference on Service Oriented Computing (ICSOC) To Appear.

95 IRODALOMJEGYZÉK 95 [30] SENSORIA (Software Engineering in Service-Oriented Overlay Computers) EU FP6 Project, [31] N. Shankar. Symbolic Analysis of Transition Systems. In Y. Gurevich, P. W. Kutter, M. Odersky, and L. Thiele (eds.), Abstract State Machines: Theory and Applications (ASM 2000), no in Lecture Notes in Computer Science, pp Springer-Verlag, Monte Verità, Switzerland, [32] C. Stahl. A Petri Net Semantics for BPEL. Informatik-Berichte 188, Humboldt-Universität zu Berlin, [33] H. M. W. Verbeek and W. Aalst. Analyzing BPEL processes using petri nets. In D. Marinescu (ed.), Proceedings of the Second International Workshop on Applications of Petri Nets to Coordination, Workflow and Business Process Management, pp Florida International University, Miami, Florida, USA, [34] Y. Yang, Q. Tan, Y. Xiao, J. Yu, and F. Liu. Verifying web services composition: A transformation-based approach. In PDCAT, pp IEEE Computer Society, URL

96 96 IRODALOMJEGYZÉK

97 10. fejezet Függelék BPEL2.0 statikus analízis kivonata A szabvány által definiált statikus analízisben leírt szabályok egy részét gyüjtöttük össze a táblázatban Webszolgáltatások protokollkészlete A kommunikációs rendszerekben a strukturálatlan bitfolyam továbbításáért a fizikai réteg felel, ez a legalsó réteg. A szállítási réteg, amely az üzenetek hálózatok közötti szállításáért felelős a fizikai réteg által nyújtott szolgáltatásokat használja. A szállítási protokollok például a Hypertext Transfer Protocol (HTTP), a Simple Mail Transfer Protocol (SMTP), vagy a File Transfer Protocol (FTP). A szállítási réteg felett az üzenetküldési réteg található, feladata az adatok szabványos Extensible Markup Language (XML) alapú kódolása, ez azért szükséges, hogy a hálózati kapcsolat két végpontján lévő rendszerek megértsék egymást. Erre használható protokollok többek között az XML-Remote Procedure Call (XML-RPC), a WS-Addressing vagy a SOAP. A szolgáltatások definiálásához szükség van az általuk használt üzenetek formátumának megadására és az adott szolgáltatás meghívható műveleteinek felsorolására. Az ezekhez tartozó definíciók leírására jött létre a Web Services Description Language (WSDL) szolgáltatás leíró protokoll. Ahhoz, hogy a kínált és a keresett szolgáltatások összeköthetők legyenek, szükség van egy telefonkönyvszerű nyilvántartásra, amelybe regisztrálni lehet a szolgáltatásokat és keresni lehet a létező szolgáltatások között, lehetőleg jól definiált módon. A szolgáltatás nyilvántartó rendszer által használt Universal Description, Discovery and Integration (UDDI) platform független, XML alapú protokoll segítségével megadható a tárolt szolgáltatások helye és specifikációja Extensible Markup Language (XML) A használt szabályrendszerek jelentős részének alapja az XML szabvány. Ez egy olyan általános célú leíró nyelvet definiál, amely jól használható speciális célú leíró nyelvek létrehozására. Az XML alapú nyelvek közös tulajdonsága, hogy nyelvtanuk formális módon van leírva, ezáltal lehetőség van olyan programok írására, amelyek a konkrét nyelvtan előzetes ismerete nélkül képesek a dokumentumokat módosítani és ellenőrizni. Az XML dokumentumokban az elemek fa struktúrában helyezkednek el, amely struktúra kiegészülhet az elemek közötti hivatkozásokkal. Az elemek neve egyben a típusokat is meghatározza, ez 97

98 98 FEJEZET 10. FÜGGELÉK Kód SA00001 SA00006 SA00015 SA00016 SA00018 SA00023 SA00025 SA00056 SA00062 SA00064 SA00066 SA00067 SA00070 SA táblázat. BPEL 2.0 Statikus analízis néhány szabálya Szabály Nem futtatható olyan folyamat, amely kérelem-válasz vagy értesítés típusú szolgáltatást valósítana meg. A <rethrow> tevékenységnek egy hibakezelőn belül kell elhelyezkednie, míg a <compensate> és <compensatescope> tevékenységeknek hiba-, kompenzáció, vagy megszakítás-kezelőn belül kell elhelyezkedniük. A folyamatnak legalább egy olyan <receive> vagy <pick> tevékenységet tartalmaznia kell, amelynek createinstance attribútuma igazra van állítva, ezt az elemet kezdő-tevékenységnek nevezzük. Egy <partnerlink> elemnek a myrole és a partnerrole attribútumok közül legalább az egyiket specifikálnia kell. A <partnerlink> nevének egyedinek kell lennie a saját műveleti hatókörén belül. A változók nevének egyedinek kell lennie a saját műveleti hatókörén belül. A változók típusa messagetype, type, vagy element közül csak az egyik lehet. A kezdő-tevékenységet nem előzheti meg, más tevékenység végrehajtása, kivéve <sequence>, <scope> vagy <flow>, a vele párhuzamos végrehajtás is tiltott. Ha a kezdő-tevékenység <pick>, akkor csak <onmessage> elemeket tartalmazhat. Egy <flow> által definiált <link> elemek nevei egyediek, valamint felhasználáskor az összeköttetések kezdő és végpontjában csak létező neveket lehet felhasználni. Egy adott <link> csak egy kezdő és végponttal rendelkezhet. Két különböző <link> nem rendelkezhet azonos kezdő és végponttal. A <link> nem lépheti át ismételhető tevékenység vagy kompenzációkezelő határát. A linkek hiba- és megszakítás-kezelőkből csak kifelé mutathatnak és a végpontjuk a kezelőhöz tartozó <scope> határán kívül kell lennie.

99 10.2. WEBSZOLGÁLTATÁSOK PROTOKOLLKÉSZLETE 99 növeli az olvashatóságot, miközben megtartja a gépi feldolgozáshoz szükséges szigort. Az elemeknek lehetnek attribútumaik és tartalmuk, egy konkrét nyelv esetén ezek típusát és számát a nyelvet definiáló séma adja meg. Az attribútumok értéke idézőjelek között adható meg az attribútum neve és egy egyenlőségjel után. Az elem tartalma szöveges tartalom és további elemek lehetnek. Egy XML dokumentum jól-formált, ha megfelel minden szintaktikai szabálynak. Olyan dokumentum esetén, amely nem jól-formált, a feldolgozást az elemző megtagadhatja. A dokumentum érvényes, ha tartalma megfelel a hozzá tartozó nyelv szabályainak. Ha az XML dokumentum jólformált és érvényes, akkor helyes. A példában egy könyv adatait tartalmazó helyes XML dokumentum olvasható (a séma definiálásától eltekintünk): <? xml version = 1.1?> <book > <title > XML Examples </ title > <author > Web School </ author > <info genre = drama date = /> </book > Részlet Példa XML dokumentumra SOAP A webszolgáltatások közötti kommunikációban használt üzenetek a SOAP XML alapú szabvány által definiált struktúrával rendelkeznek. A SOAP használata megkönnyíti a kommunikációt a HTTP szállítási protokoll felett, de definíciójának sokoldalúsága megengedi más szállítási protokollok használatát is. Előnyei az egyszerűség, a kiterjeszthetőség, és a platformfüggetlenség. Hátránya, hogy az XML alapok miatt bőbeszédű és redundáns, emiatt lassabb, mint más köztes réteg protokollok, továbbá HTTP felett használva megköti az együttműködő felek szerepeit, továbbá éppen a HTTP csomagok használata miatt a tűzfalaknak részletesebb csomagvizsgálatot kell végrehajtaniuk, ami teljesítménycsökkenést okozhat. A SOAP üzenetek felépítése egy hagyományos levél struktúráját követi, a fejléc tartalmazza a címzést és a válaszcímet, a törzs az üzenet tartalmát.[23] Fontos megemlíteni, hogy a webszolgáltatások közötti kommunikációban hibajelző üzenetek is megjelenhetnek, ezeknek az üzeneteknek a felépítését is a SOAP szabályozza. Az ilyen üzenetek a hiba jelzésén túl részletes információt tartalmazhatnak a hiba részleteiről. Egy hibaüzenet felépítését mutatja be a példa: <? xml version = 1.0?> <env : Envelope xmlns : env = http :// /2003/05/ soap - envelope xmlns : xml = http :// / XML /1998/ namespace > <env : Header > <env : NotUnderstood qname = abc : Extension1 xmlns : abc = http :// example. org /2001/06/ ext /> <env : NotUnderstood qname = def : Extension2 xmlns : def = http :// example. com / stuff /> </ env : Header > <env :Body > <env : Fault > <env :Code >< env : Value > env : MustUnderstand </ env : Value > </ env :Code > <env : Reason > <env : Text xml : lang = en > One or more mandatory SOAP header blocks not understood </ env :Text > </ env : Reason > </ env : Fault > </ env :Body >

100 100 FEJEZET 10. FÜGGELÉK </ env : Envelope > Részlet Példa SOAP dokumentumra[12] Látható, hogy az üzenet XML alapú, gyökéreleme az boríték (Envelope) elem, amely jelzi, hogy a dokumentum egy SOAP üzenet. A gyökér elem két gyermekeleme az üzenet fejlécét (Header) és törzsét (Body) tartalmazza, a fejlécben megjelennek a hibajelzések, a törzsben pedig a hiba (Fault) elemen belül a hiba részletei szerepelnek. Minden hiba elemnek van hibakód (Code) és hibaok (Reason) eleme, ezen kívül lehet csomópont (Node), szerep (Role) és részlet (Detail) eleme Transzformációk végrehajtása A bemutatott módszer használatát demonstráljuk illusztrációk segítségével ebben a fejezetben. Először bemutatjuk hogyan lehet előkészíteni azt a VIATRA modellteret, amelybe a munkafolyamat modelleket létrehozhatjuk. Ezután a transzformáció végrehajtásának módját ismertetjük, amelynek eredményéből kódgenerálás segítségével előállítjuk a SAL rendszer leírást. Végül bemutatunk néhány modellellenőrzési lépést és azok eredményét. A fejezetben bemutatott esettanulmány folyamatait a BPEL Project [8] Eclipse kiegészítő segítségével hoztuk létre. A bemutatott módszer használatához telepíteni kell a VIATRA keretrendszert az Eclipse fejlesztőkörnyezetbe. A telepítés után hozzunk létre egy új project-t, majd ebbe a project-be hozzunk létre egy új, üres VIATRA modellteret. A project mappán jobb egérgombbal kattintva a lokális menüből válasszuk ki a New... almenüből az Other... menüpontot. A felugró ablakban válasszuk ki a VIATRA2 Framework mappából a VIATRA2 VPM Model Space varázslót (lásd ábra), majd nyomjuk meg a Next gombot. A következő ablakban adjuk meg az új modelltér állomány nevét (example.vpml), majd Next gomb megnyomása után válasszuk ki a VPM Core opciót és nyomjuk meg a Finish gombot. Ezzel létrejött az üres modelltér, amely rögtön megnyílik a szerkesztő ablakban ábra. Demonstráció: Modelltér létrehozás

101 10.3. TRANSZFORMÁCIÓK VÉGREHAJTÁSA 101 Az üres modelltérben ezután létre kell hozni a transzformációk használatához szükséges metamodelleket és be kell tölteni a transzformációkat tartalmazó modulokat. A metamodellek létrehozásához az őket tartalmazó állományokat megfelelő sorrendben a VIATRA2 Model Spaces nézetben a modellterünket reprezentáló modelspace elemre kell húzni. A sorrend a következő: emf, xml, wsdl, bpel2, sal, bpel2refmodel, salbpel2extension. Következő lépésként betöltjük a transzformációkat tartalmazó modulokat. Ehhez az előzőleg említett modelltér reprezentáción jobb egérgombbal klikkelve a megjelenő menüben a Program Loaders almenüből válasszuk a EMF XMI Loader for VIATRA2 Module Instances menüpontot. A megjelenő ablakban válasszuk ki a transzformáció modul állományokat (egyszerre egyet), majd Open gombbal töltsük be. A ábrán látható a kiválasztandó menüpont ábra. Demonstráció: Transzformációk betöltése Ha betöltöttük a transzformációkat, következhet a modellek létrehozása a forrás állományokból. A ábrán látható opciót (Native Importers/BPEL2.0 Importer vagy WSDL Importer) majd válasszuk ki a kívánt állományt ábra. Demonstráció: Modell elkészítése Miután a modellek létrejöttek, a modelltérben megtekinthető a tartalmuk. A BPEL2.0 munkafolyamatok modelljei a bpel2/models elem alatt helyezkednek el a fa struktúrában, a WSDL specifikációk modelljei pedig a wsdl/models elem alatt. Ez látható a ábrán.

102 102 FEJEZET 10. FÜGGELÉK ábra. Demonstráció: Modelltér Az előző lépések elvégzése után már futtathatjuk a transzformációkat. Először a bpel2tosal transzformációt futtassuk. A futtatáshoz jobb egérgombbal klikkeljünk a modelltér reprezentáció Program models/ bpel2.programs.bpel2tosal elemére és válasszuk a Run... opciót. Ekkor a ábrán látható ablak jelenik meg, amelyben megadhatók a futtatási paraméterek. Először válasszuk ki a modelltérből a transzformálni kívánt modellt és nyomjuk meg a Select Model Element gombot. Ezután írjuk be a létrehozandó tranzíciós rendszer modell nevét végül adjuk meg, hogy kérünk-e kompenzációkezelést (yes/no). A transzformáció az OK gomb megnyomásával lefut. A transzformáció eredményeként létrejön egy modell a sal/models elem alatt a megadott névvel ábra. Demonstráció: Transzformáció futtatása Az utolsó lépésként a létrehozott tranzíciós rendszer modellből generáljunk SAL rendszer le-

103 10.4. AZ ESETTANULMÁNY FOLYAMATAI 103 írást. Ehhez futtassuk a sal2code transzformációt. Az előbbihez hasonló módon most a Program models/sal.programs.sal2code elemet válasszuk. A megjelenő ablakban válasszuk ki a megfelelő modellt, majd Select Model Element gomb, végül az Ok gomb (lásd ábra). A transzformáció hatására létrejön egy.sal kiterjesztésű állomány, amely már a SAL keretrendszer által használt leírási módban tartalmazza tranzíciós rendszert ábra. Demonstráció: Kódgenerálás Az esettanulmány folyamatai

104 104 FEJEZET 10. FÜGGELÉK ábra. BPEL Mintafolyamat: Főfolyamat ábra. BPEL Mintafolyamat: Helyi oktatási folyamat

105 10.4. AZ ESETTANULMÁNY FOLYAMATAI ábra. BPEL Mintafolyamat: Helyi oktatási folyamat elágazásának tartalma ábra. BPEL Mintafolyamat: Helyi adminisztrációs folyamat

106 106 FEJEZET 10. FÜGGELÉK ábra. BPEL Mintafolyamat: Távoli oktatási folyamat ábra. BPEL Mintafolyamat: Távoli adminisztrációs folyamat