A MAGYAR SOA ALAPÚ ARCHITEKTÚRA RENDSZERTERVE

Átírás

1 A MAGYAR SOA ALAPÚ ARCHITEKTÚRA RENDSZERTERVE BME Informatikai Központ 1

2 A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az Elektronikus közigazgatási keretrendszer tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett: BME Informatikai Központ 2

3 Metaadat-táblázat Megnevezés Leírás Cím (dc:title) A magyar SOA alapú architektúra rendszerterve Kulcsszó (dc:subject) e-közigazgatás, szolgáltatásorientált architektúra, szolgáltatási sín, e- közigazgatás informatikai rendszere Leírás (dc:description) A magyar e-közigazgatás továbbfejlesztésének fı iránya az ügyfélközpontú közigazgatási szolgáltatások minél szélesebb körének megvalósítása. Ennek egyik legfontosabb feltétele a szakrendszerek együttmőködésének egységes elvek szerint történı kialakítása. A dokumentum felvázolja és indokolja a szakrendszerek együttmőködésére javasolt, az akár jelentıs bıvítések és változások rugalmas követésére is alkalmas szolgáltatásorientált architektúrát. Az architektúra a webszolgáltatási szabványokra építkezı szolgáltatási sín kialakítását javasolja, megadja a sín mőködtetéséhez szükséges alapszolgáltatásokat, és az összetett, több szakrendszert is érintı szolgáltatások megvalósításának lehetıségeit. Meghatározza a sín kialakításának azokat a rétegeit, amelyek heterogén SOA-rendszerek együttmőködésének megvalósítását is lehetıvé teszik. Típus (dc:type) Forrás (dc:source) Kapcsolat (dc:relation) Terület (dc:coverage) Magyarország Létrehozó (dc:creator) e-közigazgatási Keretrendszer Kialakítása projekt Kiadó (dc:publisher) Miniszterelnöki Hivatal Résztvevı (dc:contributor) BME Informatikai Központ Jogok (dc:rights) Dátum (dc:date) Formátum (dc:format) Azonosító (dc:identifier) Nyelv (dc:language) magyar Verzió (dc:version) V2 Státusz (State) Végleges Fájlnév (FileName) EKK_ekozig_SOA_architektura_rendszerterv_080727_V2 Méret (Size) Ár (Price) Felhasználási jogok (UserRights) BME Informatikai Központ 3

4 Verziókövetési táblázat A dokumentum neve A magyar SOA alapú architektúra rendszerterve A dokumentum készítıjének neve BME Informatikai Központ A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám V2 Összes oldalszám 97 A projekt azonosítója e-közigazgatási Keretrendszer Kialakítása projekt Változáskezelés Verzió Dátum A változás leírása V Tartalomjegyzék V MeH-nek átadott végleges verzió V3 BME Informatikai Központ 4

5 Szövegsablon Megnevezés Leírás 1. Elıszó (Foreword) Az Elektronikus Közigazgatási Keretrendszer Kialakítása (EK3) projekt részként indult Alkalmazásfejlesztési keretrendszer kidolgozása alprojekt célja: a) a magyar SOA alapú architektúra rendszertervének kidolgozása, b) a magyar e-közigazgatási rendszer szolgáltatásorientált architektúrájának specifikálása, c) a közigazgatási szolgáltatási sín és mőködési rendjének specifikálása, d) fejlesztési útmutató és menetrend (roadmap) elkészítése, e) fejlesztési keretrendszer és komponenstár tartalmi meghatározása, f) a fenti témákban oktatási csomagok kidolgozása. Jelen dokumentum az alprojekt elsı terméke. 2. Bevezetés (Preamble) A dokumentum célja a szolgáltatásorientált architektúra rendszerterv szintő definiálása 3. Alkalmazási terület (Scope) Elektronikus közigazgatás 4. Rendelkezı hivatkozások (References) 5. Fogalom-meghatározások van (Definitions) 6. A szabvány egyedi tartalma (UniqueContent) 7. Bibliográfia van 8. Rövidítésgyőjtemény 9. Fogalomtár van 10. Ábrák van 11. Képek 12. Fogalmak van 13. Verzió 14. Mellékletek (Appendix) BME Informatikai Központ 5

6 Tartalomjegyzék 1. Vezetıi összefoglaló Bevezetés A téma elhelyezése A rendszerterv pozicionálása Az anyag felépítése Helyzetkép Az e-közigazgatás fejlettségi szintje Magyarországon Az e-közigazgatási rendszer jellemzıi Jogi háttér Elfogadott fejlesztési projektek Problémák Jövıkép Az architektúra kialakításának alapelvei Önálló szakrendszerek Meglévı rendszerek integrálása Laza csatolás igénye Sín topológiájú logikai kapcsolatok kialakítása Nyílt szabványok és specifikációk alkalmazása A folyamatos mőködés fenntartása fokozatos fejlesztés Helytıl és idıtıl független elérhetıség Összetett szolgáltatások végrehajtásának támogatása Az e-közigazgatási szolgáltatási sín Az e-közigazgatási sínnel szemben támasztott követelmények Az e-közigazgatási sín kialakítása Az architektúrához kapcsolódó fogalmak Szolgáltatás Cselekmény A szolgáltatás állapotfüggetlen A szolgáltatáskérés aszinkron Ügyek megvalósítása Szolgáltatási sín SOA SOA alapú architektúra Paraméterek egységesítése A központi rendszer A felügyeleti sín Fejlesztés Megoldási lehetıségek Nemzetközi tapasztalat Németország Dánia Egyesült Királyság Írország A szolgáltatás-orientált architektúra bemutatása Bevezetés A szolgáltatás-orientált architektúra fogalma A szolgáltatás-orientált architektúra megvalósításának generációi Web-szolgáltatás szabványok Business Process Execution Language (BPEL) Szolgáltatási láncok Orkesztráció vagy koreográfia? Architektúra kiválasztása, indoklása BME Informatikai Központ 6

7 Réteg modell A réteg modell formális nézete Infrastruktúra kialakítása (névtér, címkezelés, repository, felügyelet) Cluster-ek kialakításának lehetısége Dinamikus modell (mőködés) Nemfunkcionális követelmények Egy mintaeljárás mőködése az architektúrán A mintaeljárás rövid ismertetése A mintaeljárásban megjelenı szolgáltatások Az architektúrán megvalósított mintaeljárás bemutatása a szolgáltatási rétegig Az architektúrán megvalósított mintaeljárás bemutatása az átviteli csatorna rétegig A mintaeljárás megvalósítása a hazai adatvédelmi törvények figyelembevételével Fejlesztési eszközök és technológiák A vizsgált SOA eszközök Web-szolgáltatás API-k SOA eszközök Várható bıvítések kezelése Bevezetés Modell-vezérelt architektúra A MOF és a négy metaszint Aspektus-orientált programozás Kódgenerátor-támogatást igénylı komponensek az architektúrában A fejlesztés menete Modell az integrációra Fogalomtár Irodalomjegyzék BME Informatikai Központ 7

8 1. Vezetıi összefoglaló Az Alkalmazásfejlesztési keretrendszer kidolgozása alprojekt célja: a magyar SOA alapú architektúra rendszertervének kidolgozása a magyar e-közigazgatási rendszer szolgáltatásorientált architektúrájának specifikálása a közigazgatási szolgáltatási sín (ESB) és mőködési rendjének specifikálása fejlesztési útmutató és menetrend (roadmap) elkészítése fejlesztési keretrendszer és komponenstár tartalmi meghatározása a fenti témákban oktatási csomagok kidolgozása. A célok megvalósításáért felelıs partner a BME IK. A projektbe bekapcsolódik a Kopint- Datorg és számítunk további pilot-résztvevık (koordinációs tervezı csoport) tapasztalataira és együttmőködésére. Az alprojekt kapcsolódik a Folyamatleíró módszertan, az IT biztonsági követelmények a Szabványtár kidolgozása és a Pilot projektek alprojektekhez. Az elsı munkaszakaszban elkészült A magyar SOA alapú architektúra rendszerterve c. dokumentumnak az annotált tartalomjegyzéke, jelen (második) munkaszakaszban pedig maga a rendszerterv. A dokumentum tartalmazza a magyar e-közigazgatást támogató informatikai rendszer felépítésével és mőködésével kapcsolatos elgondolásokat és alapvetéseket. Célja a további munka fı irányának kijelölése, a következı munkaszakaszban elkészítendı architektúra és sín specifikáció, a keretrendszer, a fejlesztési útmutató és a kapcsolódó oktatási anyagok fogalmi és szakmai megalapozása. Az alprojekt a harmadik munkaszakaszban (2008. szept. 22.) fejezıdik be. A magyar e-közigazgatás továbbfejlesztésének fı iránya az ügyfélközpontú közigazgatási szolgáltatások minél szélesebb körének megvalósítása. Ennek egyik legfontosabb feltétele az önálló hivatali szakrendszerek együttmőködésének egységes elvek szerint történı kialakítása. A rendszerterv felvázolja és indokolja a szakrendszerek együttmőködésére javasolt, az akár jelentıs bıvítések és változások rugalmas követésére is alkalmas szolgáltatásorientált architektúrát. A dokumentum a web-szolgáltatási szabványokra építkezı szolgáltatási sín kialakítását javasolja, megadja a sín mőködtetéséhez szükséges alapszolgáltatásokat, és az összetett, több szakrendszert is érintı szolgáltatások megvalósításának lehetıségeit. Meghatározza a sín kialakításának azokat a rétegeit, amelyek heterogén SOA-rendszerek együttmőködésének megvalósítását is lehetıvé teszik. A rendszerterv felépítése: A helyzetkép c. fejezet rövid áttekintést ad a magyarországi e-közigazgatás fejlettségérıl, jelenlegi állapotáról, kitérve a vonatkozó jogszabályokra és a futó fejlesztési projektekre. A jövıkép bemutatja egy a kormányzati célkitőzések megvalósítására alkalmas - a jelenlegire épülı, abból inkrementálisan felépíthetı - informatikai rendszer kialakításának alapelveit. Definiálja a szolgáltatási sínnel és az architektúrával kapcsolatos fogalmakat, majd vizsgálja ezeknek a Központi Rendszerhez való viszonyát, végül utal a felügyeletre és a fejlesztés szempontjaira is. A megoldási lehetıségek c. fejezet eleje a nemzetközi tapasztalatokról szól. Ezt követi a szolgáltatások kialakításának támogatása céljából létrejött szolgáltatás orientált architektúra (SOA) és a kapcsolódó elemek (web-szolgáltatások, business process execution language) bemutatása. A fejezet a javasolt architektúra alkalmasságának indoklásával zárul. A BME Informatikai Központ 8

9 következı részben egy minta-eljáráson keresztül követhetjük végig az architektúrának megfelelı rendszer mőködését. A rajzokkal és táblázatokkal jól kiegészített leírás a tiszta funkcionalitáson túlmutatóan a biztonsági és hitelességi szempontokra is fókuszál. Az utolsó fejezet a fejlesztési folyamatot és eszközöket tekinti át, majd javaslatokat ad a szolgáltatási sínhez új szolgáltató komponens csatlakoztatása miatt felmerülı bıvítéssel kapcsolatos tipikusan elıforduló fejlesztési feladatok megoldására. BME Informatikai Központ 9

10 2. Bevezetés 2.1. A téma elhelyezése Az Európai Unió országaiban prioritásként kezelik az e-közigazgatás fejlesztését. Az i2010 egovernment cselekvési tervben [10] megcélozták az elektronikus kormányzat létrehozásának, továbbfejlesztésének felgyorsítását a társadalom egészének javára. Ezek az átfogó célok az E-közigazgatás 2010 stratégiában is megjelennek [4]. Magyaroszágon a 2010-ig terjedı idıszakban a kormányzat a következı célokat definiálta [3]: a) Az ügyfelek igényei szerint kialakított közszolgáltatások b) Az elektronikus ügyintézés jogbiztonságának megteremtése c) Az ügyintézési rendszerek megbízhatóságának növelése d) A szolgáltatások egyetemleges elérhetısége, a szolgáltatási háló (ÜGYNET) kialakítása az állam házhoz megy e) Az elektronikusan aktív állampolgár, ügyfél tevékenységének átfogó támogatása f) A non-stop közigazgatás (7/24) átállás megvalósítása g) A háttérfolyamatok érdemi elektronizálása, egységes elektronikus alapszolgáltatások h) A közigazgatáshoz értı informatikai és folyamatszervezı szakemberek koncentrálásával létre kell hozni a tervezıi, fejlesztıi, menedzsment kapacitások kínálatát, valamint az informatikai biztonsági, interoperabilitási, modellezési, és a közszolgáltatások újratervezését (reengineering) elısegítı specializált háttér tudásplatformokat. Magyarország az Új Magyarország Fejlesztési Tervben [6] egyik fontos prioritásként az államreformot jelölte meg, amelynek megvalósítására az Államreform Operatív Programot (ÁROP) [7] és az Elektronikus Közigazgatás Operatív Programot (EKOP) [8] indította el. Ezek a programok lehetıvé teszik, hogy az elektronikus közigazgatás fejlesztésének stratégiai céljait az Európai Únió támogatásával valósítsuk meg. Az EKOP projektek konvergenciájának elısegítésére az ÁROP projektek egyikeként indult az Elektronikus Közigazgatási Keretrendszer Kialakítása (EK3) projekt. Az EK3 projekt célja azoknak az elıírásoknak, szabványoknak és követelményeknek a meghatározása, amelyek biztosítják az elektronikus közigazgatás teljes fejlesztéséhez és üzemeltetéséhez az egységes technikai, szemantikai, IT biztonsági, alkalmazásfejlesztés módszertani, valamint projekt-menedzselési és monitoring platformot. Ennek a célkitőzésnek a megvalósulása és következetes érvényesítésének biztosítása megfelelı garanciát jelent ahhoz, hogy a más projektek keretében, önállóan megvalósuló szakágazati, illetve önkormányzati alrendszerek fejlesztése, továbbfejlesztése eredményeként interoperábilis, biztonságos és korszerő elektronikus közigazgatási rendszer jöjjön létre. Az EKOP projektek eredményeként az egyes szakrendszerek továbbfejlesztésén túl ki kell alakulnia a magyar közigazgatás integrált háttérrendszerének. Ennek szem elıtt tartásával az EK3-ban, azon belül az "Alkalmazásfejlesztési keretrendszer kialakítása" c. alprojektben - szoros együttmőködésben a folyamatleírással, a biztonsággal és az interoperabilitással kapcsolatos alprojektekkel - kidolgozásra kerül a szakrendszerek BME Informatikai Központ 10

11 együttmőködésének koncepciója. A koncepció az együttmőködés bázisaként szolgáltatásorientált architektúra és szolgáltatási sín kialakítását célozza meg. A mai technológiákat és trendeket tekintve ez a megoldás látszik a legígéretesebb fejlesztési keretnek, mert a) a fejlesztés az integrációban résztvevı szervezetek számára kevesebb munkát jelent, miközben a szakrendszerek önállósága megmarad (heterogén, lazán csatolt alrendszerek és szervezetek együttmőködése valósul meg) b) a fejlesztés fokozatosan, lépésenként valósítható meg a meglévı funkcionalitás folyamatos fenntartása mellett c) az EU követelményeire, elvárásaira figyelemmel van d) a változások követése, a rendszer bıvítése áttekinthetı, uralható feladat marad. Az Alkalmazásfejlesztési keretrendszer kidolgozása alprojekt célja: a) A magyar e-közigazgatási rendszer szolgáltatásorientált architektúrájának specifikálása b) A közigazgatási szolgáltatási sín (ESB) és mőködési rendjének specifikálása c) Fejlesztési útmutató és menetrend (roadmap) elkészítése d) Fejlesztési keretrendszer és komponenstár tartalmi meghatározása e) A fenti témákban oktatási csomagok kidolgozása Jelen dokumentum a nevezett alprojekt elsı terméke, célja a szolgáltatásorientált architektúra rendszerterv szintő definiálása A rendszerterv pozicionálása Az Alkalmazásfejlesztési keretrendszer kidolgozása alprojektben az alábbi dokumentumok készülnek el: a) A magyar SOA alapú architektúra rendszerterve (Rterv) - jelen dokumentum b) A magyar e-közigazgatási rendszer szolgáltatásorientált architektúrájának specifikációja (MKA) c) A közigazgatási szolgáltatási sín és mőködési rendjének specifikációja (MKSZS) d) Fejlesztési útmutató és menetrend (Roadmap) e) Fejlesztési keretrendszer és komponenstár szoftver (Keret) f) Oktatási anyagok (Okt) Az 1. ábra bemutatja a felsorolt dokumentumok egymásra épülését Az anyag felépítése A Helyzetkép c. fejezet rövid áttekintést ad a magyarországi e-közigazgatás fejlettségérıl, jelenlegi állapotáról, kitérve a vonatkozó jogszabályokra és a futó fejlesztési projektekre. A Jövıkép bemutatja egy a kormányzati célkitőzések megvalósítására alkalmas - a jelenlegire épülı, abból inkrementálisan felépíthetı - informatikai rendszer kialakításának alapelveit. Definiálja a szolgáltatási sínnel és az architektúrával kapcsolatos fogalmakat, majd vizsgálja ezeknek a Központi Rendszerhez való viszonyát, végül utal a felügyeletre és a fejlesztés szempontjaira is. A Megoldási lehetıségek c. fejezet eleje a nemzetközi tapasztalatokról BME Informatikai Központ 11

12 szól. Ezt követi a szolgáltatások kialakításának támogatása céljából létrejött szolgáltatásorientált architektúra (SOA) és a kapcsolódó elemek (web-szolgáltatások, Business Process Execution Language) bemutatása. A fejezet a javasolt architektúra alkalmasságának indoklásával zárul. 2. fázis 3. fázis 4. fázis MKA v0 MKA v1 Rterv Keret MKSZS v0 MKSZS v1 Road map Okt 1. ábra A dokumentumok kapcsolata A következı részben egy minta-eljáráson keresztül követhetjük végig az architektúrának megfelelı rendszer mőködését. A rajzokkal és táblázatokkal kiegészített leírás a tiszta funkcionalitáson túlmutatóan a biztonsági és hitelességi szempontokra is fókuszál. Az utolsó fejezet a fejlesztési folyamatot és eszközöket tekinti át, majd javaslatokat ad a szolgáltatási sínhez új szolgáltató komponens csatlakoztatása miatt felmerülı bıvítéssel kapcsolatos tipikusan elıforduló fejlesztési feladatok megoldására. 3. Helyzetkép 3.1. Az e-közigazgatás fejlettségi szintje Magyarországon A közigazgatás informatikai támogatottságának több szempontú, összesített értékelése alapján az ENSZ E-Government Survey 2008 [1] jelentése Magyarországot a 30. helyre teszi a világban (e-government Readiness Index). (2005-ben a 27. helyre rangsoroltak.) A részletesebb adatok elemzésébıl megállapítható, hogy a web-es jelenlét és a humán-tıke tekintetében ennél jobban állunk, míg az infrastruktúra (fıként a számítógépes ellátottság) és az állampolgárokkal tartott interaktív kapcsolat (e-participation) tekintetében kevésbé jól ban az OECD készített felmérı tanulmányt [2], amelyben a következı területeken tartja szükségesnek a magyar e-közigazgatás fejlesztését: a felhasználó-orientált fejlesztést a kormányzati ügyintézési folyamatok átszervezését az erıforrások felszabadítása érdekében BME Informatikai Központ 12

13 az elektronikus szolgáltatásokra való építkezést az ügyfelek kiszolgálásában a kormányzati intézmények közti együttmőködés, interoperabilitás megteremtése Az e-közigazgatási rendszer jellemzıi A magyar e-közigazgatási rendszer legfontosabb alrendszere a központi elektronikus szolgáltató rendszer (KR). Emellett összességében jelentıs az önkormányzatok, és egyes szervezetek önálló szolgáltatásainak súlya is. Az E-közigazgatás 2010 stratégia [4] összefoglalja a legfontosabb jellemzıket: Az elmúlt évek hazai e-kormányzati, e-közigazgatási fejlesztései fıként az alapinfrastruktúra megteremtéséhez kötıdtek, ezen belül is a KR kiépítéséhez. A KR részeként kiépült az Elektronikus Kormányzati Gerinchálózat (EKG), a kormányzati portál, az ügyfélkapu és a Kormányzati Ügyfél-tájékoztató Központ (KÜK). A KR gerincét jelentı EKG-hoz februárra 1598 intézményi telephely kapcsolódott közel 70 ezer felhasználóval. Az EKG megteremti az interneten keresztül nyújtott kormányzati szolgáltatások elérésének hálózati hátterét. Emellett biztosítja a TESTA (az Európai Közösség saját zártkörő, IP alapú hálózata) és H-Sec-Net (minısített nemzetközi információk fogadására alkalmas hálózat) kapcsolatot. A kormányzati portál és az ügyfélkapu biztosítja az egységes kormányzati online információ- és tranzakciós szolgáltatások elérését, és a KÜK telefonon, sms-en, -en és faxon keresztül is elérhetıvé teszi az ügyleírásokat, az ügyintézéshez szükséges ismereteket. Jelenleg a KR az államigazgatás (kivéve önkormányzatok) interneten bonyolított forgalmának a 95%-át bonyolítja, valamint az internet alapú állampolgári és vállalkozási információközvetítés 60%-át, és az interaktív szolgáltatások 80%-át teszi elérhetıvé. Az ügyfélkapun keresztül jelenleg 372 szolgáltatás érhetı el, ebbıl a leggyakoribb EU 20 szolgáltatás az összes államigazgatási ügyforgalom 80%-át teszi ki május 1. óta az ügyfélkapu alkalmazásával mintegy 39 millió azonosítási szolgáltatást vettek igénybe, több mint 28 millió dokumentumot továbbítottak, a kormányzati portálról 352 millió oldalnyi információt töltöttek le. Az ügyfélkapun regisztráltak száma több mint 640 ezer. A virtuális okmányirodában közel 80 féle közigazgatási ügy kezdeményezhetı, köztük a legsikeresebb az okmányirodai idıpontfoglalás, melyet 2007-ben közel alkalommal vettek igénybe. A kormányzati portálon elérhetı a hatályos jogszabályok győjteménye és mintegy 800 közigazgatási ügy leírása. Az elektronikusan letölthetı, illetve kinyomtatható nyomtatványok száma meghaladja a 2000-et. 33 hazai kormányzati, 26 EU-s szervezet és 8 közszolgáltató vállalat nyújt elektronikusan elérhetı szolgáltatásokat. Az ügyfélkapu szolgáltatásai: Az ügyfél biztonságos, egyszeri azonosítása, majd összekötése az elektronikus szolgáltatást nyújtó intézmény alkalmazásaival. Az ügyfelek a rendszert magát, valamint az egyes elektronikus intézményi szolgáltatásokat böngészın keresztül érik el (kiegészítve esetleges letöltıdı alkalmazásokkal). A piacon lévı szabványos elektronikus aláíró alkalmazások fogadása. BME Informatikai Központ 13

14 A rendszer felkészült a jövıbeni alternatív aláíró eszközök (pl. mobiltelefon) használatára, szabványos kapcsolódási felületek kialakításával. Az ügyfélkapu biztonsági alapelve: a kockázattal arányos, szükséges és elégséges mértékő biztonság garantálása. Az ügyfélkapu a szakrendszerek felé az alábbi szolgáltatásokat nyújtja [9]: Egységes be- és kijelentkeztetı ügyfél-azonosítási eljárás, tranzakciós kód ellenırzése, viszontazonosítás. A szakrendszer az ügyintézés elıtt az ügyfélkapura irányítja az ügyfelet, ahol megtörténik a beléptetése, azonosítása. A sikeres bejelentkezést követıen az Ügyfélkapu visszairányítja az ügyfelet a szakrendszerhez, paraméterként egy tranzakciós kódot adva. A szakrendszer az ügyfélkapunál a tranzakciós kóddal kéri az ügyfél nevét és címét. Ha a szakrendszer saját azonosítóval is rendelkezik (pl. TAJ), akkor azt elkérve az ügyféltıl, kérheti a saját nyilvántartásában szereplı természetes azonosítók hitelességének ellenırzését az ügyfélkaputól a viszontazonosítás keretében. Saját portállal nem rendelkezı szakrendszereknek a Kormányzati Portálon történı megjelenést támogató interfész. A Kormányzati Portálhoz a szakrendszer a Központi Rendszer Integrátorán (KRI) keresztül csatlakozik. A szakrendszer feladata az ügyintézéshez szükséges folyamatok vezérlése, az adattartalom szolgáltatása (a megjelenítést vezérlı információkkal együtt). A Kormányzati Portál elérhetıvé teszi a csatlakozó intézmény szolgáltatásait, megoldja a bejelentkeztetést, továbbá egységes megjelenítést biztosít. A felek közötti kommunikáció SOAP kérdés/válasz tranzakciókon keresztül valósítható meg. Az e-közigazgatási szolgáltatások fejlettségi szintjét az EU-ban elfogadott értékelési rendszer négy, újabban öt fokozatú skálán méri [12]. Ennek lényege a tájékoztatás, egyirányú on-line, kétirányú on-line, tranzakciós kapcsolati szintek megkülönböztetése, illetve a felhasználócentrikus kiszolgálás. Ezzel összhangban van az ENSZ 2008-as jelentésében alkalmazott értékelés [1]. Fejlıdı (emerging) az e-közigazgatási szolgáltatás, ha csupán statikus, kapcsolatokat alig kínáló információkat közöl a felhasználókkal. Fejlett (enhanced), ha az információközlés bıvebb, dinamikusabb, kapcsolatokat, navigációs lehetıségeket, aktuális jelentéseket, jogszabályi tájékoztatást kínál. Interaktív (interactive), ha az ügyintézésekhez szükséges őrlapok letöltésére, ügyindításra is lehetıséget ad. Tranzakcionális (transactional), ha kétirányú, on-line, folyamatosan rendelkezésre álló (7/24) kapcsolat vehetı igénybe, beleértve az on-line fizetési lehetıségeket. Egységes (connected) a szolgáltatás, ha integrált back-office infrastruktúrára támaszkodva a felhasználó igényeihez alkalmazkodó kiszolgálást nyújt. Az E-közigazgatás 2010 stratégia [4] értékelésébıl kiolvasható, hogy az átlagos szintnek megfelelı helyünk a rangsorokban elsısorban az ügyfélkapu és a kormányzati portál által kínált szolgáltatás-elérhetıség eredménye, az egységes szint felé való továbblépés az integrált back-office kialakítását, a technikai, szervezési és jogi kérdések együttes kezelését igényli. Sajátos, és külön említendı kérdés az önkormányzati rendszerek kérdése, a helyzetkép ezen a területen nagy változatosságot, színvonalukban is széles skálán elhelyezkedı, zömében önálló szigetrendszereket és egyedi megoldásokat mutat. Az a tény, hogy az önkormányzatok kötelezı feladatai egységesen rögzítettek, lényeges egyszerősítésekre, hatékony fejlesztésre ad lehetıséget. BME Informatikai Központ 14

15 3.3. Jogi háttér Az Európai Bizottsága i2010 egovernment cselekvési terv-e [10] szerint A tagállamok elkötelezték magukat amellett, hogy az elektronikus kormányzatra vonatkozó, a társadalmi integrációt szem elıtt tartó célkitőzések megvalósításával annak biztosítására törekedjenek, hogy 2010-re minden polgár beleértve a társadalmilag hátrányos helyzető csoportokat is az elektronikus kormányzat fontos haszonélvezıje lehessen Az elektronikus ügyintézés jogi keretei Magyarországon lényegében adottak, mert novemberében hatályba lépett, a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló évi CXL. törvény (Ket.). a Ket. az online ügyintézést egyenrangúvá tette a hagyományos ügyintézéssel, elkészültek a végrehajtási rendeletek a Ket. a Központi Elektronikus Szolgáltató Rendszert határozza meg az e-ügyintézés központi alapinfrastruktúrájaként az e-aláírás szabályozása kiegészült a közigazgatásban való használat szabályaival az e-fizetés bevezetése érdekében több jogszabály-módosítás megtörtént (pl. illeték) az elektronikus információ szabadságáról szóló törvény garantálja az ügyfelek tájékoztatását Mindemellett a jogi környezet nem ellentmondásmentes (például az adatvédelmi jogszabályok és a Ket. rendelkezéseinek gyakorlati alkalmazása tekintetében), és indokolt az elektronikus közszolgáltatásokról szóló törvény megalkotása [3]. A jelen alprojekt keretében kimunkálandó architektúrát érintı legfontosabb jogszabályok a következık: évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól (Ket) 182/2007. (VII.10.) Korm. rendelet a központi elektronikus szolgáltató rendszerrıl 195/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézést lehetıvé tevı informatikai rendszerek biztonságáról, együttmőködési képességérıl és egységes használatáról 194/2005. (IX. 22.) Korm. rendelet a közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítés-szolgáltatókra vonatkozó követelményekrıl 193/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézés részletes szabályairól 9/2005. (VII. 21.) IHM rendelet az elektronikus aláírási termékek tanúsítását végzı szervezetekrıl, illetve a kijelölésükre vonatkozó szabályokról 7/2005. (VII. 18.) IHM rendelet a digitális archiválás szabályairól, valamint az információs társadalommal összefüggı szolgáltatásokkal kapcsolatos elektronikus archiválás szabályairól évi XXXV. törvény Az elektronikus aláírásról 2/2002. (IV. 26) MeHVM irányelve a minısített elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó biztonsági követelményekrıl. 3/2005. (III. 18.) IHM rendelet az elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó részletes követelményekrıl BME Informatikai Központ 15

16 3.4. Elfogadott fejlesztési projektek Az EKOP átfogó célja a közigazgatás teljesítményének a javítása. Az operatív program magában foglalja a közigazgatás és igazságszolgáltatás mőködésének, eljárásainak, folyamatainak, szolgáltatásainak az infokommunikációs technológiát kihasználó modernizációját, továbbá az összes infokommunikációs eszközön keresztül nyújtható közszolgáltatás közös elemeként az ügyfelek azonosítását biztosító beavatkozásokat. Az átfogó célt az alábbi két specifikus cél megvalósítása szolgálja: javuljon a közigazgatási szolgáltatások eredményessége, továbbá növekedjen a mőködési hatékonyság. A célok teljesülését az alábbi indikátor méri: a lakosság és a vállalkozások közigazgatás tevékenységével kapcsolatos országos szintő elégedettségének változása a program hatására, illetve az állami szerepvállalás minısége és hatékonysága hatással van mind az üzleti környezetre, a vállalatok versenyképességére, mind pedig a lakosság életminıségére, így az állami funkciók ellátásának az átalakítása segíti a lisszaboni célkitőzések megvalósítását. Az EKOP-ban az alábbi projektek kaptak, kapnak támogatást: Projektgazda IRM KEKKH PMISZK Kopint-Datorg Zrt. PMISZK PMISZK Nemzetbiztonsági Szakszolgálat FÖMI Kopint-Datorg Zrt. Kopint-Datorg Zrt. KEKKH MVH MeH EKK PMISZK OITH PMISZK Projekt A cégbírósági és céginformációs rendszerek korszerősítése Jogügyletek biztonsága Költségvetési Gazdálkodási Rendszer kiépítése Központi rendszer bıvítése és szolgáltatásfejlesztése Egyablakos vámügyintézés megteremtése Központi elektronikus fizetés megvalósítása Biztonságos elektronikus összeköttetés kiépítése Ingatlan-nyilvántartások elérhetısége Elektronikus Levéltár Közigazgatási Informatikai Közmő Elektronikus azonosítás Elektronikus anyakönyvi ügyintézés Agrártámogatások feltételeként elıírt megfeleltetési rendszer Interoperabilitás megvalósítása egyes nyilvántartásoknál Családtámogatási ellátások folyósításának korszerősítése Civil szervezetek nyilvántartásának modernizációja Adóalany-centrikus adatszolgáltatási modell megvalósítása Az Államreform Operatív Program (ÁROP) célja, hogy az igazgatási rendszer teljesítményét és a nyújtott szolgáltatások színvonalát a szőkös erıforrások optimális felhasználása mellett növelje. A közigazgatás akkor képes az átfogó célhoz a legnagyobb mértékben hozzájárulni, ha eléri az alábbi specifikus célokat: javuljon a társadalmi eredmény (növekvı eredményesség); takarékosan legyenek felhasználva a rendelkezésére bocsátott, illetve a mőködése által érintett társadalmi erıforrások (optimalizált hatékonyság) javuljon a közszolgálatiság. BME Informatikai Központ 16

17 A célok teljesülését az alábbi indikátor méri: a lakosság és a vállalkozások közigazgatás tevékenységével kapcsolatos országos szintő elégedettségének változása a program hatására, illetve növelni szükséges a közszektor termelékenységét. Ennek jegyében az ÁROP tartalmában a közfunkciók költséghatékonyabb megszervezését, pénzügyileg pedig a program keretében megvalósítandó intézkedések hosszabb távú fenntarthatóságát feltételezi. Az ÁROP keretében a közvetkezı projektek indultak: Projektgazda Projekt MeH Közpolitikai Titkárság MeH EKK MeH EKK TÖOSZ Dereguláció Elektronikus közigazgatási keretrendszer kialakítása E-közigazgatási Tudásportál Kistérségek feladatellátásának támogatása 3.5. Problémák Az E-közigazgatás 2010 stratégia [4] három fı területen lát feladatokat: Az IT fejlesztéseknek, a közigazgatási intézményeket középpontba állító hagyományos ügyintézési filozófiával ellentétben, az állampolgárok és a vállalkozások köré kell épülniük A közigazgatásnak az elosztott, integrált szolgáltatási kultúra felé kell elmozdulnia Szükséges a közigazgatási hozzáértés és tudás szélesítése és mélyítése az informatikai szolgáltatóknál Dr. Baja Ferenc kormánybiztos, a Technológiai platform és e-közigazgatás workshop-on tartott elıadásában [3] április 29-én a következı problémákat azonosította: A stratégiai irányítás és koordináció nem megfelelı háttere, hatékonysága A különbözı hivatalok ellenérdekeltsége, ellenállása A szolgáltatások nem megfelelı minısége, megbízhatósága, rendelkezésre állása A felhasználók felkészültségi hiányai, a nem kellıen ügyfélközpontú megoldások miatti elégedetlensége Az e-közigazgatási informatikai rendszerének jelenlegi mőködését tekintve az alábbi problémák vetıdnek fel: A jelentıs állami nyilvántartások mőködtetésének felelıssége szervezetileg tagolt. Saját informatikai rendszerét minden szervezet önállóan fejleszti. Különbözı szakrendszerek nyilvántartásainak összekapcsolása adatvédelmi szempontokból csak törvényi felhatalmazással, a célhoz kötöttség elvének érvényesítésével lehetséges. Ebbıl az következik, hogy a nyilvántartások adattartalmát törvények rögzítik. A törvényi felhatalmazások alapján alakítják ki az ellenırzött (naplózott) hozzáférési pontokat a felhatalmazott külsı szervezetek számára, jellegzetesen egyedi, pont-pont kapcsolatok kialakításával meglehetısen szoros csatolást okozva a szakrendszerek között. BME Informatikai Központ 17

18 Minden jogszabály-módosítás az érintett nyilvántartás(ok), és a nyilvántartást használók oldalán is fejlesztési feladatokat generál. Bármilyen módosítás a kapcsolatok ismételt, páronkénti egyeztetését igényli. Az ügyfélkapu túl az ügyfelek beléptetésén módot ad a saját portállal nem rendelkezı szakrendszerek megjelenésére a Kormányzati Portálon. Ez szükségessé teszi az együttmőködést, ami SOAP üzenetváltásokkal történik. Az üzenetek megjelenítendı adattartalmakból és annak formájára vonatkozó információkból állnak. A központi rendszer a szakrendszerbıl nézve egy speciális utasításkészlettel rendelkezı browserként viselkedik, a kommunikáció tehát a megjelenítés szintjén zajlik. Mindez nem lehet alkalmas a szakrendszerek logikai, szolgáltatás szintő, biztonságos kapcsolatának kiépítésére. 4. Jövıkép Az e-közigazgatás mőködésének jövıképét a következı szolgáltatásokkal jellemezhetjük. Az állampolgárok (ügyfelek) lehetıségei: Minden állampolgár, aki erre igény tart, a hatóságokkal és egyre bıvülıen a közszolgáltatást végzı szervezetetekkel és az üzleti élet szereplıivel adott élethelyzetében, felmerülı problémájának megoldására elektronikus ügyintézés keretében lehetıséget kap (elektronikus állampolgár). A szolgáltatásokat a számára legmegfelelıbb eszközökrıl (számítógép, mobiltelefon, stb.) helytıl és idıtıl függetlenül igénybe veheti. A szolgáltatások folyamatosan (7/24) rendelkezésre állnak. Rendelkezésére áll egy garantált, letagadhatatlan, biztonságos elektronikus levelezı rendszer, amelyet a hatóságokkal és a rendszerhez csatlakozott szolgáltatókkal, üzleti szereplıkkel való hivatalos kommunikációra használhat, küldemény érkezésérıl igénye szerinti értesítést kap (pl. sms). Rendelkezik egy csak általa elérhetı, biztonságos (sérülések, adatvesztések ellen védett, titkosított) tárhellyel. Az állampolgár biztonságos azonosítására a kockázatokat elfogadható szintre mérséklı megoldások állnak rendelkezésre. Az állampolgár ésszerő keretek között megválaszthatja az adott ügyhöz általa szükségesnek tartott biztonsági szintet. Az állampolgár egyetlen belépéssel (azonosítási folyamat) elintézheti az adott élethelyzethez kapcsolódó ügyeit, eközben egységes környezetben érezheti magát. Az azonosításhoz szükséges adatok kivételével nem kell olyan adatokat igazolnia, megadnia, amelyet valamely hatóság jogszabállyal rendszeresített nyilvántartásának tartalmaznia kell. A szolgáltatás igénybevételével ugyanakkor felhatalmazást ad arra, hogy az ügy elintézéséhez szükséges adatokat a hatóságok célhoz kötötten felhasználják. További szereplık lehetıségei: A közhivatalok munkatársai az állampolgárokhoz hasonló, de szerep alapú azonosítási és jogosultsági rendszerrel kezelhetı lehetıségeket használhatnak. Ügyintézési folyamataikat fejlett alkalmazások támogatják, amelyek végigvezetik ıket az BME Informatikai Központ 18

19 ügyintézés jogszabály szerinti menetén. A rutindöntések automatizáltak, a mérlegelést igénylı döntéseket a releváns adatok ergonomikus prezentációja segíti. A rendszerhez a közigazgatás szereplıi mellett fokozatosan továbbiak is csatlakozhatnak (közszolgáltatók, egyéb, jelentıs ügyfélforgalmú üzleti szereplık). Az üzemeltetık lehetıségei: A jogszabály-változások, az új csatlakozók belépése technikailag egyszerő, könnyen végrehajtható, átlátható módosításokkal valósítható meg. A jogosultsági rendszer átlátható, jól konfigurálható, a jogszabályoknak való megfelelés könnyen igazolható A rendszeradminisztráció és a felügyelet hatékony eszközökkel támogatott. Ezekhez a funkciókhoz és elvárásokhoz elıre vetítjük egy szolgáltatás-orientált architektúra kialakítását, felvázoljuk a magyar SOA alapú architektúra vízióját. Az architektúra levezetését és részletes ismertetését késıbbi fejezetek tartalmazzák. Az architektúra jelen dokumentumban a közigazgatási feladatok megoldását támogató, lehetıvé tevı informatikai rendszer komponenseit és azok együttmőködését jelenti. Komponensen értjük a meglevı intézményekben mőködı informatikai rendszerek (szakrendszerek) által szolgáltatott közigazgatási célú megoldásokat (pl. ügyfélkapu, adó- és járulékbevallás, lakcímigazolvány pótlása, cégbejegyzés) függetlenül attól, hogy azok az ügyfél által közvetlenül elérhetıek-e vagy sem. A komponensek az ügyfelek számára közvetlenül elérhetı (külsı) felülettel is rendelkezhetnek Az architektúra kialakításának alapelvei Önálló szakrendszerek A szakrendszerek önállóan, egymástól függetlenül fejlesztett, különbözı technológiai bázison álló informatikai rendszerek. Az architektúrában fekete dobozként viselkednek, velük szemben csak kapcsolódási felületükön (interfész) írhatók elı funkcionális és nem funkcionális követelmények. A KR szerepe bizonyos mértékig kitüntetett. Biztosítja az egységes beléptetési és azonosítási szolgáltatást (ügyfélkapu), valamint az e-közigazgatás kiindulási pontjaként a kormányzati portál funkciókat. Összetett funkciók végrehajtására a KR más szakrendszerek szolgáltatásait veszi igénybe. A tervezés idıhorizontján a szakrendszerek önállósága fennmarad, azonban a felhasználók számára is érzékelhetı átjárásokat és környezetváltásokat fokozatosan felszámolja a munkafolyamat-vezérelt végrehajtás egységes környezete. Az architektúra elvileg lehetıvé teszi a KR funkcióinak elosztását is. A kitüntetett szerepet az erıforrás-kihasználási, szervezési, biztonsági szempontok indokolják Meglévı rendszerek integrálása A rendszer teljes újratervezése, zöldmezıs beruházás indítása nem reális, de nem is indokolt. A meglévı alrendszerek jelentıs értéket képviselnek, és feladataikat nagyrészt megfelelıen ellátják, így teljes cseréjük az esetek többségében nem indokolt. Emellett az BME Informatikai Központ 19

20 ÚMTF idıhorizontján a rendelkezésre álló források sem teszik lehetıvé a zöldmezıs megoldást. A javasolt SOA-alapú integráció (integráción itt a heterogén alrendszerek olyan együttmőködésének kialakítását értjük, amelyik biztosítja az egységes rendszerként való viselkedést a rendszer felhasználói számára) alkalmas a jelentıs továbblépésre Laza csatolás igénye A szakrendszerek önállóságának alapelvébıl következıen olyan megoldásra kell törekednünk, amelyben a kapcsolódó alrendszerek és komponensek (itt szakrendszerek) fekete dobozként viselkednek, közöttük a függıség a lehetı legkisebbre korlátozódik. Egy rendszer egy (függı) eleme, komponense függ a rendszer egy másik (független) elemétıl, komponensétıl, ha a független elem megváltozása a függı elem változását vonja maga után. Az együttmőködés egyben valamilyen mértékő függést is jelent, de az együttmőködés módja lényegesen befolyásolja a függıség mértékét. A fekete doboz elv és az interfész bevezetése csökkenti a függıség mértékét, az interfész-specifikáció megtartása mellett a komponens belsı szerkezete tetszés szerint változtatható anélkül, hogy más komponensek változtatására lenne szükség. Az így kialakuló laza csatolás a minimális függıséget jelenti. A szakrendszerek önállóságának megtartása laza csatolást követel Sín topológiájú logikai kapcsolatok kialakítása. A rugalmas bıvíthetıség és a fokozatos fejlesztés igénye miatt a kapcsolódó komponensek belsı szerkezetének elrejtése mellett a kapcsolatot biztosító sín egységesítését, szigorú felügyeletét, skálázható kialakítását kell biztosítani. Az egységes sín az összekapcsolt komponensek számának növekedésekor is elkerülhetıvé teszi a páros kapcsolatok számának négyzetes növekedésébıl adódó komplexitási problémát, így a várható további csatlakozások (önkormányzat, régió, közszolgáltatók, üzleti szereplık) kezelése könnyebben uralható Nyílt szabványok és specifikációk alkalmazása A szakrendszerekben mőködı informatikai rendszerek különbözı platformokon épülhetnek fel. Ezen heterogén rendszer elemeinek összekapcsolásához gyártófüggetlen, nyílt, lehetıleg elterjedten alkalmazott szabványokon alapuló megoldásokra kell építeni. Ez a megoldás csökkenti a szállítófüggıséget, a gyártóknak való kiszolgáltatottságot, egyben biztosítja a rugalmas továbbfejleszthetıséget és a szállítói verseny lehetıségét A folyamatos mőködés fenntartása fokozatos fejlesztés A közigazgatás biztonsága, folyamatos mőködésének fenntartása, a folyamatban levı és a korábbi ügyek elérésének igénye miatt ez az igény természetes, hiszen nem lehet tartós (1-2 napot meghaladó) közigazgatási üzemszünetet meghirdetni. Ezért az architektúra rugalmasságának a fejlesztés fokozatosságát is támogatnia kell. Biztosítani kell, hogy a meglévı egyedi szakrendszer-közi kapcsolatok együtt éljenek a sín jellegő új kapcsolatokkal, és fokozatosan legyenek azokkal kiválthatók. BME Informatikai Központ 20

21 Helytıl és idıtıl független elérhetıség Az architektúra kialakításakor figyelemmel kell lenni a helytıl és idıtıl független elérhetıségre, a különféle eszközökkel való csatlakozás lehetıségére Összetett szolgáltatások végrehajtásának támogatása A több szakrendszert érintı ügyintézés támogatására a szakrendszerek együttmőködését is magába foglaló, magasszintő munkafolyamat-kezelı komponenseket kell kialakítani Az e-közigazgatási szolgáltatási sín A javasolt architektúra központjában az e-közigazgatási sín áll, amely szolgáltatási szinten kapcsolja össze a szakrendszereket (ebben az értelemben a KR is a szakrendszerek egyike). A szolgáltatási szint azt jelenti, hogy a szakrendszerek által eddig nyújtott és ezután tervezett funkciókat szolgáltatás formájában publikálni kell, és elérhetıvé kell tenni minden arra feljogosított komponens (szakrendszer) számára. Például egy szakrendszer megvalósít és kiajánl egy szolgáltatást, amely egy rendszámról eldönti, hogy az körözött-e. Ezt a szolgáltatást igénybe veheti valamennyi a használatra feljogosított komponens. Az összekapcsolás azt jelenti, hogy a szolgáltatást kérı és nyújtó szakrendszerek között szabványnak megfelelı, egységes együttmőködés épül ki. Az egységesség abban nyilvánul meg, hogy a szolgáltatás kérésének, elérésének módja független attól, hogy melyik komponens szolgáltatását vesszük igénybe. Az e-közigazgatási szolgáltatási sín részét képezik emellett azok a standard szolgáltatások, amelyek a sín használatához szükségesek (pl. cím- és névkezelés, sínfelügyelet, stb.) Az e-közigazgatási sínnel szemben támasztott követelmények A német architektúra-koncepcióban [14] foglaltakkal is megerısítve az alábbi követelményeket kell megfogalmaznunk a komponensek kapcsolatát biztosító sínnel szemben: Bıvíthetıség: a rendszer gazdaságosan bıvíthetı új funkciókkal Rugalmasság: az a képesség, hogy az architektúrát újabb követelményeknek megfelelıen módosítani lehet Interoperabilitás: heterogén rendszerek együttmőködésének támogatása Nyitottság: meglevı és új rendszerek kis költséggel integrálhatók Teljesítmény: a funkcionalitások végrehajtásának sebessége Biztonság: az információkat csak a kialakított biztonsági politikának megfelelıen lehet megszerezni vagy módosítani Skálázhatóság: növekvı terhelés mellett a hatékonyság és a teljesítmény szintentartása Megbízhatóság: a rendszer hálózati és egyéb hibák során is képes a kérések fogadására BME Informatikai Központ 21

22 Rendelkezésre állás: annak a mértéke, hogy az alkalmazás mennyire képes kiesésmentesen mőködni Karbantarthatóság: a rendszert a fejlesztésben részt nem vevık is könnyen mőködtethetik és felügyelhetik Újrahasznosíthatóság: a rendszer komponensei az eredetileg tervezettel azonos vagy ahhoz hasonló feladatok során is felhasználhatók Az e-közigazgatási sín kialakítása A 2. ábra három jelenleg is mőködı komponenst (a KR központi rendszer az ügyfélkapuval, másik két szakrendszer (H1 és H2)) és az e-közigazgatási sín mutat be. A szakrendszerek a felhasználókkal, a kormányzaton kívüli szolgáltatókkal az interkom -on keresztül kapcsolódnak, amely tetszıleges kommunikációs technológiát (internet, telefon) és a rajta keresztül nyújtott szolgáltatásokat (pl.sms küldés/fogadás) jelenti. A e-közigazgatási sín két részbıl áll, a közmőbıl és az adapterekbıl. A közmő valamennyi kapcsolódó szakrendszer számára egységes felületet ad, alsó rétege a kormányzati gerincháló. Az adapter (az ábrán sraffozott) a szakrendszer része, feladata a konkrét szakrendszer illesztése a sínre. Az e-közigazgatási sínt nevezzük szolgáltatási sínnek is. interkom Ügyfélapu +portál KR portál H1 portál H2 Személyes tár Postafiók Ügygazda e- közig sín Közmő EKG 2. ábra - Az e-közigazgatási sín áttekintése A szolgáltatási sínre kapcsolódó szakrendszerek nyílt szabványok szerint definiálják az általuk nyújtott szolgáltatásokat, és a szolgáltatások igénybevételéhez szükséges üzeneteket (adatszerkezeteket). A szolgáltatási sín biztosítja a rajta keresztül küldött üzenet egyszer és csakis egyszer történı kézbesítését. BME Informatikai Központ 22

23 Az e-közigazgatási szolgáltatási sínhez tartozó további alapfunkciók (cím- és névkezelés, felügyelet, stb.) ugyancsak szolgáltatásként érhetık el a sín szabályai szerint. A központi rendszerre tervezett további funkciók, így az állampolgárok személyes, biztonságos tárhelye, és az állampolgári jogon járó postafiók, valamint a bonyolult, sok szakrendszer szolgáltatását igénylı, összetett ügyek (például: házasodni szeretnénk) munkafolyamat kezelése megfelelı alkalmazások, szerverek, motorok használatával valósíthatók meg, amelyek a sín szabályai szerinti szolgáltatásokat nyújtanak, illetve vesznek igénybe Az architektúrához kapcsolódó fogalmak Szolgáltatás A szolgáltatás olyan, a szolgáltató által végzett tevékenység (folyamat), amely tevékenység a szolgáltatást kérı számára értékkel, jelentıséggel bíró eredményt, hatást állít elı. A szolgáltatás megvalósulásáért, a szolgáltatás eredményéért a szolgáltató a felelıs. A szolgáltatás specifikációja az interfészen megkövetelt viselkedés megadásával történik. A szolgáltatást kérı a kérés kezdeményezéseként készít egy üzenetet, amely tartalmazza a szolgáltatás igénybevételéhez szükséges adatokat (a szolgáltatás megnevezését, paramétereket, tanúsítványokat). Paraméter lehet bármely adat, információ (pl: egy utcaszakasz hossza méterben kifejezve egy tizedes pontossággal, egy szerzıdés.doc formátumban, fénykép.gif fájlban, audió mp3-ban, korábbi jegyzıkönyveket tartalmazó katalógus.zip-ben tömörítve, egy probléma fellépése esetén igénylendı szolgáltatás neve stb.), amelynek a kérés pillanatában rendelkezésre kell állnia. A szolgáltató a szolgáltatás elvégzését elıfeltételek teljesüléséhez, fennállásához kötheti. Elıfeltétel lehet a paraméterek megfelelı értéke. Például: lakcím szolgáltatás Paraméterek a) a polgár személyi száma, b) az a dátum, amely napra vonatkozóan kérjük a lakcímet, c) az ügy száma, amelyben a lakcím kell Elıfeltételek: a) érvényes személyi szám, amely valóságos élı vagy elhunyt személyhez tartozik b) a dátumnak az aktuális dátumnál korábbinak kell lennie c) az ügyszámnak érvényesnek kell lenni A szolgáltatást kérı utasítja a közigazgatási szolgáltatási sínt hogy az üzenetben szereplı szolgáltató a szolgáltatást specifikáló tevékenység egy példányát (cselekmény) készítse el, és azt az üzenet paramétereivel hajtsa végre. Minden szolgáltatáskérés alkalmával új cselekmény keletkezik, amely cselekménynek a feladata a konkrét kérés kiszolgálásához tartozó absztrakt tevékenység végrehajtása (pl: az 1234 személyi számú polgár május 22-én érvényes lakcímének kiadása az XXXY ügyben) Cselekmény Cselekmény egy szolgáltatáskérés alkalmával jön létre. A cselekmény a végrehajtás idejéig él. A cselekmény addig létezik, amíg a szolgáltatás nyújtásához szükséges tevékenység be nem BME Informatikai Központ 23

24 fejezıdött. A tevékenység idıben zajlik le, egy szolgáltatás elvégzésének ideje a másodperc tört részétıl kezdve évekig tarthat, függıen a szolgáltatás bonyolultságától. Hiába végzi két cselekmény ugyanazon szolgáltatást, a két cselekmény két különálló entitás, amelyek különbözı idıpillanatokban születnek és érnek véget (megfelelı finomságú idıalapot alkalmazva). A szolgáltatás konkrét végrehajtásához mindig tartozik egy környezet (kontextus). Egy cselekmény környezetébe értjük mindazon a cselekményen kívül álló tıle függetlenül létezı komponenseket, amelyek a szolgáltatás végrehajtásának lefutását valamilyen módon befolyásolhatják. A lakcím szolgáltatás példa esetében a környezet nyilvánvalóan tartalmaz egy adatbázist, amelyben a személyi számmal indexelve megkapjuk a lakcímet. Fontos megjegyezni, hogy a lakcím adatbázis nem része a cselekménynek, a cselekmény azt csak mint a környezetéhez tartozó komponenst felhasználja. A szolgáltatás megkezdését követıen a környezettel való együttmőködés révén szerzett információ nem paraméter A szolgáltatás állapotfüggetlen A szolgáltatás állapotfüggetlensége azt jelenti, hogy ha a szolgáltatást ugyanazon paraméterekkel, változatlan környezetben többször végrehajtjuk, minden alkalommal ugyanazon eredményt fogjuk kapni. Megfordítva: ha egy szolgáltatástól elvárjuk, hogy bizonyos adatoktól, információtól függı eredményt szolgáltasson, akkor azokat az adatokat, információkat a környezeten és/vagy a paramétereken keresztül kell - az alkalmazás szintjén - átadni. A cselekmény kapcsolatokat tart fent. Egy szolgáltatás végrehajtása során a cselekmény kapcsolatban van (lehet) a saját maga által a végrehajtás idejére létrehozott komponensekkel (pl. temporális változók, az átvett paraméterek) a környezetében tıle függetlenül létezı komponensekkel (pl: adatbázisok, globális adatok). Ez utóbbiak közé tartoznak a szolgáltatások is. Azaz egy szolgáltatás a feladata megoldásához igénybe vehet más szolgáltatásokat, vagyis egy szolgáltatás megvalósításában (tevékenység) lehetnek újabb szolgáltatáskérések A szolgáltatáskérés aszinkron A szolgáltatást kérı kezdeményezi a szolgáltatást megvalósító cselekmény elindítását, de nem várja meg annak befejezıdését, hanem folytatja mőködését. A kérés kiadását követıen tehát "egymással párhuzamosan" folyik tovább a szolgáltatást kérı és a kért szolgáltatást megvalósító cselekmény. A kérést kiadó cselekmény a vele párhuzamosan zajló szolgáltatási tevékenység eredményérıl a környezetébıl tájékozódhat. Ehhez az szükséges, hogy a szolgáltatás valamilyen változást idézzen elı a kérı cselekmény környezetében. Ennek különbözı jól bevált technikai megoldásai ismertek. Például a szolgáltatás a befejezıdésekor egy a szolgáltatást kérıvel közösen használt adatbázisba tesz egy bejegyzést. A szolgáltatást kérı a neki alkalmas idıben vizsgálhatja a bejegyzés meglétét, várakozhat annak megtörténtére. Jelen architektúrában preferált megoldás, hogy a szolgáltatás befejeztével a kiszolgáló meghív (visszahív, callback) egy a két fél által egyeztetett szolgáltatást (tipikusan a hívó oldal BME Informatikai Központ 24

25 környezetében), ahol magasabb szintő komponensek (pl. BPEL-várakozás) igénybevételével szerezhet a hívó tudomást a szolgáltatás eredményérıl. A szolgáltatáskérést követıen közvetlenül kezdeményezett - a szolgáltatás eredményére történı várakozás együttesen alkalmas a szinkron módú szolgáltatáskérés szimulálására. A szolgáltatást kérı utasíthatja a közigazgatási szolgáltatási sínt arra, hogy maga a sín jelezzen vissza a szolgáltatást kérınek akkor, ha a szolgáltató vette a szolgáltatást kérı üzenetet. Ez egy tértivevény, amelynek elküldésére a szolgáltatónak semmiféle ráhatása nincs, tıle teljesen függetlenül történik Ügyek megvalósítása Az e-közigazgatási ügyeket a különbözı szolgáltatók egymásnak nyújtott szolgáltatásainak együtteseként írhatjuk le és valósíthatjuk meg. Egy e-közigazgatási ügy olyan tevékenységsorozat, amelyet konkrét közigazgatási aktus elıkészítése, kibocsátása és végrehajtása érdekében valósítanak meg. Az ügy példánya az eljárás, amely egyben az ügy végrehajtásával kapcsolatos cselekmények összessége. Például ügy alatt értjük egy autó forgalomból történı kivonásával kapcsolatos tevékenységek összességét általános szinten, úgy, ahogy az egy ügyleírásban szerepel. Eljárásnak nevezzük ennek a konkrét ügynek a megvalósulását, ha pl. Balog Atanáz kivonatja a forgalomból az ABC123 rendszámú autóját. Az ügy egy tevékenysége az illeték befizetése igazolásának benyújtása, míg ennek a tevékenységnek a konkrét példánya (cselekménye) a Balog Atanáz általi 8765 Ft befizetését igazoló feladóvevény benyújtása. Azokat az ügyeket, amelyeket definiáló tevékenységsorozatban nem szerepel szolgáltatáskérés, mert az ügyet a szolgáltató maga egyetlen aktussal meg tudja oldani, egyszerő, vagy primitív ügynek nevezzük. Ilyen például a korábban példaként említett lakcím lekérdezés. Azt az ügyet, amelynek a végrehajtásához szükséges tevékenységek között szerepel szolgáltatás igénybevétele, összetett ügynek nevezzük. Ha valaki kér egy szolgáltatást, akkor nem kell tudnia, hogy a szolgáltatás elvégzése egyszerő vagy összetett folyamat-e. Elegendı ismerni a szolgáltatás nevét és az átadandó paramétereket,. Ez a megoldás biztosítja a szolgáltatást kérı és a kiszolgáló közötti leglazább csatolást Szolgáltatási sín A kérı és a kiszolgáló között kell lennie egy mechanizmusnak, amely megoldja szolgáltatáskérések és paraméterek továbbítását, gondoskodik a kérést tartalmazó üzenet szolgáltatónak történı átadásáról. Ezt a mechanizmust nevezzük közigazgatási szolgáltatási sínnek. A szolgáltatási sín egy csomagtovábbító közmő (tekinthetjük egyfajta postának) és egy csomagoló réteg együttese. A csomagoló réteg implementálása a szolgáltatónál történik. A csomagoló réteg feladata az üzenetek csomagokká történı átalakítása és visszaalakítása. A közmő biztosítja, hogy a csomag legkevesebb egyszer (at least once) átadásra kerül a csomagoló rétegnek. A csomag titkosítva van, és garantált, hogy csak a szolgáltatás oldalon a csomagoló rétegbeli komponens tudja elolvasni. A szolgáltatási sín és a felette álló alkalmazási rétegek között a szolgáltatáskéréseket reprezentáló üzenetek teremtik meg a kapcsolatot. Az interoperabilitás biztosítása miatt szükséges az üzenetek formájának szabványosítása. Célszerő választásnak tőnik valamely széles körben elterjedt, nyílt szabvány alkalmazása. Ennek egyenes következménye, hogy az BME Informatikai Központ 25

26 egyes szakrendszereknek a fenti szabvány által elıírt formában megadott üzenetekkel leírható szolgáltatásokat kell megvalósítania, az üzenetek eljuttatása pedig az alkalmazástól független szolgáltatási sín feladata. Azaz a sín és az alkalmazás egymástól függetlenül fejleszthetı, a csatlakozási felület az üzenet. A szolgáltató oldalán el kell készíteni a csomagoló réteg komponenseinek, a csomagküldınek és a csomagfogadónak az implementációját SOA Az OASIS definíciója szerint a Service Oriented Architecture (SOA) [16] különbözı érdekeltségek hatáskörében álló elosztott erıforrások és képességek szervezését és hasznosítását lehetıvé tevı paradigma. Definiálja az erıforrások és képességek egységes módon történı felkínálását, felderítését, együttmőködését és felhasználását annak érdekében, hogy ellenırizhetı elıfeltételeknek és elvárásoknak megfelelı eredményt, hatást érjünk el. A SOA központi fogalma a szolgáltatás. Hétköznapi értelemben a szolgáltatás egy szereplı által egy másik szereplı számára végrehajtott munkát jelenti. A szolgáltatás azonban a következıket is magába foglalja: képesség más számára való munkavégzésre a végrehajtandó munkatevékenység leírása hajlandóság a munka végrehajtására és ennek felkínálása Ezek a pontok kihangsúlyozzák a különbséget a képesség megléte és annak végrehajtása között. Habár az igények és a képességek a SOA-tól függetlenül is léteznek, a SOA-n belül a szolgáltatások azok, amik ezeket az igényeket és képességeket összehozzák egymással. A SOA egy eszköz, amely a megoldások rendszerezését támogatja oly módon, hogy elısegíti az újrahasznosíthatóságot, a bıvíthetıséget és az interoperabilitást. A javasolt architektúra láthatólag egybeesik a SOA paradigmával SOA alapú architektúra Az e-közigazgatási sínre szolgáltatók csatlakoztathatnak. A sín biztosítja, hogy a szolgáltatáskérések egyszer és csakis egyszer jussanak el a kérıtıl a kiszolgálóig. A sínre csak regisztrált szolgáltatók kapcsolódhatnak. A sínhez való hozzáféréskor tanúsítványok alapján, automatikusan történik meg azonosításuk és hitelesítésük. Ha a szolgáltató átvesz egy neki szánt üzenetet, a sín automatikusan egy digitálisan aláírt tértivevényt küld a kérınek, amellyel a kérı igazolni tudja, hogy az üzenetét átvették, a szolgáltató pedig ezt nem tudja letagadni. A sín nem titkosítja az adatokat és nem ellenırzi azt, hogy a kérınek joga van-e meghívni egy adott szolgáltatást. Amennyiben ilyen igény felmerül, azt szolgáltatás szinten kell megvalósítani, amelyre jó eszköztámogatás létezik. Az adatvédelmi jogszabályokkal való konformitás biztosításához lehetıség van felhatalmazások készítésére, amelyek segítségével az érzékeny adatok csak az arra illetékes szereplı által és csak egy meghatározott ideig kérdezhetık le. Az e-közigazgatási sínre csatlakoznak a szakrendszerek, mint szolgáltatók. A szakrendszerek üzemeltetıinek feladata, hogy a többi szakrendszer számára a szükséges szolgáltatásokat biztosítsák. Nyilvánvalóan a szakrendszerek jelenleg is üzemelı változatai a maguk implementációs módjaival megvalósítják a szolgáltatásoknak megfelelı funkciókat. A sínre történı csatlakozás lényege, hogy a meglevı funkciók és a sín közötti kapcsolatot a BME Informatikai Központ 26

27 szakrendszerben meg kell teremteni. Ehhez csatoló adaptereket kell készíteni. Az adapterek készítése várhatóan a szakrendszer fejlesztıinek, üzemeltetıinek feladata Paraméterek egységesítése A szakrendszerek sínre történı kapcsolódásához tartozik a szolgáltatáskérések paramétereinek egységesítése. Valószínősíthetı, hogy a különbözı szakrendszerek különbözı adatszerkezeteket használnak ugyanazon entitások kezelésére (pl. név, lakcím). Az egységes adatszerkezetek lehetıvé teszik, hogy minden szakrendszer változatlanul megtarthassa és alkalmazza a saját szerkezetét a szakrendszeren belül. A sínen alkalmazható egységes adatszerkezet mindössze azt teszi szükségessé, hogy minden szakrendszer a saját adatszerkezeteit a sínre "kifordítsa". Ez biztosítja a laza csatolást, hiszen az egyes szakrendszereknek a saját adatszerkezetén kívül csak a közös formátumot kell ismerni, és feleslegessé teszi egy hatalmas mindenrıl-mindenre transzformáló adatklíring-ház kidolgozását A központi rendszer A sínre történı kapcsolódás szempontjából a szakrendszerek egyike a központi rendszer. A központi rendszer valósítja meg jelenleg az ügyfélkaput és a tárhelyet. Az ügyfélkapu, mint az ügyfél beléptetésének eszköze, felhasználói portálként mőködik. Ez a funkció a továbbiakban is szükséges. A sínre történı kapcsolódás érdekében a központi rendszerben megkívánt változtatás mindösszesen annyi, hogy amennyiben az ügyfél a portálon olyan funkciót indít, amely szakrendszert érint, akkor annak elérése a sínen keresztül elérhetı szolgáltatás közremőködésével történjen. A központi rendszer továbbfejlesztésére az architektúrával összhangban az alábbi javaslatokat tesszük Állampolgári postafiók Az ügyfélkapun található állampolgári tárhely pillanatnyilag az APEH-tıl érkezı üzenetek fogadására szolgál. Hosszabb távon ezt a funkciót fel kellene váltani az állampolgári postafióknak és a személyes tárnak. Az állampolgári postafiók egy biztonságos (letagadhatatlan, titkos) és megbízható levelezırendszerhez kapcsolódna, és ez a levelezırendszer szolgálna az állampolgár és az állam közötti hivatalos levelezésre. Minden állampolgár az állampolgársága, születése jogán kapna egy postafiókot. Az állam képviseletében eljárók az állampolgárnak szóló valamennyi hivatalos üzenetet erre a postafiókra küldenék. A postafiók tulajdonosának lehetısége lenne megszabni, hogy a postafiókba érkezı levéllel mi történjék. Elıírhatja, hogy a levél egy példányát kinyomtatva a nevére postai úton továbbítsák, kapjon egy SMS üzenetet a megadott számra, vagy továbbítsák a levelet (feladót) más postafiókba. Ezek a továbbítások a polgár kockázatára (és költségére) történnének. Egyebekben a polgár felelıssége, hogy az állampolgári postaládáját ugyanúgy megnézze, mint a lakásán elhelyezett levelesládát. Azon állampolgárok számára, akiknek nincs internetes kapcsolatuk, a teleházakban, iskolákban, önkormányzatoknál, könyvtárakban kell biztosítani az internet elérést, beleértve az ügysegéd segítségét is. Természetesen a rendszer mőködhet önkéntességi alapon is, amikor az alaphelyzet a postai BME Informatikai Központ 27

28 kézbesítés (azaz a jelenlegi rendszer), és az állampolgár igényelheti az elektronikus továbbítást, vagy vállalhatja a rendszeres ellenırzést ami célszerően jogkövetkezményekkel is jár. A biztonságos levelezési infrastruktúra megkönnyítené a hivatalközi nem formalizált információcsere elektronizálását. A vállalkozások számára történı nyitás pedig az élet sok területén tudná fellendíteni az elektronikus ügyintézést Személyes tárhely Megfontolásra érdemes a kormányzati fejlesztési koncepciókban szerepel is egy személyes tárhely bevezetése. Az államnak is főzıdik érdeke ahhoz, hogy a polgárok a hivatalos irataik elektronikus változatait ne nehezen ellenırizhetı internetszolgáltatóknál és egyéb internetes cégeknél, esetenként a munkahelyükön ırizgessék. A személyes tár kizárólag az állampolgár által látható tárterület, ahová tetszıleges fájlok tölthetık a felhasználó gépérıl és az állampolgári postaládából. A személyes tárban tárolt anyagok mellékletként csatolhatók az állampolgári postafiókról indított levelekhez. A biztonságos levelezırendszer alapjául érdemes a közigazgatási sínt választani. A személyes tár a sínnel nincs kapcsolatban Ügygazda A közigazgatási ügyek jelenleg a meglévı szakrendszerekhez vannak rendelve, jogszabályok rögzítik az egyes szakrendszerek feladatát és felelısségét az ügyintézés során. Az ügyfélkapu továbbfejlesztése során érdemes az ügyfélnek eset vagy helyzet alapú támogatást nyújtani. Például: eladtam az autómat, házasságot szeretnénk kötni, gyermekem született, haláleset a családban, elvesztettem a tárcámat stb. Magasabb szinten ezek is tekinthetık igazgatási ügynek. Nyilvánvalóan ezek az ügyek többszörösen összetettek, hiszen nagyon sok szakrendszert érinthetnek. Általában felvetıdı kérdés, hogy az összetett szolgáltatási folyamatok végrehajtásának, és különösen a ma még nem létezı szolgáltatásoknak melyik szakrendszer legyen a gazdája. Erre sok esetben egyszerő választ adhatunk a szakrendszerek meglevı funkcióinak, szolgáltatásainak áttekintése alapján. Célszerőnek tőnik a sok szolgáltatást igénylı, összetett ügyek felelısévé, gazdájává a központi rendszert megtenni. Ezt részint a fokozatos fejlesztés elve indokolja, mely szerint elsı lépésben a munkafolyamatok végrehajtására alkalmas rendszert egy helyen érdemes megvalósítani és a tapasztalatokat értékelve továbblépni. Ismereteink szerint a központi rendszerben megvannak a megfelelı erıforrások ehhez a feladathoz. Ez persze nem zárja ki, hogy bármely másik, ma még esetleg nem is létezı szakrendszerhez is telepíthetnek ügyeket. Folyamatok és így igazgatási ügyek technológia-közeli leírására jelenlegi ismereteink alapján a BPEL nyelv használatát javasoljuk. Nyílt szabvány, amely mára még nem kellıen stabilizálódott, de a trendek szerint arra halad. Jelenleg szabványosított változatai és implementációi korlátozottan hordozhatóak, az egyes implementációk a szabványváltás miatt jelentısen eltérnek. Az igazgatási folyamatok leírásával foglalkozó alprojekt részletesen elemzi a BPEL alkalmazásának lehetıségeit, korlátait. Valószínőleg ma a BPEL a folyamatok magasabb szintő leírására nem megfelelı, viszont más, jól definiált, szabványosított, megfelelıen támogatott (végrehajtható), elterjedt, magas szintő leíró nyelv nem található. BME Informatikai Központ 28

29 A javasolt megoldás: egy magas szintő szöveges/grafikus folyamatspecifikációból (pl. UML, BPMN) kiindulva a BPEL leírás kézi vagy automatikus generálása. Egyre több eszköz (nyílt és fizetıs) kerül forgalomba, amelyben van BPEL motor. A BPEL implementációk nagy elınye, hogy közvetlenül kapcsolódhatnak a WSDL-ben leírt web-szolgáltatásokhoz. Fentiek szerint indokolható, ha fıleg az összetett ügyek esetében a szolgáltatások technológiai szintő leírására a BPEL-t választjuk. Ezért célszerőnek tartjuk a központi rendszert is felszerelni egy BPEL kerettel és motorral. A KR-tıl függetlenül valamennyi, a sínre kapcsolódó szakrendszer felszerelhetı munkafolyamatok kezelésére alkalmas informatikai rendszerrel. Semmi nem akadályozza meg a szakrendszereket abban, hogy az általuk nyújtott szolgáltatások megvalósítására folyamatkezelésre szolgáló eszközt (pl. BPEL keretet és motort) használjanak Sín implementáció A szolgáltatási sínnek biztosítania kell a megbízható üzenetközvetítést, amibe beletartozik az is, hogy a burst jelleggel rövid idıszakon belül jelentkezı hatalmas mennyiségő üzenetet (pl. adóbevallási határidı elıtti idıszakban) kell továbbítani. Ez azt jelenti, hogy a sínnek alkalmasnak kell lennie a rengeteg üzenet átmeneti tárolására, ami megfelelı tároló berendezéseket is igényel. (a pontos méretezést a korábbi években méréssel szerzett tapasztalatok alapján kell elvégezni). Tekintettel arra, hogy a központi rendszerben a szükséges infrastruktúra megvan, célszerő a közigazgatási sínnek ezeket a funkcióit is ott megvalósítani A felügyeleti sín A sínt implementáló rendszer telepítését illetıen lehet centralizált, de lehet elosztott is. Nyilvánvalóan az üzembiztonság érdekében a sínre csatlakozó szakrendszereket, beleértve a központi rendszert is cluster-szerkezetben érdemes megvalósítani. Önmagában a SOA architektúrát nem befolyásolja az a körülmény, hogy bármely szakrendszer centralizáltan vagy elosztva csatlakozik-e a sínre. A közigazgatási szolgáltatási sín feladata a szolgáltatások közvetítése a sínre kapcsolódó komponensek számára. Ehhez nyilvánvalóan meg kell oldani a szolgáltatások életciklusának felügyeletét, a szolgáltatások követését, általában a szolgáltatások menedzsmentjét. Az életciklus vezérlése, felügyelete kiterjedhet már a modellezés fázisára is, de mindenképpen beletartozik a komponensek konfigurálása, integrálása, telepítése, üzemeltetése és az üzembıl történı kivonása. Mindez úgy is elképzelhetı, hogy a közigazgatási szolgáltatásokat nyújtó sín fölött megtalálható egy olyan sín, amely menedzsment és felügyeleti szolgáltatásokat biztosít jelen rendszertervben ezt nevezzük felügyeleti sínnek. A felügyeleti sínre kapcsolódnak a közigazgatási szolgáltatások menedzselésére vonatkozó szolgáltatások. Ezek a következı típusú szolgáltatásokat jelentik: A szolgáltatások szerkezeti felügyelete milyen szolgáltatások és hol telepítettek A szolgáltatások dinamikus felügyelete a szolgáltatások életével, mőködésével kapcsolatos lekérdezések, beavatkozások Naplózások, statisztika, diagnosztika és tesztelés. A dinamikus felügyelet és a naplózások, valamint a statisztika készítésére és kiértékelésére szolgál a Business Activity Monitoring (BAM). A BAM a Gartner szerint [13] biztosítja az BME Informatikai Központ 29

30 üzleti folyamatokhoz történı valós idejő hozzáférést, az üzemeltetık által definiált KPI-k (Key Performance Indicators) követésével és kijelzésével módot a szolgáltatások minıségi paramétereinek (sebesség, várakozás stb.) javítására. A gyártók a SOA eszközeiket ellátják BAM támogatással. Heterogén rendszerek esetében az egyes BAM funkciók illesztése szükséges Fejlesztés Az e-közigazgatási sín közmő részének egyedi fejlesztése nem javasolható, egy megbízható szállító kész SOA rendszerét célszerő megvásárolni és telepíteni, vagy egy jól mőködı közösség által menedzselt és tapasztalatokkal rendelkezı szakértıi csapattal támogatott nyílt forráskódú megoldást célszerő választani. Várhatóan a leggyakoribb fejlesztési feladat egy-egy új szolgáltatás elkészítése lesz. Valamennyi mértékadó szállító a keretrendszerébe fejlesztı eszközöket is integrál. Az integrált fejlesztı eszközök lehetıvé teszik, hogy a gyártó architektúrájában értelmezett komponensek könnyen kiválaszthatók, összeköthetık, és az összekötések paraméterezhetık legyenek. A különbözı gyártók fejlesztı eszközeivel készített alkalmazások egyedi hangolásokat követıen interoperábilissá tehetıek. Ez az interoperabilitás viszont nem terjed ki a fejlesztési folyamatra. Azaz ugyanazon alkalmazás kifejlesztése különbözı termékekben teljesen különbözı fejlesztési folyamatokat igényelhet. Új szolgáltatás fejlesztésénél ritkábban, de alkalmanként szükséges lehet az adapterek kifejlesztése is. A fejlesztések hordozhatósága iránti igény indokolja egy közös fejlesztı technológiai platform létrehozását. Ennek alapja a Model Driven Architecture (MDA) [52] elv lehet. A fejlesztési folyamatban azonosítani kell az alkalmazásfüggı és alkalmazásfüggetlen, valamint a keretrendszerfüggı és keretrendszerfüggetlen részeket. Ezek alapján olyan modelleket és termékeket kell kifejleszteni, amelyek segítségével az eszközökbe betölthetı forráskódok minél nagyobb része automatikusan elıállítható. 5. Megoldási lehetıségek Ez a fejezet az e-közigazgatási szolgáltatási sín architektúráját választja ki és ismerteti. Ennek keretében összefoglaljuk a ma ismert hasonló célú rendszerek szokásos architektúráit, kiindulva a KOPINT-DARORG jelent projekt keretében készített tanulmányaiból, valamint az egyes nemzeti weboldalakon közzétett és jelen rendszertervben külön nem referált anyagokból. A különbözı változatok elemzését követıen javaslatot teszünk az architektúrával szembeni követelményrendszer fı pontjaira, majd indokoljuk a javasolt architektúrát Nemzetközi tapasztalat A következı alfejezetben bemutatjuk négy ország e-közigazgatási projektjének az architektúrához kapcsolódó megoldásait és tapasztalatait. BME Informatikai Központ 30

31 Németország A német elektronikus közigazgatás fejlesztését és üzemeltetését szolgáló technikai, szemantikai, IT biztonsági, alkalmazásfejlesztés módszertani, valamint projekt-menedzselési és monitoringra vonatkozó elıírások, szabványok és követelmények legtöbbje a jelenleg negyedik verziójú SAGA címő dokumentumban föllelhetı. A SAGA kapcsán megfogalmazott alapvetı célok a következık: a) Interoperabilitás különbözı e-kormányzati alkalmazások együttmőködése az állampolgárok, a szövetségi kormányzati intézmények és partnereik közötti hatékony információáramlás érdekében. b) Újrafelhasználhatóság Azonos vagy hasonló elveken mőködı szolgáltatásnyújtás, illetve adatmodellek kialakítása a közigazgatás különbözı szintjein. Így a tartományi és a kommunális/helyi közigazgatási szerveknek lehetıségük van arra, hogy a BundOnline 2005 projekt eredményeit felhasználják, alkalmazzák. c) Nyitottság A hosszú távú alkalmazhatóság érdekében nyílt szabványok felhasználása az e- kormányzati rendszerekben. d) Költség és kockázatcsökkentés A piaci fejlemények alapján a biztosabb beruházást jelentı szabványok preferálása. e) Skálázhatóság Olyan megoldások alkalmazása, amelyek nem érzékenyek a tömeges, gyakori igénybevételre. A SAGA önmagára nézve két feladatot állapít meg: a) E-kormányzati normák, szabványok és architektúrák rögzítése, ezáltal a kompatibilitás, ill. interoperabilitás biztosítása. b) Folyamatok és adatok igazgatások közötti egységesítése. Ennek támogatására a KBSt a honlapján e-kormányzati alkalmazások felépítéséhez használható szolgáltatás- és rendszerelemek (Einer-für-Alle- Angebote kb.: egy-mindenkiért ajánlások) leírását közli. Az e-kormányzati alkalmazások számára alapvetı elveket is megfogalmaz: a) Az e-kormányzati alkalmazások a kliens-oldalon ne másra, mint szokásos webböngészıkre támaszkodjanak. b) Tartózkodjanak olyan aktív tartalmaktól, amelyek a falhasználót a böngészıje biztonsági beállításainak leszállítására ösztönöznék vagy legalábbis használjanak aláírt és minıségbiztosított programokat. c) Az e-kormányzati alkalmazások ne helyezzenek olyan programrészeket vagy adatokat a felhasználó számítógépére, amelyek felett annak ne volna ellenırzése. Majd felsorolásra kerülnek a kapcsolódó dokumentumok. Már a második fejezet szól a SAGA alapjairól. A SAGA hatálya a szövetségi közigazgatásra terjed ki, valamint a szövetségi és az alacsonyabb (tartományi vagy települési) szintő hivatalok közötti kapcsolódási felületekre (interfészekre), amennyiben ezek G2C, G2B vagy G2G szolgáltatást támogatnak. BME Informatikai Központ 31

32 Dánia A óta lépésenként elırehaladó dán e-kormányzati keretrendszer kialakulását az jellemzi, hogy egyfajta moduláris építkezést valósítottak meg, ami folyamatosan együtt haladt a közigazgatási reform egyes szakaszaival. Az IT-architektúra a dán kormányzati keretrendszer sarokkövének tekinthetı, melynek elemei: a) Közös koordináció, amelynek intézménye a Nemzeti Vállalatszerő Architektúra Bizottság (National Enterprise Architecture Commity), b) a vállalatszerő architektúrával kapcsolatos folyamatok, koncepciók és szabványleírások közös metodológiája, c) a szabványok és infrastruktúra beleértve a közös referencia profilok (e-gif) használatát és a közös architektúra-elveket közös elvei, d) közös eszközök használata, mint például a szerzıdési modellek együttesen használt adatbázisának és könyvtárának használata, adat-meghatározások, szoftver komponensek és infrastruktúra-minták. A közös közigazgatási szektor architektúra modell szempontjából alapvetınek tartják a szolgáltatás-orientált architektúra (SOA)-modell megválasztását. Ez biztosítja az egy rendszer által szolgáltatásként nyújtott IT rendszer komponens interoperabilitását, amelyet egy másik rendszer kíván használni. A Referencia-profil -nak nevezett keretben felsorolják a kormány által formálisan elfogadott technikai megoldásokat és specifikációkat. A publikálással a közigazgatási szervezetek széles köre számára irányt is akarnak mutatni az új IKT fejlesztések számára. A Referencia-profil a következı területeken nyújt szabványokat: a) felhasználói interface-ek b) dokumentum- és adat-csere c) web-alapú szolgáltatások d) tartalom-menedzsment és meta-adat meghatározás e) adatfeldolgozás f) felhasználó-beazonosítás kezelése g) hálózati és rendszer-fejlesztés h) rendszer-operációk és monitoring Az általános keret-ajánlások kiterjednek a nyílt forráskódú szabványok használatára és a meglévı technológia által biztosított adminisztratív folyamatok átalakítására. A dán gyakorlatra jellemzı legó-rendszer megközelítés abban jelenik meg, hogy pilot-okat indítanak az interoperabilitást szolgáló szabványok és eljárások széleskörő bevezetését megelızıen; a fokozatosság elvében: a közös szabványok és eljárások bevezetésének kezdeti stádiumában nem várták el és nem tartották szükségesnek, hogy az egyes közigazgatási szervezetek teljes rendszerükben vezessék be az újonnan létrehozott közös szabványt. Ehelyett közös értékelés alapján kialakított prioritások meghatározásával alakították ki a megfelelı sorrendet, aminek az alapja az, hogy mely területek fejlesztése gyakorolja a legnagyobb hatást a digitális közigazgatás egészére; A dán gyakorlat egyik specialitása a digitalizálás és szabványosítás mérföldköveinek kijelölése: az ún. E-nap meghirdetése. Ennek nemcsak a közvélemény számára van BME Informatikai Központ 32

33 publicitási haszna és jelentısége, hanem az egyes mérföldkövek kitőzése az intézmények számára is egyfajta rákészülést jelenthet Egyesült Királyság Az elsı e-kormányzati keretrendszer (e-government Interoperability Framework - e-gif) az e-kormányzat stratégia érvénybe lépésével egy idıben, 2000 áprilisában került vitaanyagként meghirdetésre, majd elsı változata 2000 októberében lépett életbe. Az e-gif megjelenése tekinthetı az elsı lépésnek a kormányzati szolgáltatások teljes körő online elérhetıségére irányuló folyamat útján. Az e-gif, mint a nevébıl is következik, csak egy keret, amelyben meghatározzák a kormányzati szervek interoperábilis mőködése biztosításához szükséges irányelveket, a rendszer fejlıdéséhez szükséges kritériumokat, az interoperabilitás szegmenseit, valamint az interoperabilitásnak a többi e-kormányzati kezdeményezéshez főzıdı kapcsolatrendszerét. Külön fejezetek foglalkoznak azzal, hogy a kormányszervek kitıl, milyen segítséget kaphatnak az implementáláshoz, milyen mőszaki- és változásmenedzsment folyamatokat kell végrehajtaniuk, továbbá, hogyan bizonyosodhatnak meg arról, hogy rendszerük megfelel-e az elıírt követelményeknek. Az e-gif a kormányzati intézmények egymás közötti és a külvilággal fennálló kapcsolatait szabályozza. Az egymás közötti kapcsolatokon kívül kiterjed a) a brit kormányszervek és az állampolgárok, b) a brit kormányszervek és a közvetítık (intermediaries), c) a brit kormányszervek és a hazai és külföldi üzleti világ képviselıi, d) a brit kormányszervek és a különféle szervezetek valamint e) a brit kormányszervek és más országok kormányszervei, illetve az EU intézményeiközötti kapcsolatokra. Az e-gif nem standardizálja az információknak a humán interfészeken való megjelenését. Ezeket különféle felhasználói csatornák (pl. internet, nyilvános internet-hozzáférési helyek (public kiosks), digitális TV, mobiltelefonok stb.) biztosítják. Az e-gif csak az adatok és információk eljuttatásának formáját, útját és nem a megjelenítésük formáját standardizálja. A kormányzati hivatalok közötti szuperbiztos kapcsolatot a Kormány Biztonságos Intranet-je (Government Secure Intranet GSI) használata garantálja. A mi EKG-nkhez hasonló kormányzati gerinchálón kívüli kapcsolatok esetében a biztonságot az S/MIME szabvány elıírásaihoz való alkalmazkodás, illetve a biztonságos levéltovábbítás és a levelekhez való biztonságos hozzáférés garantálása végett legalább 128 bit-es TSL/SSL kapcsolatot kell fenntartani. a) A GSI-re csatlakozott intézmények egymás közötti kapcsolataikban a GSI 1/2003 számú Directory Schema-jában található elıírások alapján kapcsolódnak egymáshoz. Ez alól kivételt képeznek azok az esetek, amikor SOAP-on web alapú tranzakciót folytatnak. Ilyenkor az UDDI-t kell használniuk. b) Az intézmények web szolgáltatásainak SOAP-on kell alapulniuk WSDL specifikációval. Web szolgáltatásaik rendszerleíró adatbázisainak (registry) UDDI kompatibiliseknek kell lenniük. c) Az intézményeknek projektjeikben követniük kell az Egyesült Királyság kormánya domain név politikáját. DNS-t kell használniuk az Internet/intranet domain neveik IP címe kialakításához. BME Informatikai Központ 33

34 d) FTP-t kell használni, ha a kormányzati intraneten belül fájltranszferre kerül sor. Az FTP restart és recovery facilitásait kell használni, amikor nagyon nagy fájlok továbbítására kerül sor. e) Amikor csak lehetséges, web alapú technológiát kell használni azoknál az alkalmazásoknál, amelyeknél korábban terminál emulációt használtak. f) A kormányzati rendszerek és a közvetítık (intermediaries) közötti interfészeknek meg kell felelniük az OASIS (Organisation for the Advancement of Structured Information Standards) WS-I kezdeményezésében a web szolgáltatások vonatkozásában elıírt szabványainak. Az egif politikája támogatja az IPv6-ra való migrálást, de biztosítani kell az Ipv4-el való együttmőködés lehetıségét. Azt javasolják az intézmények beszerzési részlegeinek, hogy új beszerzéseiknél lehetıleg törekedjenek IPv6-os hálózati elemek vásárlására, de olyanokéra, amelyek támogatják az IPv4-es megoldásokat is. Az XML alapú termékekhez és szolgáltatásokhoz a W3C XML sémáját kell használni. Az ISO/IEC most dolgozik az új XML sémanyelven (ISO/IEC Cocument Schema Definition Languages DSDL), s várhatóan az e-gif következı változatában már kötelezıként lesz elıírva ennek a használata. A Schematron is várhatóan ki fogja hamarosan egészíteni a W3C XML sémáját, s ez is minden bizonnyal bele fog majd kerülni az új e-gif változatba. A szemantikai interoperabilitás megvalósításához elengedhetetlen fontossággal bír, hogy a közigazgatás minden szintjén és intézményében, továbbá a szakrendszerek képviselıi egységes formában rögzítsék az adatokat. Ennek biztosítását szolgálja a kormányzat adatszabvány katalógusa (UK Government Data Standard Catalogue). Az ebben rögzített szabványok használata valamennyi közintézmény számára kötelezı Írország Az ír e-kormányzat egyik nagyszabású projektje volt a Public Service Broker PSB (közigazgatási szolgáltatás-bróker) létrehozása és kiépítése. A Szociális és Családügyi Minisztériumon belül 1999-ben hozták létre a Reach Ügynökséget, melynek legfıbb feladata az e-kormányzathoz kapcsolódó tevékenységek kidolgozása, végrehajtása lett. Ennek keretében jött létre a közigazgatási szolgáltatás-bróker a Public Service Broker intézménye, mely közvetítıi, segítségnyújtó funkciót tölt be. A PSB alapkoncepciója az volt, hogy egy web-alapú rendszert hozzanak létre, amely integrálja mind a helyi, mind a központi közigazgatás szolgáltatásait, mégpedig egy belépési-ponton ( one-stop ). A PSB elsı verziója szerint a Bróker felhasználói-felület részbıl (Customer Facing Components) és integrációs keretrendszerbıl (Integration Framework) tevıdik össze. Felhasználói-felület (Customer Facing Components) elemei: a) Portál, amely kb kormányzati szolgáltatás listáját és leírását tartalmazza a megfelelı hivatalok és szervek linkjeivel b) ügyfél kormányzat biztonságos belépési pont regisztrált felhasználók számára c) Eset menedzsment komponens, amely biztonsági bejövı ablakot biztosít d) e-nyomtatvány eszköz, e) Biztonsági, ellenırzési és naplózási szolgáltatások f) e-fizetés a Bróker rendelkezik egy biztonságos fizetési lehetıséggel (RealX), amely lehetıvé teszi a felhasználók számára, hogy az állami hivataloknak és irodáknak hitelkártyával fizessenek. BME Informatikai Központ 34

35 Integrációs Keretrendszer (Integration Framework): a) Alapvetı szolgáltatások (Broker Core Services): aa) a szolgáltatásokhoz való hozzáférés irányítása a Brókeren keresztül, ab) adminisztrációs szolgáltatások nyújtása a Bróker számára b) Reach Interoperabilitási, Biztonsági és Integrációs Szabványok (Reach Interoperability, Security and Integration Standards - RIGS): útmutatók és szabványok üzenet-átvitelhez. A kormányzat és a magánszektor szolgáltatói számára közzétett anyag, amely részletezi, hogy az üzeneteknek milyen formátumban kell megjelenniük ahhoz, hogy a Brókerrel képesek legyenek kommunikálni. A PSB más kormányhivatalokkal és szervekkel együttmőködve megfogalmazta az Interoperabilitási szabványokat és útmutatásokat. A következı területeken történt megállapodás: a) Ügyféladatok adatvédelem, használat, adatgyőjtés és ellenırzés b) Biztonsági és belépés-ellenırzési elvek c) Ügyfél szolgáltatási elvek és szabványok beleértve a szolgáltatások továbbítását más ügynökségeknek, szervezeteknek d) A Bróker általános szolgáltatásainak használata és a technikai követelmények leírása e) A szolgáltatásokra vonatkozó információk szállítása f) Szolgáltatás és Adatcsere Katalógus (SDEC Services Data Exchange Catalogue): tárház vagy tároló terület a RIGS számára. Minden a Brókeren keresztül történı kommunikáció XML elektronikus üzenetekkel történik. Az interoperabilitás biztosítására a Bróker szabványos üzenet-szerkezeteket és jelenéseket definiál. A közigazgatásban a számítógépes rendszerek igen nagy variációja található meg. Az interoperabilitás lehetıvé teszi, hogy ezek a különbözı számítógépes rendszerek és hálózatok egymással kommunikálni tudjanak, és együtt tudjanak dolgozni. Jelenleg az ír közszektorban az interoperabilitás terén számos jelentıs fejlesztés és munkafolyamat figyelhetı meg. Az összes állami szerv összekapcsolható a Kormányzati Virtuális Magánhálózat (Government Private Virtual Network) (GVPN) segítségével. A GVPN egyetlen egységes platformot biztosít a szervek számára az internet biztonságos eléréséhez, ek elküldéséhez stb. A Reach kifejlesztette az Inter-Agency Messaging Service (IAMS)-t, megbízható központosított üzenetszolgálatot, amely a GVPN-en bonyolítja az ügyféllel kapcsolatos információk cseréjét a szervek között. A Bróker egy szolgáltatás-központú architektúrára (SOA) épül. A Public Services Broker (PSB) kiváló gyakorlati megközelítése és megvalósítása a Service Oriented Architecture (SOA)-nak, az EU ajánlásai alapján (Web Services, XML, Üzenetkezelés). A projekt az elektronikus kormányzati infrastruktúrához illeszkedı elektronikus rendszerek, folyamatok, és eljárások integrációját valósítja meg. A mőködés üzeneteken alapul, melyekre garantálják a címzetthez történı biztos eljuttatást, de nem garantálják az azonnali feldolgozást. Az egyes üzeneteket generálhatják személyek, például egy portál felületen keresztül vagy szolgáltatások. Közös jellemzıjük, hogy szabványos, XML formátumban tárolódnak a rendszerben. A közremőködı szolgáltatások megfelelı idıközönként figyelik, hogy van-e számukra feladott üzenet, és szükség szerint kezelik azt. A szolgáltatás-alapú megközelítés megvalósítja a laza csatolást, a helyszín- és protokoll független mőködést. A szolgáltatásokat BME Informatikai Központ 35

36 a rendszerek együttmőködéséhez elegendı szabványos, szabályozott eszközökkel írják le és publikálják, magát a szolgáltatás implementálását az egyes szervezetek saját hatáskörükben tartják. Ez egyben a teljes interoperabilitási rendszer rugalmasságát is adja, hiszen bármely belsı változtatáskor, új rendszerek beüzemelésekor a kapcsolódási felületek változatlanok maradhatnak, csak a szolgáltatás megvalósítási módja változik. Mindez lehetıvé teszi azt, hogy különbözı gyártóktól származó szoftvermegoldások az elvárásoknak megfelelıen kommunikáljanak egymással A szolgáltatás-orientált architektúra bemutatása Bevezetés Ez a fejezet a szolgáltatás-orientált architektúra (Service Oriented Architecture, SOA) legfontosabb alapelveit mutatja be, majd ennek egy konkrét megvalósítását, a webszolgáltatásokat ismerteti. Összefoglalja a legfontosabb WS-* szabványok feladatát és mőködését, végül megmutatja, hogy az üzleti folyamatok leírására alkalmas Business Process Execution Language (BPEL) hogyan viszonyul ezekhez. A BPEL és a legtöbb WS-* szabvány egy a szoftvergyártók szövetségén alapuló szervezet, az OASIS (Organization for the Advancement of Structured Information Standards) [15] gondozásában vannak. A CORBA és a DCOM a web-szolgáltatások elıdeinek tekinthetık, hasonló feladatok megoldására jöttek létre, használatuk azonban túl nehézkes, illetve a különbözı gyártók termékei között nem minden problémára létezik szabványos megoldás (biztonságos adatátvitel, tranzakció-kezelés, tőzfalak kérdése stb.). Jelenleg az XML alapú webszolgáltatások alkalmasnak látszanak a fenti problémák megoldására [49] A szolgáltatás-orientált architektúra fogalma Ez a szakasz a SOA referencia modell [16] alapján a Szolgáltatás-Orientált Architektúra alapelveit foglalja össze. Az OASIS definíció szerint a SOA egy paradigma különbözı érdekeltségek hatáskörében álló elosztott erıforrások és képességek szervezésére és hasznosítására. Definiálja az erıforrások és képességek egységes módon történı felkínálását, felderítését, együttmőködését és felhasználását annak érdekében, hogy ellenırizhetı elıfeltételeknek és elvárásoknak megfelelı eredményt, hatást érjünk el. Az emberek és szervezetek általában különbözı képességeket biztosítanak a mindennapi üzleti életben elıforduló problémák megoldására vagy a megoldás támogatására. Természetesnek tőnik az a gondolat, hogy az igények találkoznak ezekkel a képességekkel, azonban nem feltétlenül létezik egy kölcsönös megfeleltetés közöttük: egy adott igény kielégítése több képesség kombinálását teheti szükségessé, valamint egy képesség több igényt is kiszolgálhat. A SOA legfıbb értéke abban rejlik, hogy egységes keretrendszert biztosít az igények és képességek megfeleltetéséhez, illetve az igények kielégítéséhez szükséges képességek kombinálásához. A SOA paradigma leírásának kulcsfogalmai a láthatóság, az együttmőködés és a kívánt hatás elérése. BME Informatikai Központ 36

37 A láthatóság arra vonatkozik, hogy akik szolgáltatnak és akik igényekkel lépnek fel, láthassák egymást, tudjanak egymásról. Ez tipikusan a funkcionális és technikai követelmények, a kényszerek és policy-k, valamint a kérés és a válasz mechanizmusainak leírását jelenti. A leírásoknak olyan formátumúnak (vagy olyanná konvertálhatónak) kell lennie, hogy szintaktikájuk és szemantikájuk széles körben elérhetı és megérthetı legyen. Az együttmőködés az a tevékenység, amely során egy képességet használunk. Az együttmőködés során tipikusan üzenetek átvitelével információk cserélıdnek és tevékenységek hajtódnak végre. Az együttmőködésnek több fajtája lehet, de mindegyik egy végrehajtási környezet része, amely a képességekkel és igényekkel rendelkezık közötti technikai és üzleti elemek összességét jelenti. Ez teszi lehetıvé a szolgáltatásokat biztosítók és felhasználók közti interakciót, ezen kívül döntési pontként szolgál a policy-k és szerzıdések számára. A képességek használatának célja valamilyen kívánt hatás elérése. Ez a hatás információt szolgáltathat vagy egy tevékenység végrehajtásán keresztül megváltoztathatja az együttmőködésben résztvevık állapotát. Fontos megkülönböztetni nyilvános- és magántevékenységeket. A magántevékenységek más szereplık számára ismeretlenek, ezzel szemben a nyilvános tevékenységek a végrehajtási környezetben résztvevık (esetleg más szereplık) állapotának megváltozását eredményezhetik. A hatás ebben az esetben tehát a szereplık között megosztott állapot megváltozása. Az elvárt hatások leírása alapján lehet eldönteni, hogy egy képesség megfelel-e egy hasonló módon leírt igénynek. Az együttmőködés során a hatások eredménye találkozik azoknak az elvárásaival, akik a képességet igénybe veszik. Azonban figyelembe kell venni, hogy nem lehet minden hatást leírni, amely egy képesség használatának eredményeként elıáll. A SOA egyik kulcsfontosságú elve, hogy a képességek felhasználhatók anélkül, hogy az összes hatás részleteirıl tudomásunk lenne. A SOA központi fogalma a szolgáltatás. Hétköznapi értelemben a szolgáltatás egy szereplı által egy másik szereplı számára végrehajtott munkát jelenti. A szolgáltatás azonban a következıket is magába foglalja: a képesség más számára való munkavégzésre a végrehajtandó munkatevékenység leírása hajlandóság a munka végrehajtására és ennek felkínálása Ezek a pontok kihangsúlyozzák a különbséget a képesség megléte és annak végrehajtása között. Habár az igények és a képességek a SOA-tól függetlenül is léteznek, a SOA-n belül a szolgáltatások azok, amik ezeket az igényeket és képességeket összehozzák egymással. A SOA a megoldások rendszerezését oly módon támogatja, hogy egyszersmind elısegíti az újrahasznosíthatóságot, a bıvíthetıséget és az interoperabilitást. Külön megjegyzendı, hogy ugyan a SOA hozza össze a képességeket és az igényeket, de az a szereplı, aki a képességet biztosítja, nem feltétlenül ugyanaz, mint aki a a képesség eléréséhez szükséges szolgáltatást rendelkezésre bocsátja. Aki a megfelelı szakértelemmel rendelkezik a képesség létrehozásához és karbantartásához, nem feltétlenül rendelkezik a szükséges szakértelemmel a hozzáférést biztosító szolgáltatás elkészítéséhez és karbantartásához. A már említett fogalmak (láthatóság, együttmőködés, kívánt hatás elérése) ugyanúgy vonatkoznak a szolgáltatásokra, ahogy azok korábban az általános SOA paradigma jellemzıinél szerepeltek. A láthatóságot a szolgáltatás-leíró biztosítja, amely tartalmazza az együttmőködéshez szükséges információkat leírva a bemeneteket, a kimeneteket és a szemantikát. A szolgáltatás-leíró megadja a szolgáltatás használatához szükséges elıfeltételeket és azt is, hogy milyen hatást vált ki a szolgáltatás használata. BME Informatikai Központ 37

38 Általában a szereplık képességeket ajánlanak fel másoknak, ık a szolgáltatások üzemeltetıi. Azok, akik igényekkel lépnek fel és használják a szolgáltatásokat a szolgáltatások felhasználói. A szolgáltatás leírója alapján a leendı felhasználók eldönthetik, hogy az adott szolgáltatás megfelel-e az aktuális igényeiknek, illetve megállapítható az is, hogy a felhasználó kielégíti-e az üzemeltetı által megkívánt elıfeltételeket. Az üzemeltetıket és a felhasználókat összefoglaló néven résztvevıknek nevezzük. Ez a leírás ugyan absztraktnak tőnhet, de talán ez ragadja meg legjobban a SOA lényegét. Az implementációs részletekkel megtőzdelt SOA definíciók gyakran elfedik az itt megfogalmazott alapelveket. A web-szolgáltatások is a SOA egy megvalósításának tekinthetık. A web-szolgáltatások olyan szolgáltatások, amelyek SOAP [19] hívásokon keresztül érhetık el. A webszolgáltatásokra épülı architektúrák és technológiák specifikusak és konkrétak, azonban az itt megfogalmazott elvek rájuk is érvényesek. SOA pedig létezhet web-szolgáltatások nélkül is A szolgáltatás-orientált architektúra megvalósításának generációi A SOA paradigma gyakorlatban történı megvalósításának hosszú folyamata még ma sem tekinthetı lezártnak. Egymást követték az egyes megvalósítások, amelyek javítottak a korábbiak hiányosságain és egyben újabb problémákra hívták fel a figyelmet. Fejlıdésüket vizsgálva három generációt azonosítottunk, melyek a következık: web-szolgáltatás megvalósítások, SOA megvalósítások, ESB (Enterprise Service Bus) megvalósítások. A szolgáltatás nyújtás és igénylés elvei már az objektum-orientált szemléletben is kiemelt jelentıséget kapnak. Ennek megvalósítására készült megoldások fejlıdése jól követhetı. Kezdetben az objektumok szolgáltatásai csak egyazon alkalmazás keretein belül voltak elérhetık, majd egyazon számítógép azonos nyelven írt alkalmazásai között, késıbb több számítógép azonos programozási nyelven írt alkalmazási között (pl. RMI, Remoting segítségével), végül a különbözı számítógépek különbözı programnyelvei között is lehetıvé váltak (pl. CORBA, WS segítségével). Az utolsó lépés megvalósításában volt döntı jelentısége a web-szolgáltatások megjelenésének és gyakorlatban történı alkalmazásának. Ezt az idıszakot a SOA elsı generációjának tekintjük. A fontosabb programozási környezetekben/nyelvekben kialakították a web-szolgáltatások támogatásához szükséges APIkat. A programozók elsajátították web-szolgáltatások használatához szükséges API-k, és szabványok (SOAP, WSDL, XSD, XML, XSLT, stb.) használatát. Rövid idın belül nagy számban jelentek meg web-szolgáltatások a vállalatok informatikai rendszereiben. A szolgáltatás-orientált szemlélet gyakorlatban történı alkalmazása ezzel bizonyos tekintetben megvalósult. A használat során több olyan probléma került elıtérbe, amelyek egységes megoldására újabb WS szabványok kerültek kidolgozásra, ezek a WS-* szabványok (tranzakciók, biztonság, megbízhatóság, stb. támogatására). Ezek alkalmazása folyamatosan megy át a gyakorlatba. Az elsı generációs megvalósítások problémáit a tervezés- és szervezésbeli hiányosságok okozták. A nagy számban megjelenı web-szolgáltatások funkcióikban sok esetben átfedték egymást, használt adatstruktúráikban eltértek egymástól, ezért összekapcsolásuk köztes megoldásokat igényelt. Problémát jelentett, hogy nem lehetett megtudni, hogy egészen pontosan milyen web-szolgáltatások, milyen funkcionalitással kerültek már megvalósításra, illetve a web-szolgáltatások, hol és hogyan érhetık el. A web-szolgáltatások kialakítása nem volt központilag tervezve és irányítva. A második generációs SOA megvalósítások nem technológiában, hanem szervezésben jelentettek elsısorban elırelépést. Konzisztens objektumrendszerek használata vált gyakorlattá. A szolgáltatások magas szintő tervezéssel, BME Informatikai Központ 38

39 egymásra építve, hosszú távú tervek figyelembe vételével kerültek kialakításra. A használatban lévı adatstruktúrák és szolgáltatások felderítésére és megismerésére katalógusok lettek kialakítva (pl. UDDI). A harmadik generációnak az ESB (Enterprise Service Bus) megvalósításokat tekintjük. (Az ESB elveit többen a SOA szemlélet továbbvitelének mondják.) Alapvetıen a szolgáltatások menedzsmentjét erısíti a korábbi generációkhoz képest. A szolgáltatások meghirdetéséhez, használatához újabb szabályozásokat vezet be. Támogatja a szolgáltatások monitorozását, mérését, auditálását, naplózását. Az ESB megoldásokat biztosít a folyamatvezérléshez, optimalizáláshoz, eseménykezeléshez, üzenettranszformáláshoz. Egyes megvalósításai funkcióikban jelenleg még nagyon eltérnek egymástól. Az ESB-nek (Enterprise Service Bus) jelenleg nincs mindenki által elfogadott definíciója. A gyártók gyakran saját ESB implementációjuk funkcionalitásait felsorolva határozzák meg a fogalom jelentését. Véleményünk szerint jobb megközelítés lenne egy absztrakt Service Busról beszélni, amely a már ismertetett végrehajtási környezetet jelenti: továbbítja az üzeneteket, segíti a szolgáltatások leíróinak megadását, a szolgáltatások felkínálását és felderítését. Mi a következıképpen határozzuk meg az ESB definícióját: az ESB a végrehajtási környezet egy konkrét megvalósítása, amely egy adott alkalmazási terület szereplıit köti össze. Az alkalmazási terület lehet például egy vállalat, az egészségügy vagy akár a közigazgatás is. Egy ESB nem feltétlenül egy vállalaton belülre korlátozódik, kiterjedését befolyásolhatják többek között a tőzfalak és a földrajzi határok is (pl. egy vállalat különbözı országokban lévı leányvállalatai rendelkezhetnek saját ESB-vel; egy ország egészségügyi intézményei csatlakozhatnak egyetlen közös ESB-re) Web-szolgáltatás szabványok Ez a szakasz a fontosabb WS-* szabványokat (3. ábra) ismerteti M. L. Bustamante összefoglalója [17] és a WSIT Tutorial [39] alapján. Az innoq weblapján [18] egy nagyon jó áttekintı poszter található, amely összesíti a szabványok verzióit, jelöli a elsı negyedévi állapotukat (szabvány, specifikáció, ajánlás, stb.) és megadja azt is, melyik szabványosító testület (OASIS, W3C, WS-I, IETF) gondozásában vannak. BME Informatikai Központ 39

40 SOAP és WSDL 3. ábra - A fontosabb WS szabványok A SOAP (Simple Object Access Protocol) [19] azt specifikálja, milyen XML formátumú üzenetek használatával lehet egymással együttmőködı alkalmazásokat készíteni. Megadja, hova kerüljenek a fejlécek, hova a tartalom és milyen módon kell jelölni a végrehajtandó mőveletet (action). Ezeket kell tudnia értelmezni egy alkalmazásnak, amely SOAP üzeneteket dolgoz fel. A SOAP azonban csak ezt a keretet biztosítja, ezen felül az alkalmazás feladata a konkrét fejlécek és a tartalom elıállítása és értelmezése. Ennek leírásában segít a WSDL (Web- Services Description Language) [20]. A WSDL adja meg a felhasznált típusokat XSD-ben (types), a különbözı operációk be- és kimeneti paraméterlistáját (message), az interfészeket (porttype) és operációikat (operation). Eddig tart a WSDL absztrakt része, amely független a használt protokolloktól. A WSDL konkrét része írja le a hívási konvenciókat (binding) és a szolgáltatások konkrét címeit (service). Egy operáció lehet szinkron vagy aszinkron. Szinkron operáció bemenettel (input) és kimenettel (output) is rendelkezik, aszinkron operációnak azonban csak bemenete van. A szabvány szerint lehetıség van csak kimenettel rendelkezı ún. értesítı (notification) operációk definiálására is, de ezek használatára ritkán van szükség, hiszen helyettesíthetık kliensoldali aszinkron szolgáltatásokkal. Szinkron operációt akkor érdemes készíteni, ha a választ azonnal vissza tudja adni a szolgáltatás. Hosszú lefolyású mőveletek esetén a kliens blokkolódását elkerülendı az aszinkron változatot célszerő használni, ahol a szerver a mővelet befejezıdésekor a kliensoldalon futó call-back szolgáltatást hívja vissza (általában szintén aszinkron módon). BME Informatikai Központ 40

41 Egy operációnál a Java-ban ismert checked exception-ökhöz hasonlóan lehetıség van annak definiálására is, hogy a mővelet milyen hibaüzeneteket (fault) dobhat. Ezek SOAP fault formájában jutnak el a hívó félhez, ahol általában kivétellé traszformálódnak. A WSDL 2.0-ás verziójában csökkentették a redundanciát: eltőnt a message rész. A porttype-ot átnevezték interface-re, amely jobban követi a hagyományos programnyelvi értelmezést, a paraméterlistát pedig az operation-ökön belül kell megadni; ezáltal tisztább lett a leírás. Mivel azonban az új verzió még csak a szabványosítás ajánlási fázisában van, a legtöbb eszköz még mindig a WSDL 1.1-es verzióját használja WS-* szabványok A SOAP tehát nem definiálja az üzenetek tényleges tartalmát, ezt az alkalmazásnak kell meghatároznia. Azonban a legtöbb alkalmazás ugyanazokkal a feladatokkal szembesül: meg kell oldani a címzést, a biztonsági és megbízhatósági kérdéseket, a nagyobb üzenetek hatékonyabb átvitelét. Ebben segítenek a WS-* szabványok, amelyek ezekre a problémákra adnak szabványos megoldást. A WS-* szabványok egy az ipar által is széleskörően támogatott folyamatosan bıvülı protokollhalmazt takarnak. Céljuk, hogy megoldást adjanak az üzenetek cseréje során felmerülı általános problémákra. A következıkben ezek áttekintésére kerül sor Transzport protokollok A transzportréteg felelıs az üzenetek közvetlen továbbításáért. Ez lehet HTTP, HTTPS, SMTP, vagy bármi egyéb, ha azt az adott eszköz támogatja. Azonban szabványos WSDL binding csak HTTP-re (HTTPS-re) létezik, így az interoperabilitáshoz ezt célszerő használni XML szabványok Az összes WS-* szabvány XML-en alapul, így az XML és XSD elengedhetetlenek használatukhoz. Bár ez nem lenne szükséges, a legtöbb használt névtér prefixe általában egységes (még gyártók között is), így könnyebb a hozzátartozó elemek azonosítása. A biztonsággal kapcsolatos protokollok erısen építenek az XML-féle digitális aláírásra és titkosításra. A WS-Security protokollok tehát a már meglévı szabványokon alapulnak, és nem vezetnek be újfajta aláíró és titkosító módszereket Üzenetkezeléssel kapcsolatos protokollok A SOAP adja az üzenetek vázát. Jelenleg két verziója (1.1 és 1.2) létezik, mindkettıt már szinte mindegyik eszköz támogatja. A címzéssel és útvonalválasztással kapcsolatos elemeket a WS-Addressing üzenetszintre emeli, ezáltal ezek függetlenné válnak az alkalmazott transzportrétegtıl. A legtöbb protokoll erısen épít a WS-Addressing-re: sokszor egyetlen üzenet küldése több másik üzenet cseréjét vagy egy másik szolgáltatáshoz való dinamikus átirányítást von maga után. Az MTOM (Message Transmission Optimization Mechanism) azt írja le, hogyan lehet bináris adatot hatékonyan továbbítani egy SOAP üzenet részeként. A cél az, hogy a méretbeli és sebességbeli overhead-del járó BASE64 kódolást mellızni lehessen. Mindezt MIME BME Informatikai Központ 41

42 kódolás segítségével éri el: a bináris adat külön MIME-részként adódik az üzenethez, a SOAP XML-bıl pedig csak egy referencia hivatkozik rá Biztonsági protokollok A biztonsági protokollok azok közé a protokollok közé tartoznak, amelyek elsıként váltak stabillá a gyártók között. Elıször a hitelesítést oldották meg, majd késıbb kialakultak az aláírást, titkosítást és felhatalmazást segítı szabványok. Az üzenetek védelme céljából azokat digitálisan alá kell írni és titkosítani kell. Ez megoldható transzport- és üzenetszinten is. Mivel az elıbbi csak pont-pont kapcsolaton keresztül biztosít védelmet, inkább az utóbbi használata javasolt, amely transzportrétegtıl függetlenül akár több köztes szereplı esetén is védelmet nyújt. Ha elıfordulhat, hogy az üzenet továbbítása során az nem megbízható szereplıkön is áthalad, akkor mindenképpen az üzenetszintő megoldás javasolt. A WS-Security szabvány az üzenet egyes részeinek aláírásáért és titkosításáért, valamint a hitelesítı tokenek biztonságos átviteléért felelıs. Több tokenfajta is létezik, köztük a UserName Token Profile, az X.509 Token Profile, a Kerberos Token Profile és az SAML Token Profile. Ezek definiálják azt, hogy az egyes hitelesítési információkat milyen módon kell szerializálni. A UserName Token felhasználónév-jelszavas hitelesítést tesz lehetıvé. Az adatok titkosítását lehet transzport- és üzenetszinten is végezni. Az X.509 Token tanúsítványok alapján hitelesít. A Kerberos Token tipikusan belsı hálózaton, tőzfal mögött használatos. Az SAML Token a különbözı felügyelet alatt álló domének közti hitelesítést oldja meg (ld. késıbb a WS-Trust és WS-Federation). Sok üzenetváltásnál teljesítményszempontból kedvezıtlen az, ha minden egyes webszolgáltatás hívást hitelesítési információkkal kell ellátni és azokat minden hívásnál ellenırizni kell. Az aszimmetrikus kulcsok használata további teljesítményromlást eredményez. A WS-SecureConversation ezen a problémán segít az SSL-éhez hasonló elvek alkalmazásával. A két egymással kommunikáló szereplı egy SCT-t (Security Context Token) beszélnek meg, ezt használják a késıbbi üzenetváltásoknál hitelesítésre. A kommunikáció ideje alatt egy session-t tartanak fenn, amely során azonosíthatók az adott kapcsolaton át kicserélt üzenetek. A titkosítást a kapcsolat felépítésekor aszimmetrikus kulcsok segítségével megbeszélt szimmetrikus kulcs alapján végzik, ezáltal az sokkal hatékonyabbá válik. A WS-Trust protokoll biztonsági tokenek kibocsátásáért, megújításáért és cseréjéért felelıs. A WS-SecureConversation is ezt használja az SCT létrehozására. A doméneken átívelı modellben a WS-Trust alapján lehet a hozzáféréseket szabályozni akár a jogosultságok átruházásával is. A tokeneket egy STS (Security Token Service) bocsátja ki, leggyakrabban SAML (Security Assertion Markup Language) [22] formátumban, melynek segítségével könnyen azonosítható a hívó, és leírhatók a hozzáférési jogosultságai is. A WS-Trust a Kerberos elvén alapul, azonban az SAML tokenek jóval finomabb felbontást tesznek lehetıvé a jogosultságok meghatározásánál. A Channel9-on egy nagyon jó összefoglaló videó található a WS-Trust mőködésérıl [23]. A WS-Federation a WS-Security, WS-SecureConversation és WS-Trust szabványokra építve különbözı fennhatóság alatt álló domének között biztosít azonosítási és single-sign-on megoldást. Hasonló feladatot lát el, mint az SAML 2.0, de figyelembe veszi a többi WS-* protokollt is, például a megbízhatósági és tranzakciós protokollokat. BME Informatikai Központ 42

43 Megbízhatósági protokollok A megbízhatósági protokollok feladata, hogy növeljék az alkalmazások megbízhatóságát az esetleges hálózati problémák esetén. Garantálható az, hogy az üzenetek pontosan egyszer továbbítódjanak és az is, hogy megırizzék sorrendjüket. Mindez nincs egy adott protokollhoz kötve, minden üzenetszinten mőködik, akár több közbülsı szereplın át is. Mindkét kommunikáló fél egy megbízható session részeként egy-egy puffert tart fenn a még nem nyugtázott kimenı és beérkezı üzenetek számára. A nem nyugtázott üzenetek újra lesznek küldve, de maximum a konfigurációban beállított számú újrapróbálkozás történik. A WS-Reliability protokollt viszonylag hamar elfogadták, még jóval a többi szabvány elıtt, ennek következtében nem veszi figyelembe a többi biztonsági és tranzakciós protokollt. A WS-ReliableMessaging már a többi protokollra is tekintettel van, és széleskörő ipari támogatással rendelkezik. Jelenleg is dolgoznak azon, hogy a két szabványt összevonják Tranzakciók A WS-Coordination, WS-AtomicTransaction és WS-BusinessActivity protokollok a webszolgáltatások közötti tranzakciók megoldását segítik. A WS-Coordination a tranzakció levezénylését végzi, ennek segítségével regisztrálhatják magukat a résztvevık. A WS- AtomicTransaction rövidtávú tranzakciókat támogat, kétfázisú commit-tal (2PC). A WS- BusinessActivity hosszútávú tranzakciók számára lett kialakítva, ahol a rollback kompenzációt igényel Metaadatok A szolgáltatások operációinak, az üzenetek formátumának és a felhasznált WS-* protokolloknak az egységes leírása nagyban megkönnyítheti az együttmőködést. Ezek alapján az eszközök automatikusan elıállíthatják a szükséges beállításokat leegyszerősítve a konfigurálást. A WSDL a szolgáltatások operációit és üzeneteit írja le WS-* szabványok nélkül. A WS- Policy protokollcsalád a WS-* szabványok számára biztosít leírást közvetlenül vagy közvetve (WS-PolicyAttachment) kibıvítve a WSDL-t. Vannak policy megoldások a biztonsági (WS- SecurityPolicy), megbízhatósági (WS-ReliableMessaging Policy) és tranzakciós (WS- AtomicTransaction Policy) protokollokra is, sıt a kör bıvíthetı az esetleges saját protokollok számára is, mivel a WS-Policy szabvány úgy lett kialakítva, hogy könnyen kiterjeszthetı legyen. A WS-MetadataExchange a WSDL-ek, a WS-Policy beállítások és az üzenetformátumok feltérképezését támogatja. Segítségével az eszközök felderíthetik a követelményeket, lekérdezhetik a WSDL egyes részeit (pl. policy vagy operation rész), ezáltal lehetıség nyílik a proxy-k és a konfigurációs fájlok automatikus generálására Business Process Execution Language (BPEL) Ez a szakasz a BPEL fıbb tulajdonságait ismerteti a szabvány [24] és M. B. Juric könyve alapján [25]. A BPEL az üzleti folyamatok leírására szolgáló szabványos programnyelv, BME Informatikai Központ 43

44 amely egyben végrehajtható is, ezáltal a folyamatok automatizálhatók. A BPEL webszolgáltatásokat használ, a külvilág számára pedig maga is web-szolgáltatásként jelenik meg. A BPEL hasonlít a hagyományos programnyelvekhez: tartalmaz ciklusokat, elágazásokat, változókat és értékadásokat, azonban kifejezıereje eléggé korlátozott. Ennek köszönhetıen könnyő megtanulni, de bonyolultabb feltételek megadására, összetettebb számítások vagy algoritmusok megvalósítására nem alkalmas. Ezeket a feladatokat célszerő egy külön webszolgáltatáson keresztül hagyományos programnyelven megvalósítani, majd a BPEL folyamatból az adott szolgáltatást meghívni. A BPEL legfontosabb feladata a web-szolgáltatások összekötésével a kívánt üzleti folyamat megvalósítása. Ennek köszönhetıen a BPEL leglényegesebb elemei web-szolgáltatások eléréséhez kapcsolódnak. Lehetıség van szinkron és aszinkron hívásokra, az aszinkron válaszokra való várakozásra és time-out definiálására is. Támogatja a hibakezelést, a hosszútávú tranzakciók visszavonását pedig kompenzáció segíti. (Bár ez nem feltétlenül jelent megoldást a tranzakciós problémákra, hiszen elıfordulhat, hogy maga a kompenzáció sem sikerül.) Lehetıség van a tevékenységek soros és párhuzamos végrehajtására, de a folyamat reagálhat kívülrıl érkezı eseményekre is. A BPEL-nek jelenleg két verziója (1.1 és 2.0) használatos, azonban egyik sem veszi figyelembe a WS-* szabványokat. Mindkét verzió a WSDL 1.1-re épül, de az operációk neveinek túlterhelése és a csak output-tal rendelkezı operációk nem megengedettek. A WSDL 2.0 és a többi WS-* szabvány nem támogatott. A BPEL specifikáció indoklása szerint a BPEL szabványosításának pillanatában ezek nem voltak véglegesítve, így a BPEL-be sem épültek be. A BPEL valójában csak a WSDL absztrakt részére épül, így független a legtöbb szabványtól. A BPEL futtatórendszer feladata a konkrét protokollok megfelelı kezelése. Azonban a WS- Addressing támogatás hiánya eléggé kényelmetlenné teszi a BPEL-en belüli címzést. Néhány eszköz biztosít bıvítményeket, amellyel a probléma orvosolható, de ezek használatával a folyamat leírása elveszíti szabványos és portolható voltát Szolgáltatási láncok A közigazgatási sín szolgáltatásokat kapcsol össze. Egy összetett ügy végrehajtásához szolgáltatások láncolatára van szükség. Ugyanazon ügy kiszolgálása több különbözı szolgáltatáslánc megvalósulásával is történhet. Hogy melyik (egy vagy több) szolgáltatáslánc lesz megvalósítva a gyakorlatban, az több tényezıtıl is függhet. Elsısorban az adott közigazgatási eljárásra vonatkozó jogszabályok és a bevett gyakorlat fogja meghatározni. Amennyiben lehetséges alternatívák között választani, akkor annak az architektúrával való kapcsolatát érdemes figyelembe venni. A következıkben egy példa kapcsán bemutatjuk, hogy a választás milyen elınyökkel/hátrányokkal jár. Példa: Az ügyfél az APEH és a VPOP együttes nullás igazolását kéri. Az alábbi egyszerősítı feltételeket tesszük: a) A lépések végrehajtásának sorrendje tetszıleges lehet. b) Az ügyfél az ügyfélkapun keresztül hitelesen bejelentkezett, a szolgáltatás igénybevételére jogosult. Az ügyfélkapun történı bejelentkeztetést nem részletezzük. Lényegtelen, hogy az ügyfélkapu folyamatai hol zajlanak le, történhet akár a KR-en is. c) Minden szolgáltatáskéréshez a kérelmezı megfelelı tanúsítványa csatolva van, a szolgáltató jogosult, sıt köteles a szolgáltatást elvégezni. d) A dupla 0-s igazolás szolgáltatás megvalósításáért a KR felelıs. BME Informatikai Központ 44

45 e) Az ügyfél megfelel a feltételeknek, neki az igazolást ki kell adni. Az események sorrendjét UML2 szekvenciadiagramon ábrázoljuk Elsı változat 4. ábra 1: Az ügyfél nevében az ügyfélkapu a KR-en elindítja a dupla 0-s igazolás kéréssel az azt kiszolgáló cselekményt. A kérés paraméterként megkapja az ügyfél adóazonosítóját. Az elindított cselekmény készít egy igazolást az ügyfél adataival, majd 2: a cselekmény tudja, hogy elıször kérni kell az APEH-tıl a 0-s igazolás_1 szolgáltatást, paraméterként megadva az ügyfél adóazonosítóját. Az APEH-nél a kérést kiszolgáló cselekmény ellenırzi az ügyfél állapotát. Ez a szolgáltatás mindössze annyit tud, és azért felelıs, hogy az APEH adminisztráció szerinti státuszt visszajelezze. A szolgáltatásnak nem kell tudnia, hogy mi is volt az ügyfél eredeti kérése. 3: Az APEH a KR APEHOK szolgáltatásának meghívásával jelzi, hogy az APEH szempontjából az ügyfél rendben van. A szolgáltatást megvalósító cselekmény megkapja az APEH válaszát, amit a megfelelı helyre az igazoláson bejegyez. A KR-en indított cselekmény folytatódik, és 4: a KR a VPOP-tól is kéri a 0-s igazolás_1 szolgáltatást, az adóazonosítóval paraméterezve. A VPOP-nál is hasonló a kérés kiszolgálása, mint az APEH-nél. A VPOP 0-s igazolás_1 szolgáltatásának szintén nem kell tudnia, hogy mi volt az ügyfél eredeti kérése, vagy azt, hogy az ügyfél az APEH vizsgálaton megfelelt. 5: VPOP válaszként visszahívja az ügyfélkapu vámok szolgáltatását, jelezve hogy az ügyfél a VPOP-nál tiszta. Az APEH válaszának kezelésével megegyezı módon a cselekmény a VPOP válaszát bejegyzi az igazolásra, és 6: kéri a szintén a KR felelısségi körébe tartozó igazolást tedd a tárba szolgáltatást, paraméterként átadva az igazolást. 7: Valamikor késıbb az ügyfél az ügyfélkapun indított kéréssel veszi át a tárból az igazolást. adóvám_1 KR APEH VPOP Ügyfél 1: dupla 0-s igazolást(adóaz) 2: 0-s igazolást_1(adóaz) 3: APEHOK 5: vámok 4: 0-s igazolást_1(adóaz) 6: igazolást tedd a tárba(igazolás) 7: kérem az igazolást 4. ábra - Központi vezérlés BME Informatikai Központ 45

46 Második változat 5. ábra 1: Az ügyfél nevében az ügyfélkapu a KR-en elindítja a dupla 0-s igazolás kéréssel az azt kiszolgáló cselekményt. A kérés paraméterként megkapja az ügyfél adóazonosítóját. Az elindított cselekmény készít egy igazolást az ügyfél adataival, majd 2: ezt az igazolást a 0-s igazolás_2 szolgáltatás kéréséhez paraméterként csatolja. Az APEH a paraméterként kapott igazolásból kivett adóazonosító alapján ellenırzi az ügyfél állapotát. Megállapítja, hogy részérıl az igazolás kiadható, azt feljegyzi az igazolásra (aláírja), majd az igazolást átvizsgálva megállapítja, hogy azt még a VPOP-nak is látnia kell. Ezért 3: az APEH a félig kész igazolást paraméterként megadva az engedélyezési eljárást folytatva a 0-s igazolás_2 szolgáltatást kéri a VPOP-tıl. A VPOP az igazolásból vett adatok alapján ellenırzi az ügyfél állapotát, majd mivel azt rendben találja, maga is aláirja az igazolást. Végül az igazolást megvizsgálja annak okán, hogy megtudja, neki mi a teendıje a továbbiakban. Mivel az igazolás kész, abban több közremőködıt nem talál, 4: kéri a KR felelısségi körébe tartozó igazolást tedd a tárba szolgáltatást, paraméterként átadva az igazolást. 5: Valamikor késıbb az ügyfél az ügyfélkapun indított kéréssel veszi át a tárból az igazolást. adóvám_2 KR APEH VPOP Ügyfél 1: dupla 0-s igazolást (adóaz) 2: 0-s igazolást_2(igazolás) 3: 0-s igazolást_2(igazolás) 5:kérem az igazolást 4: igazolást tedd a tárba (igazolás) 5. ábra - Elosztott vezérlés A két változatot összehasonlítva megállapíthatjuk: a) Mindkét változat alkalmas az igazolás kiadására. b) A KR által nyújtott három szolgáltatás ( dupla 0-s igazolás, igazolást tedd a tárba és kérem az igazolást ) interfésze mindkét esetben megegyezik. Azaz az ügyfél (pontosabban a nevében eljáró ügyfélkapu) számára láthatatlan, hogy melyik változat szerint kap igazolást. c) Az elsı esetben a KR-nek még meg kell valósítani két további szolgáltatást ( APEHOK, vámok ). Ezeknek a feladata az APEH-tıl és a VPOP-tıl érkezı visszaigazolások továbbítása az igazolás kérésére a KR_en elindított cselekményhez. d) A 0-s igazolás_ szolgáltatások változaton belül a két szakrendszerben, az APEHnél és a VPOP-nél csak minimális mértékben különböznek. e) A 0-s igazolás_ szolgáltatások változatonként nagyon eltérnek egymástól. Az elsı változatban az adóazonosító alapján meg kell keresni az ügyfél állapotát és BME Informatikai Központ 46

47 annak eredményét a KR OK szolgáltatásával tudatni. A második változatban a két szakrendszer felelıssége sokkal nagyobb. Itt nem az adóazonosítóból indul ki, hanem a részben kitöltött igazolásból. Az igazolásból vett adatokból megkeresi ugyanazon adatokat, mit az elsı változatnál, majd az igazolást aláírja, és ismét értelmeznie kell az igazolást azért, hogy meg tudja állapítani, melyik szolgáltatás kérésével folytatódik az ügy. f) A második változat 0-s igazolás_ szolgáltatásai nagyon függhetnek az igazolás tartalmának, formájának és az ügy kezelésének változásától. Ha valamilyen ok miatt megváltozik az igazolás, akkor az igazolás kezelésre, értelmezésére készített cselekményt meg kell változtatni mindkét szakrendszerben. Ez az elvileg két független szakrendszer fejlesztıinek egyidejő, párhuzamos munkáját igénylik, ráadásul a hibázás lehetısége is nagy. A probléma eredendı oka a kapcsolatban álló szakrendszerek közötti szoros csatolás, ami a közöttük átadott paraméter bonyolultságából származik. Nyilván sokkal nehezebb feladat egy igazolás felismerése, interpretálása, annak alapján döntések meghozatala, mint egy adóazonosító alapján egy számot (tartozást) megkeresni (amit egyébként a második változat esetében is meg kell tenni). g) Általánosságban is elmondható, hogy érdemes törekedni a szolgáltatások paramétereinek egyszerősítésére. Pontosabban, olyan szolgáltatásokat próbáljuk kialakítani, amelyek egyszerően paraméterezhetıek. Vizsgáljuk meg a különbséget az ügyfél kérését a KR-en kiszolgáló dupla 0-s igazolás szolgáltatás két változatában! Mindkét változatban elı kell tudni állítani az üres igazolást. Az elsı változatban a szakrendszerek válaszait is be kell tudni írni abba. Az elsı változat abból a szempontból is bonyolultabb, hogy fogadnia kell tudni a szakrendszerektıl érkezett visszajelzéseket (callback). A két szolgáltatáslánc közötti különbség a legjobban abban mutatkozik meg, ha választ keresünk arra kérdésre, hogy az egyes változatokban kihez, mihez kell fordulni, ha meg akarjuk tudni, hogy az ügyfél kérésének kiszolgálása (az ügy ) hol is tart. Az elsı változatban az ügy állását a KR-en megvalósított dupla 0-s igazolás szolgáltatástól tudjuk meg. Ez a szolgáltatás elejétıl végéig felügyeli az ügyfél által kért szolgáltatás végrehajtását, ı kéri a szakrendszerek közremőködését, ı a szolgáltatás egészének felelıse. Tekinthetı az ügy karmesterének. Vezényli a kapcsolódó szolgáltatásokat, mint egy zenekart. Ezt a nézetet szokás orchestration -nek, orkesztrációnak nevezni. A második változatban a központi vezérlés hiányában az ügy állását az éppen készülı igazolásból nyerhetjük ki. A helyzetet nehezíti, hogy az úton levı igazolást úgy tudjuk elérni, ha követjük az útját. Ez nem könnyő, mert a közremőködı szolgáltatások a bennük foglalt szabályok és a közöttük áramló igazolások (dokumentumok) alapján, egyfajta koreográfia szerint járnak el, és adják tovább az igazolást. Ezt a nézetet choreography, koreográfia néven említik Orkesztráció vagy koreográfia? Az ügyek mindkét nézıpontból leírhatók, modellezhetık. Meglátásunk szerint a papíralapú közigazgatásban mindkettınek vannak hagyományai. Mindkét szemlélet szerinti leírásnak vannak szabványai. Az orkesztrációnak például a Business Process Execution Language for Web Services (BPEL4WS), míg a koreográfiának a Web Service Choreography Interface (WSCI). BME Informatikai Központ 47

48 Megítélésünk szerint az e-közigazgatásban az orkesztrációs nézıpontot és leírást érdemes választani. Indokok: Az ügyleírások, az eljárások a koreográfiai szemléletet tükrözik. Az ügy életciklusának, a változásoknak a követése egyszerőbb. Az ügyekhez egyértelmő felelıs rendelhetı, a megfelelı jogosultságokkal. Az ügyfelek ügyekkel találkoznak, számukra ez a természetes nézıpont. A rendkívüli helyzetek szabályozása, kezelése sokszor egyszerőbb, átláthatóbb. A hagyományos programozói folyamatábra szemléletnek egy modern változata. Jobban implementált és elterjedtebb Architektúra kiválasztása, indoklása Az elızı pontban összefoglalt nemzetközi példákat és a projekt partnerek legjobb gyakorlatát alapul véve a rendszertervben definiálunk egy architektúrát. A lehetséges döntési pontokban indokoljuk a választásainkat Réteg modell A közigazgatási sín alapvetıen egy rétegelt modell szerint épül fel. Amennyiben megtartjuk a szigorú rétegrendet, a rétegek cseréje konfigurációs feladattá egyszerősödik. Nyilvánvalóan az egyes rétegek meghatározásánál a szabványokból és ajánlásokból kell kiindulni. Ezen a ponton a munka tartalmi vonatkozásban csatlakozik a szabványtár alprojekthez. A rétegek sorrendje: cselekményi, szolgáltatási, csomagoló, közmő-hozzáférési, csomagtárolási és csomagátviteli réteg. A szolgáltatási réteg alatti rétegek úgy vannak kialakítva, hogy az együttmőködık számára közömbös legyen az átviteli rendszerben alkalmazott technológia. Réteg Cselekményi réteg Szolgáltatási réteg Csomagoló réteg Közmőhozzáférési réteg Csomagtároló réteg Csomagátviteli réteg Feladat Feladata az egyes cselekmények végrehajtása. Feladata a szolgáltatások nyújtása, a szolgáltatási kérések feldolgozása és kiszolgálása. Az egyes kéréseket továbbadja a Cselekményi rétegbe, ahol a szolgáltatás végrehajtódik. A cselekmények felıl fogadja a szolgáltatáskéréseket, és továbbítja a Csomagoló réteghez. Feladata a szolgáltatáskérések (üzenetek) becsomagolása, és a Közmőhozzáférési réteg által megkövetelt technológiával a réteghez juttatása. A rétegtıl csomagokat kap, ezekbıl kiveszi az üzeneteket és továbbítja Szolgáltatási réteghez. Ez a réteg biztossítja, hogy egy üzenet pontosan egyszer filozófát követve jusson el egyik szolgáltatási rétegtıl a másikig. Feladata, hogy fogadja a Csomagoló rétegtıl érkezı csomagokat. A csomagtárolóba beérkezı csomagok létérıl értesíti a Csomagoló réteget, vagy vár, amíg a réteg kér egy újabb csomagot. Szerepe, hogy a Csomagtároló réteg és a Csomagoló réteg között az átvitelt érintı technológiai konverziót megoldja. Feladata a Csomagátviteli rétegtıl beérkezı csomagok perzisztens tárolása, valamint a Közmőhozzáférési rétegtıl érkezı csomagoknak a Csomagátvitei réteghez juttatása. Feladata a csomagok megbízható, "legalább egyszer" filozófiát megvalósító átvitele a Csomagtároló rétegek között. BME Informatikai Központ 48

49 A rétegek közötti vertikális és horizontális kapcsolatokat szemlélteti a 6. ábra: Közmő rétegei Szolgáltató rétegei 6. ábra Rétegek kapcsolatai A rétegek részletes felépítését a 7. ábra mutatja be: BME Informatikai Központ 49

50 Szolgáltatási réteg Cselekmény réteg Alapszolgáltató Cselekmény A Szolgáltatás1 Szolgáltató Cselekmény B Szolgáltatás2 Szolgáltatás3 Csomagoló réteg csomagküldı csomagfogadó csomagküldı csomagfogadó Közmőhozzáférési réteg csatoló csatoló Csomagtároló réteg csomagtár csomagtár Csomagátviteli réteg Megbízható csomagcsatorna 7. ábra - Az architektúra rétegeinek részletes felépítése Cselekmény Egy tevékenység konkrét végrehajtása. Szolgáltatás Egy szolgáltató által végzett tevékenység specifikációja, amely tevékenység a szolgáltatást kérı számára értékkel bíró eredményt, hatást állít elı. A szolgáltatás igénybe vétele a hozzárendelt tevékenység végrehajtását (cselekmény elindítását) kezdeményezi. A szolgáltató számára más szolgáltatások elérése abból áll, hogy az alatta levı réteghez egy megfelelıen elıállított üzenetet küld. Ugyanígy arról, hogy szolgáltatást kell nyújtania, abból értesül, hogy az alatta levı rétegtıl egy megfelelıen elıállított üzenetet kap. Az alatta levı réteg implementációjáról, az üzenetek átvitelének a módjáról semmiféle tudással nem rendelkezik. Üzenet A szolgáltatás igénybe vételéhez szükséges konkrét adatok (szolgáltatás címe, paraméterek, tanúsítványok, stb.) összessége. Az üzenet formátumát WSDL definiálja. BME Informatikai Központ 50

51 Csomag A közmő által átvitt entitás, amely pontosan egy üzenetet tartalmaz. A közmő csak csomagokkal dolgozik. A csomagokban levı üzenetekrıl semmit sem tud, azok tartalmát nem olvassa, nem módosítja. Csomagküldı Feladata az üzenet becsomagolása, majd annak a közmő-hozzáférési réteghez való továbbítása. Csomagfogadó Feladata a csomag kibontása és az üzenet megfelelı szolgáltatáshoz történı továbbítása. Csatoló Feladata a felette lévı rétegbeli elemek (Csomagküldı és fogadó) számára, hogy a közmőben alkalmazott csomagtároló és továbbító technológiától függetlenül képesek legyenek a közmőre csatlakozni. Minden támogatott kapcsolódási lehetıséghez, technológiához saját csatoló implementáció készül. Csomagtovábbító közmő A csomagátviteli réteg, a csomagtároló réteg és a közmőhozzáférési réteg összefoglaló neve. Közigazgatási szolgáltatási sín A csomagtovábbító közmő és a csomagoló réteg együttes neve A csomagtovábbító közmő A csomagcsatorna felelıs a csomagok (package) egyik csomagtártól a másikig juttatásáért. A csomagok átvitele garantált (csomag nem veszhet el átvitel közben) perzisztens (a rendszer újraindítása után is megmaradnak az át nem vett csomagok) hiteles (a csomag feladója, eredı socket-azonosítója egyértelmően azonosítható) letagadhatatlan (a csomag átvevıje, ha a csomagot átvette, nem tudja letagadni, hogy az adott csomagot megkapta). A csomag hasznos tartalma, az üzenet a közmő által nem értelmezett, nem ellenırzött, csak a szolgáltatás számára kell, hogy értelmes legyen. A közmőre csatlakozó (regisztrált) szolgáltatók egy dedikált csatolót kapnak. Ez egyedileg címezhetı, ezen keresztül küldhetı és fogadható csomag. A közmő a többi csatolótól beérkezı csomagokat egy korlátlan mérető csomagtárban, perzisztens módon győjti. A csatoló elérése többfajta technológiával is megoldható, jelen rendszerterv a WS-* szabványoknak megfelelı kapcsolat specifikálását és kialakítását javasolja Szolgáltatók Szolgáltatónak nevezzük a közmőre regisztrált, saját csatolóval rendelkezı szereplıt. A csatoló és a szolgáltató között mindig egy-egy kapcsolat van. A szolgáltatót a sínen egyértelmő cím (pl. a csatoló azonosítója) azonosítja. A szolgáltatók a csatoló interfészén keresztül küldhetnek üzenetet más, a közmőre csatlakozó szolgáltatónak. Az üzenetek felépítésérıl a közmő semmit sem tud. A közmő csak az átadásért felelıs. Egy szolgáltató többfajta dokumentumot is fogadhat. Ezek szerkezetét, tartalmát a szolgáltatáskatalógusban publikálják. Elıírható, hogy minden, a szolgáltató belsejébe (alszolgáltatónak) címzett üzenetnek tartalmaznia kelljen a szolgáltatóban megcímzett entitás (alszolgáltató) azonosítóját. Ez azonban a közmő számára teljességgel érdektelen. BME Informatikai Központ 51

52 Alapszolgáltatók Olyan speciális szolgáltatások, amelyeknek az architektúrában kitüntetett szerepük van, jellemzıen valami általánosan, mindenki által igénybe vett feladatot látnak el. Szolgáltatáskatalógus Tartalmazza az összes, a közmőn át elérhetı szolgáltatás leírását. A leírás megadja a szolgáltatás elérési címét, a szolgáltatásnak küldhetı üzenet felépítését. Tokenszolgáltató Lehetıvé teszi, hogy egy adatot adott ideig egy adott entitás tudja csak használni. Pl. az állampolgár TAJ számát tokenizáljuk, hogy csak az OEP tudja kiolvasni. Így az APEH szakrendszere nem tudja megismerni a konkrét adatot, de egy folyamat során a token segítségével elkérheti az OEP-tıl az állampolgárra vonatkozó, az ügy szempontjából releváns adatokat. Hitelesítésszolgáltató Megadja, hogy egy adott dokumentum a kérdéses entitás tanúsítványával van-e ellátva. E-tár Dokumentumok tárolására képes, az ügyfélkapu része. A dokumentumok elérését szabályozni lehet. Minden dokumentumhoz megadható, hogy kinek milyen idıintervallumban van joga a dokumentumot megkapni. Alapvetıen klasszikus könyvtárkezelı funkcionalitás megfelelı hozzáférés-vezérléssel. Ügyfélkapu Lehetıvé teszi, hogy az állampolgárok: a) elérjék a közigazgatás nekik szóló szolgáltatásait aa) a szolgáltatások több dimenzió szerint is kereshetık, navigálhatók ab) különbözı élethelyzetekhez varázsló segítségével indíthat közigazgatási folyamatot b) elérjék a nekik címzett hivatalos leveleket ba) ezek kapcsán lehetıvé teszi, hogy a levelek beérkeztérıl különbözı csatornákon ( , SMS, galambposta) értesüljenek c) elérjék az e-tár fiókjukat ca) listázhatják a tartalmat cb) feltölthetnek dokumentumot cc) törölhetnek dokumentumot d) állíthatják a dokumentumok hozzáférési jogosultságait Az ügyfélkapu lehetıvé teszi, hogy a sínre csatolt szolgáltatások az állampolgároknak biztonságos levelet küldjenek. Ez mindig alá van írva, így a spammelést minimalizáljuk. BME Informatikai Központ 52

53 A réteg modell formális nézete Az osztályok leírása Szakrendszer Cselekmény réteg Ügy Tevékenység Lépés 1 * 1 * * 1 Szolgáltatás «datatype» Üzenet Szolgáltatási réteg 1 * * 1 1 Csomagoló réteg CsomagfogadóImpl Csomagküldı 1 «interface» Csomagfogadó «datatype» Csomag «interface» Csatolófelület Csomagtovábbító közmő Csatoló Csomagtár Csomagcsatorna 1 1 * 1 8. ábra A réteg-modell osztályai Csomagcsatorna Felelısség: Csomagok eljuttatása egyik csomagtártól a másikig. A céltár címe a csomagon (közvetve vagy közvetlenül) megadva. send(p:csomag) a csomagtárból ide kerülı csomagokat a céltárhoz megbízhatóan át kell vinni. BME Informatikai Központ 53

54 Csomagtár Felelısség: a kapott csomagokat tárolja, amíg a Csatoló át nem veszi. Ha kell, értesíti az új csomagról az érintettet. put(p:csomag) behelyezi a sorba a csomagot. Ha kell, értesíti a regisztráltat. getnext():csomag kiveszi a soron következı csomagot a sorból. Csatolófelület Felelısség: ezt az interfészt érik el az interfész által nyújtott átviteli technológiával (RPC, SOAP, stb.) a szakrendszerek. Tipikusan a Csatoló implementálja. Ezen az interfészen keresztül tud a szakrendszer a sín felıl csomagot kapni, valamint az interfész támogatja mind a pull, mind a push átvitelt. send(p:csomag) ez a metódus a sín felé továbbítja a paraméterként beérkezı csomagot, miután ellátta ıt a feladó azonosítójával. getnext():csomag visszaadja a következı csomagot. setnotify(b:boolean) beállítja, hogy új csomag esetén továbbítsa-e a csomagot, vagy várjon az átvételre. Csatoló Felelısség: a fenti interfész (Csatoló) megvalósítása. Egy Csomagtárhoz és egy Csomagfogadóhoz csatlakozik. Feladata, hogy egy adott átviteli technológiával kapcsolatot hozzon létre a sín és a szakrendszer között. Csomagküldı Felelısség: a szolgáltatási sín és a szakrendszer kapcsolatának egyik tagja, a szakrendszer valósítja meg. A szakrendszer kapuja a sín felé. Mindig egy Csatolófelület-hez kapcsolódik. A kapcsolat megbízható kell legyen. Csomagfogadó Felelısség: a szolgáltatási sín és a szakrendszer kapcsolatának másik tagja, a szakrendszer valósítja meg. Az interfész a szakrendszer kapuja a sín felıl. Mindig egy Csatoló ismeri. A kapcsolat megbízható kell legyen. receive(p:csomag) a sín felıl érkezı csomagot a Csatoló e metódust meghívva adja át. Csomag A szakrendszerek között a sínen át utazó objektum. Tartalmazza egy üzenetet, amit a címzett szolgáltatás dolgoz fel. A csomag feladata, hogy lehetıvé tegye a sínen való utazást, címzést, stb. A csomag attribútumai: Attribútum Típus Kitöltı Érték to Address kliens a csomag címzettje from Address csatoló a feladó címe identifier UUID csatoló a csomag globálisan egyedi azonosítója payload Message kliens a csomag tartalma: az üzenet Üzenet A sínre csatlakozó szolgáltatók közötti kommunikáció üzenetek segítségével történik. Az üzenetet a sínre küldés elıtt be kell csomagolni egy Csomagba, amit meg kell címezni. BME Informatikai Központ 54

55 Szolgáltatás, Ügy, Tevékenység, Lépés Az szakrendszer szolgáltatását megvalósító osztályok. Implementációjuk a szakrendszer felelıssége Infrastruktúra kialakítása (névtér, címkezelés, repository, felügyelet) A szolgáltatási sínen keresztül történı közigazgatási szolgáltatás-kérés és -kiszolgálás alapja a szolgáltatási sín által nyújtott szolgáltatáshalmaz. A következı analógia használható: Közkedvelt szolgáltatás a telebank, amelynek lényege, hogy az ügyfél telefonon keresztül banki mőveleteket végezhet. Ehhez egyfelıl elengedhetetlen a banki szolgáltatást nyújtó bank, másfelıl az ügyfél és a bank közötti átviteli szolgáltatást nyújtó telefonszolgáltató. A leírás jelen pontjában azt definiáljuk, hogy magának az infrastruktúrának milyen szolgáltatásokat kell nyújtania. Meg kell vizsgálni, hogy ezen szolgáltatások melyike igényel központosítást és melyek végezhetık elosztottan. Az alapszolgáltatások közé tartozik a névés címterek kezelése, szolgáltatáskatalógusok üzemeltetése, a forgalom rögzítése, dokumentálása, a sín felügyelete. A SOA rendszerek menedzsmentje alapvonalaiban megegyezik az összetett, nagybonyolultságú IT rendszerek menedzsmentjével. Az alábbi tulajdonságok azonban új kihívásokat jelentenek: a) A szolgáltatások granularitása erısen különbözı. Az egyik szolgáltatás tárgya lehet egy elemi adat lekérdezése (házasságkötés dátuma), a másiké egy bonyolult közigazgatási folyamat egésze (halálesetet követı gyámügy). A menedzsmentnek magasabb szinten képesnek kell kell lenni a közigazgatási modell felügyeletére is. A közigazgatás mőködése, a mőködés paraméterei követelményeket, korlátozásokat jelenthetnek a keretrendszer egészére illetıleg egyes komponenseire nézve. A definiált közigazgatási szintő indikátorok folyamatos figyelése, kiértékelése alapul szolgál a közigazgatási szolgáltatási folyamat átszervezésére, tökéletesítésére (BPM) b) A szolgáltatások gyorsan változnak. Egyfelıl folyamatosan változik az a jogszabályi környezet, amelynek meg kell felelni a szolgáltatásnak, másfelıl remélhetıleg a e-közigazgatási rendszerbe folyamatosan új szereplık (pl. önkormányzatok) új feladatokkal kapcsolódnak. c) A szolgáltatások fejlesztése erısen elosztott. A szolgáltatásokat általában annál a szakrendszernél kell vagy legalábbis célszerő megvalósítani, ahová a szolgáltatás felelısségét rendeltek, ahol ehhez a szükséges hagyományos nyilvántartások és szakértelem, valamint a kompetencia rendelkezésre áll. d) A hagyományos IT alaprendszereket szállítók komoly támogatást adnak a menedzsment feladatok elvégzésére. Ezeket az eszközöket folyamatosan továbbfejlesztik és teszik alkalmassá a SOA keretrendszereik kezelésére, felügyeletére. Amennyiben különbözı szállítók termékeit kívánjuk összekapcsolni, akkor szembetalálkozunk a SOA menedzsment rendszerek kompatibilitásának kérdéseivel, illetıleg jelentıs feladat lehet az interoperabilitás megteremtése Követelmények Az alábbiak ismertetik a SOA rendszerek menedzselésével kapcsolatos követelményeket. BME Informatikai Központ 55

56 a) Azonosítás és felismerés: a SOA rendszer természetébıl adódóan gyorsan változik. A menedzsment alapvetı feladata mindenkor világos, áttekinthetı képet adni a rendszer aktuális szerkezetérıl, az elérhetı szolgáltatásokról, komponensekrıl. Szükség esetére eszközök kellenek a szolgáltatások magasszintő kezelésére (leállítás, újraindítás, stb.) b) Megfigyelhetıség: Támogatnia kell mindazon lépéselket, tevékenységeket, amelyeknek célja az aktuálisan meglevı rendszer mőködésének monitorozása, szükség szerint beavatkozási lehetıség biztosítása, paraméterek megváltoztatása, hangolása. Ehhez a ponthoz értendı a QoS jellemzık mérése, győjtése. A monitorozás eredményeként meghatározhatjuk az egyes szolgáltatások, (vagy általánosabban az erıforrások) igénybevételének mértékét, annak idıbeli eloszlását, a teljesítményigényeket, az eszközök, komponensek rendelkezésre állását. c) Követés: A SOA rendszer minden egyes komponensének saját fejlıdéstörténete lehet. A menedzsment támogatásnak ki kell terjedni a komponens élettörének követésére. Információt kell szolgáltatni az egyes verziókról, a változatok közötti különbségekrıl, a különféle szolgáltatások és komponensek különbözı verzióinak egymástól való függıségeirıl. d) Problémakezelés: A nagyfokú dinamizmus egyik következménye lehet a kivételes helyzetek gyakoriságának növekedése. A menedzsment eszközeivel egyszerősödnie kell a kivételek kezelésével kapcsolatos folyamatoknak. Támogatás szükséges a kivételek lefutásának követéséhez, a kivétel okának felderítéséhez. Ezen feladatok megoldásának sikere általában a logoláson múlik. Elsısorban megbízható, a rendszerbeli történéseket híven követı logoló szolgáltatások kellenek. Másodsorban eszközök az elosztott logok hatékony feldolgozására, kezelésére. e) Pénzügyek: A SOA rendszer egyes komponenseinek használata, elszámolást, esetleg fizetési kötelezettséget von maga után. Ezek a komponensek kapcsolatban állhatnak a rendszer erıforrásaival (memória, tár, licence.) vagy bizonyos (SMS vagy üzenetküldés, letöltések száma, mennyisége ) szolgáltatásokkal. A rendszernek eszközöket kell adni az elszámoláshoz szükséges adatok győjtésére, valamint a győjtött adatok alapján az árazás figyelembe vételével számlázni a kliens vagy külsı szolgáltató felé. f) Biztonság: A SOA rendszernek a biztonsággal kapcsolatos komponensei (felhasználók és erıforrások) felügyelete tartozik a biztonsági menedzsment témakörébe. A szolgáltatások biztonságába értjük az egyes szolgáltatásokkal kapcsolatos biztonsági elıírások felvételét, azok meglétének ellenırzését valamint a szolgáltatás kérések biztonsági szempontból történı ellenırzésének támogatását. A menedzsment körébe tartozik a felhasználók adminisztrációja, a felhasználók biztonságának követése a teljes kiszolgálási folyamat alatt. Ebbe beleértendı az azonosítás, hitelesítés, felhatalmazás ellenırzése, a kapcsolatos technikai megoldások (pl. digitális aláírás, token-szervíz) követése, róluk statisztikák készítése. Az egypontos belépési rendszernek biztosítani kell a rendszer valamennyi komponense számára a felhasználó egyértelmő azonosítását (federated identification). A biztonság egy alapvetı tényezıje az adatok integritása elvének megvalósulása. A tranzakció menedzsment feladata az integritást biztosító tranzakciók felügyelete, annak jelzése, ha olyan esemény történt a rendszerben, amely az adatok integritásának sérülésével járhat. A menedzsment feladata még BME Informatikai Központ 56

57 mindazon adatok győjtése, amelyek szükségesek lehetnek a rendszer biztonsági auditjának lebonyolításához, a megfelelıség igazolásához A menedzsment komponensei A menedzsmenttel szemben támasztott követelményekbıl meghatározható funkciók lényegüket tekintve szintén szolgáltatásként jelennek meg. Ezen szolgáltatások tárgya azonban nem valamely közigazgatási célú feladat megvalósítása (pl. gépkocsi forgalomból történı kivonása), hanem magának a rendszernek, a rendszer egyes elemeinek szolgáltatás szintő felügyelete, ellenırzése. A SOA rendszereket szállító gyártók a rendszereiket magaszintő menedzsment eszközökkel is felszerelik. Egy heterogén (több gyártó termékét tartalmazó) rendszerben szükséges lehet a különbözı menedzsment támogatások összekapcsolása, és a rendszer alapmőködését meghatározó egységes közigazgatási szolgáltatásrendszer kialakításával analóg módon szükségesnek látszik egy virtuális menedzsment vagy felügyeleti sín definiálása is. A közigazgatási buszra kapcsolódó (fıtevékenységükben közigazgatási funkciót nyújtó) szolgáltató elemek a saját mőködésükkel kapcsolatos szolgáltatásokat is kötelesek nyújtani. Ezen szolgáltatások összességét tekinthetjük a felügyeleti sínnek. A felügyeleti sín a közigazgatási sín infrastruktúráját felhasználva, azon saját mőködését, mint folyamatot felügyeli és vezérli A felügyeleti sínt jelentı fontosabb szolgáltatás-csoportok a) Konzol az egyes szolgáltatások beleértve a menedzment szolgáltatásokat is monitorozása, közvetlen elérése, bekapcsolása, leállítása. A paraméterek lekérdezése, beállítása. Ide tartozik a hálózati monitorozás, az üzenetek követése, az üzenetben szereplı adatszerkezetek megjelenése. Interceptorok közbeiktatása, az üzenetek transzformálása. b) Életjel a felügyeletnek minden pillanatban valós képe kell legyen arról, hogy mely szolgáltatások és folyamatok állnak rendelkezésre, melyek mőködnek, mely komponensek vannak üzemen kívül és a rendszer mőködésében hol jelentkeznek szők keresztmetszetek. A tapasztalatok alapján kiegészíthetı olyan modullal, amely képes a kritikus helyzetek elırejelzésére, javaslatot ad a rendszer konfigurálásának megváltoztatására c) Naplók a rendszer mőködésének dokumentálása és követés alapvetıen a naplózásokon áll. Naplók mind az üzenetkezelés, mind a szolgáltatások szintjén készülnek. Logok készülnek: o Üzenetkezelı rendszer szintjén az üzenetkezelı hatáskörében Az üzenetkezelı (kijelölt) metódusainak meghívásakor o Szolgáltatások szintjén a szolgáltatás kérésekor a szolgáltatást kérı hatáskörében a kiszolgálás megkezdésekor a szolgáltató hatáskörében a szolgáltatás végzése közben bármikor opcionálisan a szolgáltatás indításakor a szolgáltató hatáskörében a szolgáltatás leállításakor a szolgáltató hatáskörében BME Informatikai Központ 57

58 A napló adatok tárolásával és hozzáférésével kapcsolatosan figyelemmel kell lenni egyfelıl a mőködés megbízható, javítható felügyeletének igényére, másfelıl az adatvédelmi jogszabályokra. d) Statisztikák a helyi jelleggel győjtött naplók, adatok alapján a közigazgatási indikátorokra, de magára a rendszer mőködésére nézve is készíthetık, készítendık statisztikák. Ezek lekérésével, összegzésével kapcsolatos szolgáltatások tartoznak ebbe a csoportba. Legfontosabbak ezek közül az SLA indikátorok, pl: szolgáltatáskérések száma, sikeres/sikertelen aránya, hibák, teljesítmény paraméterek, SLA követelmények megsértése (pl. határidık túllépéses) e) Diagnosztika A rendszer folyamatos mőködéső, ezzel együtt folyamatosan új szolgáltatások vagy régi szolgáltatások új változatai lépnek üzembe. Új (változatú) komponens beállításakor, hibát követıen célszerő lehet diagnosztikai célú funkciók végrehajtatása. Diagnosztikai célból az éles rendszert használjuk, olymódon, hogy a kiváltott funkciók együttes hatása az éles adatokon nem okoz változást. f) Tesztelés A rendszer részei vagy egésze mőködhet teszt módban. Ennek lényege, hogy az éles rendszer helyett a kitüntetett teszt rendszert alkalmazzuk. Célja lehet a funkcionális, teljesítmény követelmények vizsgálata, benchmarkok készítése, illetve kivételes helyzetek definit körülmények közötti vizsgálata Cluster-ek kialakításának lehetısége Clusteren jelen rendszertervben közös felügyelet alatt álló csomagcsatornát, csomagtárakat és csatolókat értünk. Egy cluster-en belül a csatolók bármelyik csomagtárba közvetlenül tudnak üzenetet küldeni. Egy cluster lehet fizikailag elosztott is, a lényeg a közös adminisztráción van. Amíg csak egyetlen cluster van, addig nincs probléma a csomagok átvitelével. Felmerülhet azonban az igény, hogy például skálázhatósági okokból ne csak a központi rendszer rendelkezzen cluster-rel, hanem bizonyos nagyobb önkormányzatok, vagy régiók is (9. ábra). Ebben az esetben meg kell oldani a cluster-ek összekapcsolását. BME Informatikai Központ 58

59 9. ábra - Regionális és önkormányzati cluster-ek Különbözı cluster-ek között a csomagok átvitele nem triviális, ugyanis a különbözı csomagcsatornák implementációi közvetlenül nem kapcsolhatók össze. Az ajánlott megoldás az, hogy két cluster összekötése esetén mindkét oldalon nyitni kell a másik cluster felé küldendı illetve a másik cluster felıl érkezı csomagok számára egy-egy csomagtárat (10. ábra). A csomagtárak fölé olyan csatolók, csomagküldık és csomagfogadók kellenek, hogy mindkét cluster a saját csomagjait át tudja venni. Ezen kívül a csatolókban (vagy a csomagcsatornában) meg kell oldani a csomagban szereplı címzett alapján a csomag routeolását a másik cluster felé menı csomagtárba. 10. ábra - Csomagok átvitele cluster-ek között BME Informatikai Központ 59

60 A cluster-ek közti csomagok átviteléhez a route-olást célszerő statikusan konfigurálni, mivel a dinamikus felderítı algoritmusok komplikáltak lehetnek, új cluster beüzemelésére pedig ritkán van szükség. Több cluster esetén a cluster-ek fahierarchiába rendezhetık, de hatékonysági okokból kört tartalmazó gráf is elıállítható. Utóbbi esetben ügyelni kell arra, hogy a route beállítások ne tartalmazzanak kört. Több cluster esetén már nem lehet minden menedzsmentfeladatot közvetlenül központilag ellátni (pl. egy helyi csomagtár nyitását csak a helyi cluster adminisztrátora végezheti), így ki kell alakítani a megfelelı felügyeleti hierarchiát a többi cluster-re is hatással lévı döntések meghozatalához. Minden cluster-ben implementálni kell azokat a menedzsmentszolgáltatásokat, amelyek legalább csak olvasható módon lehetıséget biztosítanak a központi felügyeletre Dinamikus modell (mőködés) Az elızı pontban a javasolt architektúra szerkezetét és funkcionalitását vizsgáltuk, jelen pont pedig az idıbeli viselkedés leírását célozza. A modell a sínen illetıleg a sínhez kapcsolódóan elıforduló eseményeket azonosítja és meghatározza az érvényes esemény-sorrendeket, a szerkezeti elemek élettörténetét. Vonatkozik ez a kérés kiszolgálásától a sínre történı fel- és lecsatlakozásig. Meghatározásra kerül a sín mőködését leíró log-események köre, az események tárolásának megvalósítása. Mindez a vonatkozó jogszabályokkal összhangban. A következı leírásokban az egyes lépések felelıseire az alábbi jelöléseket alkalmaztuk: [S] Szolgáltató [B] Buszfelügyelet [U] Ügyfélkapu Új szolgáltatás csatlakoztatása létezı csatolóhoz Az alábbi lépések azt írják le, hogy mi a teendı akkor, amikor egy (a sínen csatolóval rendelkezı) szakrendszer új szolgáltatást kíván a sínen elérhetıvé tenni. [S] A szolgáltatás interfészének definiálása, dokumentálása [S] A szolgáltatás elkészítése [S] A szolgáltatás tesztelése, auditja [S] A következık elküldése a buszfelügyeletnek: o szolgáltatásleíró o dokumentáció o szolgáltatás címe o verzió o régi verzió érvényességi ideje o igénybe vett más szolgáltatások o választott csatoló neve [B] A szolgáltatás funkcionális és nem funkcionális tesztje a csatolón keresztül [B] A kérelem elbírálása [S+B] A szolgáltatás véglegesítése [B] A szolgáltatásleíró, a dokumentáció és a szolgáltatás címének regisztrálása a szolgáltatáskatalógusban [S] A többi szereplı értesítése az új szolgáltatásról BME Informatikai Központ 60

61 Új csatoló nyitása létezı cluster-ben Az alábbi lépések azt írják le, hogy mi a teendı akkor, amikor a sínen új csatolót kell megnyitni. [B] Új csomagtár nyitása a csatolóhoz [B] Új csatolópéldány generálása, telepítése [B] Tanúsítvány hozzárendelése a csatolóhoz (ha új, akkor a tanúsítványtárba is fel kell venni) [B] A hozzáférı szereplık tanúsítványainak megadása [B] A cluster belsı router-einek konfigurálása az új csomagtárhoz [B] A menedzsment feladatok konfigurálása az új csomagtárhoz és csatolóhoz [B] A csatoló, a router-ek, a menedzsment és az illetékes hozzáférés tesztelése [B] A csatoló véglegesítése Új cluster csatlakoztatása az e-kormányzati közmőhöz Az alábbi lépések azt írják le, hogy mi a teendı akkor, ha az e-kormányzati közmő több clusterbıl áll, ugyanis ilyenkor ezek összekapcsolása nem triviális, fıleg különbözı gyártók üzenetküldı rendszerei között. Például elıfordulhat, hogy hierarchikus címzésre, vagy külön csomagtárakra és csatolókra van szükség a cluster-ek között. [B] Cluster telepítése, tőzfalak beállítása [B] Tesztcsomagtárok beállítása [B] Menedzsment feladatok konfigurálása (pl. log queue, menedzsment szolgáltatások, stb.) [B] A többi cluster értesítése az új cluster-rıl [B] A megfelelı cluster-ek között átvivı csomagtárak, csatolók és szolgáltatások telepítése, konfigurálása, tanúsítványok hozzárendelése stb. [B] A router-ek átkonfigurálása [B] Az új cluster és az összes régi közötti üzenetküldés funkcionális és nem funkcionális tesztje [B] A cluster véglegesítése Új szolgáltatás felületének megjelenítése az Ügyfélkapun Az alábbi lépések azt írják le, hogy mi a teendı akkor, amikor egy új szolgáltatás az állampolgárok számára is elérhetı kell legyen, hiszen ebben az esetben az ügyfélkapun is meg kell jelenjen az új szolgáltatás képe. [S] Az Ügyfélkapu értesítése az új szolgáltatásról [S] Az állampolgár/jogi személy által kitöltendı őrlapok, felhatalmazások definiálása és elküldése az Ügyfélkapunak [U] Az őrlapok, felhatalmazások, linkek elhelyezése a weblapon [U] Tesztállampolgárként a szolgáltatás tesztelése [U] A szolgáltatás véglegesítése, a célszereplık számára elérhetıvé tétele BME Informatikai Központ 61

62 Nemfunkcionális követelmények Az alábbiakban definiáljuk azokat a nemfunkcionális követelményeket, amelyeknek az e- közigazgatási sínnek illetve az architektúrának eleget kell tennie. a) Bıvíthetıség A bıvíthetıség azt a képességet jelenti, hogy a rendszer gazdaságosan új funkciókkal bıvíthetı, vagy a meglévı funkcionalitások kiterjeszthetık anélkül, hogy azokat korlátozni kellene. Például az elektronikus kormányzati rendszerben különösen fontos a jogszabályok folyamatos változásai alapján a bıvítések és a változások követése. b) Rugalmasság A rugalmasság azt az általános képességet jelenti, hogy egy architektúrát újabb nem-funkcionális követelmények alapján módosítani lehessen. Egy változtatható topológia elısegíti az elosztott architektúra gyorsabb módosítását, ezáltal javítja a rendelkezésre állást, megbízhatóságot és skálázhatóságot. c) Interoperabilitás Az interoperabilitás heterogén rendszerek együttmőködési képességét jelenti. A szakrendszereken átívelı folyamatoknak átviteli közegtıl és gyártótól függetlenül megvalósíthatónak kell lennie. d) Nyitottság A nyitottság arra vonatkozik, hogy meglévı és új rendszerek minél kisebb költséggel integrálhatók legyenek. Ehhez jól definiált és dokumentált interfészekre van szükség. e) Teljesítmény A teljesítmény azt az általános képességet jelenti, hogy a funkcionalitásokat elég gyorsan végre lehessen hajtani ahhoz, hogy a rendszer használhatóságát biztosítsuk. A teljesítmény mértékét az adott idıegység alatt kiszolgált kérések száma adja meg. f) Biztonság A biztonság azt jelenti, hogy az információkat csak a kialakított biztonságpolitikának megfelelıen lehet megszerezni vagy módosítani. A legfontosabb szempontok az azonosítás, a hitelesítés, a felhatalmazás, a titkosság, a sértetlenség és a leragadhatatlanság. (Ezeket részletezzük, hogy mit jelentenek?) g) Skálázhatóság A skálázhatóság azt jelenti, hogy az alkalmazás növekvı terhelés mellett is képes a kívánt hatékonyságot és teljesítményt biztosítani. Az alkalmazás vagy bizonyos elemei elosztásának problémamentesen végrehajthatónak kell lennie. h) Megbízhatóság A megbízhatóság azt jelenti, hogy a rendszer hálózati problémák vagy bizonyos komponensek leállása mellett is képes a kérések fogadására. A befogadott kérések nem veszhetnek el, azoknak elıbb-utóbb garantáltan meg kell érkeznie. i) Rendelkezésre állás A rendelkezésre állás annak a mértéke, hogy az alkalmazás mennyire képes a funkcionalitását, szolgáltatásait és erıforrásait kiesésmentesen biztosítani. j) Karbantarthatóság A karbantarthatóság azt jelenti, hogy az alkalmazás komolyabb elıképzettség BME Informatikai Központ 62

63 nélkül olyan külsı szereplık által is gazdaságosan mőködtethetı és felügyelhetı, akik az alkalmazás kifejlesztésében nem vettek részt. k) Újrahasznosíthatóság Az újrahasznosíthatóság azt jelenti, hogy bizonyos komponensek vagy szolgáltatások azonos vagy hasonló feladatok megoldása során is felhasználhatók legyenek, ezáltal elkerülhetı a redundáns fejlesztés. Az újrahasznosítás különbözı absztrakciós szinteken történhet: pl. közös adat- és folyamatmodellek, architektúra minták és központosított szolgáltatások. A különbözı követelmények súlyozása bizonyos alkalmazásoktól függıen eltérı lehet. Például amíg nagyobb terhelési idıszakokban (pl. adóbevallás) a megfelelıen magas rendelkezésre állás elengedhetetlen, addig az érzékeny személyes adatok kezelését végzı feladatoknál a biztonság játszik kulcsszerepet. Az architektúra a következıképpen támogatja a fenti a követelményeket: a) Bıvíthetıség A jogszabályi változások követése technikailag viszonylag könnyő feladat, mivel a web-szolgáltatásokat a különbözı gyártók eszközei jól támogatják. A bıvítésnél azonban ügyelni kell arra, hogy a megfelelı tesztek végrehajtásra kerüljenek, átállás esetén pedig a verziózás is fontos szerepet kap. Fontos, hogy egy új szolgáltatás üzembe állítása vagy kivonása csak egy engedélyezési eljárás keretében történhet meg. b) Rugalmasság Az architektúra jól elkülönített rétegeket definiál, amelyek nyílt szabványokon alapulnak, gyártófüggetlenek és igény esetén lecserélhetık. Akár egy késıbbi új technológia bevezetésekor is a rétegek lépésrıl lépésre kiválthatók. c) Interoperabilitás A web-szolgáltatások és a WS-* szabványok a különbözı gyártók eszközeinek interoperabilitását segítik elı. Az architektúrában említett szolgáltatásokat webszolgáltatásokként kell megvalósítani. A szolgáltatások interfészét WSDL írja le, az üzenetek formátuma SOAP. Ezeket jelenleg a legtöbb gyártó eszköze támogatja. További elınyük, hogy mivel XML-re épülnek, könnyő a feldolgozásuk. d) Nyitottság Az architektúra pontosan specifikálja, hogyan csatlakoztathatók új szolgáltatók a sínhez. A csatolók interfésze is jól definiált. A sín felépítésnek köszönhetıen egy új szolgáltató felvétele minimális hatással van a többi szolgáltatóra. Az architektúra támogatja a késıbbi bıvítést akár az önkormányzatok, akár az EU felé. e) Teljesítmény Az architektúra alapvetı célja a garantált üzenetküldés megvalósítása úgy, hogy a kérések kiszolgálását a szolgáltatók a saját tempójukban végezhessék. Ezáltal elkerülhetı az, hogy minden szolgáltató költségesen kialakított nagy rendelkezésre állású és teherbírású legyen. Ennek hátránya azonban, hogy a kis teljesítıképességő szolgáltatók lassabban válaszolnak a kérésekre, de az architektúraterv ezt a kompromisszumot elfogadhatónak tartja. f) Biztonság Az architektúrában a biztonság több szinten jelenik meg: BME Informatikai Központ 63

64 fa) A sínhez a csatolókon keresztül csak az arra jogosult szolgáltatók kapcsolódhatnak. Ezt a csatoló, valamint a csomagküldı és -fogadó között tanúsítványokkal kell biztosítani. fb) A szolgáltatók által átvett csomagokról a sín automatikusan egy digitálisan aláírt tértivevényt küld a feladónak. Ezáltal a feladó igazolni tudja, hogy a kérése valóban eljutott a kiszolgálóhoz, aki ezt nem tudja letagadni. fc) A sín önmagában nem biztosít az üzenetek tartalmára vonatkozó biztonsági funkciókat, így azokat szolgáltatásszinten (alkalmazásszinten) kell megvalósítani. fd) A szolgáltatások közötti üzenetek titkosítása és digitális aláírása igény esetén történhet a WS-Security szabványnak megfelelıen. Ez biztosítja az azonosítást, hitelesítést, titkosságot, sértetlenséget és letagadhatatlanságot. fe) Amennyiben bizonyos szolgáltatások igénybe vételéhez speciális felhatalmazások szükségesek, azokat egy tokenszolgáltató tudja biztosítani a WS-Trust és WS-Federation szabványok alapján. Ajánlott az SAML tokenek használata. Ez a modell az adatvédelmi jogszabályokkal konformizálható. ff) A rendszerben felhasznált tanúsítványok érvényességét egy hitelesítésszolgáltató ellenırzi. g) Skálázhatóság A sín egyes komponenseinek megfelelı elosztásával elérhetı, hogy a lokális érvényő csomagátvitel a sín többi részére ne legyen hatással, így a terhelés jobban szétosztható. Egy jól kialakított hardveres háttér és megfelelı szoftveres konfiguráció lehetıvé teszi növekvı terhelés esetén újabb komponensek indítását, ezáltal a nagyobb teljesítmény elérését. h) Megbízhatóság A sín kialakítása olyan, hogy garantálja a pontosan egyszeri üzenettovábbítást, akár hálózati problémák vagy egyes szolgáltatók kiesése esetén is. A csomagcsatorna célszerően egy MQ (message queue) megoldás (pl. JMS vagy MSMQ), amely perzisztens módon képes a csomagok pontosan egyszeri átvitelét garantálni. A csomagtárak feladata a hosszabb távú tárolás és az üzenetek naplózása. A csatolók és a csomagfogadók feladata a csomagtárból a csomagok átvitele a szolgáltatóhoz. Ezeket úgy kell kialakítani, hogy hálózati problémák vagy a szolgáltató újraindulása esetén is garantálják a pontosan egyszeri átvitelt. i) Rendelkezésre állás A magas rendelkezésre állást az architektúra felépítése két ponton képes biztosítani: az egyik a moduláris, réteges felépítés, ami lehetıvé teszi, hogy a rendelkezésre állás szempontjából kritikus elemeket a többi modul vagy szint módosítása nélkül megváltoztathassuk. A másik pont a skálázhatóság, mivel a rendszer a kritikus elemekkel a jó skálázhatóság által megkívánt rendelkezésre álláshoz szükséges számban és minıségben bıvíthetı. j) Karbantarthatóság Az architektúra elıírja a kialakítandó menedzsmentfeladatokat, amelyek nagyban megkönnyítik a karbantarthatóságot. k) Újrahasznosíthatóság Az architektúrában vannak olyan központosított szolgáltatások (tokenszolgáltató, hitelesítésszolgáltató, szolgáltatáskatalógus), amelyek bármely szolgáltató által BME Informatikai Központ 64

65 igénybe vehetık, így újrahasznosíthatók. A már elkészült csatlakozók, valamint a csomagküldık és -fogadók újrahasznosíthatók egy új szolgáltató felvételekor. 6. Egy mintaeljárás mőködése az architektúrán Az elızı pontokban bemutatott architektúra mőködıképességét kívánjuk igazolni ebben a fejezetben egy közigazgatási mintaeljárás megvalósításával és mőködésének szemléltetésével. A mintaeljárás kiválasztásakor arra törekedtünk, hogy minden fontosabb mozzanatát megmutassa a mőködésnek, a legfontosabb kérdések (pl. magyarországi adatvédelmi törvények kapcsán felmerülı kérdések) megoldására választ adjon, valamint legyen egyszerő az átláthatóság érdekében. Lényegét tekintve ebben a részben dokumentáljuk a javasolt architektúra tervezıi tesztjét. A következı alfejezetek a mintaeljáráson keresztül egyre részletesebben mutatják be az architektúra mőködését. A kibontás felülrıl lefelé, az általános leírástól az egyre technikaibb részletek felé történik. Minden alfejezet végén ismertetjük, hogy az eset kapcsán felmerülı problémák közül melyek lettek az adott szinten kezelve A mintaeljárás rövid ismertetése Mintaeljárásnak a következıt választottuk: Kiss László elkészít egy kérvényt, melyet aláír és levélben elküld (bead) az X hivatalhoz. Az X hivatal átvizsgálja, hogy helyes-e a kérvény tartalma. A kérvény jogosságának megállapításához levelet ír az Y hivatalhoz, melyben megkérdezi Kiss László gyermekeinek számát. Az Y hivatal válaszlevelet küld Kiss László gyermekeinek a számával. Az X hivatal jogosnak találja a Kiss László kérvényét, amirıl értesítést küld Kiss Lászlónak. Az eljárást az 11. ábra szemlélteti. 11. ábra - A mintaeljárás magas szintő szemléltetése BME Informatikai Központ 65

66 A mintaeljárásban megjelenik az ügyfél-hivatal, a hivatal-hivatal és a hivatal-ügyfél kommunikációja. Ugyancsak meg kell figyelni, hogy az X hivatal az ügyfél felhatalmazására egy adott ügyben kér el adatot az Y hivataltól, amelynek a példa kiválasztásában ugyancsak szerepe volt. X-beli Az eljárás leírásában nem lett megemlítve, de a késıbbiekhez fontos kiemelni, hogy az X hivatal a K.L. X hivatalbeli azonosítót, az Y hivatal pedig a K.L. Y hivatalbeli azonosítót használja Kiss László azonosításához. Az üzenetváltások a szereplık között a Postán keresztül történnek, amelyet megbízhatónak tartunk (az üzenetek garantáltan megérkeznek). Felmerülı problémák: A hagyományos Postán keresztül történı üzenetváltások nagyon lelassítják az eljárást. Az üzenetváltások biztonsága nehezen garantálható. Kiss László aláírást könnyő hamisítani. Az Y hivatal a K.L. Y hivatalbeli azonosító alapján tudja megválaszolni, hogy Kiss Lászlónak hány gyermeke van. Ezt az azonosítót nem szabadna megtudnia az X hivatalnak az adatvédelmi törvények alapján. Az X hivatalt semmi sem gátolja abban, hogy Kiss László felhatalmazása nélkül, akár többször is lekérdezze gyermekei számát (akár más ügyekben) A mintaeljárásban megjelenı szolgáltatások A mintaeljárásban négy szereplıt különböztethetünk meg: Kiss László, X hivatal, Y hivatal, Posta. Közülük az utolsó hármat szolgáltatónak nevezzük, mivel alapvetıen szolgáltatásokat nyújtanak egymásnak. Kiss Lászlót ügyfélnek tekintjük, de rövid idıre ı is kerül szolgáltatói szerepbe az eljárásban. Az egyes szereplık által nyújtott szolgáltatásokat a 12. ábra szemlélteti. 12. ábra - A mintaeljárás szereplıi által nyújtott szolgáltatások A Posta által nyújtott szolgáltatást alacsonyabb szintőnek mondható, mivel az eljárás szempontjából csak a többi szolgáltató közötti kommunikációt biztosítja. A mintaeljárás nem változna meg, ha például a hagyományos Postát leváltanánk egy telefonvonalakon kialakított hálózatra, ahol fax gépekkel történne meg az üzenetek cseréje. (Természetesen a kommunikációs csatorna biztonsága, megbízhatósága és gyorsasága eltér a különbözı megoldásoknál.) BME Informatikai Központ 66

67 6.3. Az architektúrán megvalósított mintaeljárás bemutatása a szolgáltatási rétegig A mintaeljárásban megjelenı szereplık és szolgáltatások ismeretében az eljárás könnyen áthelyezhetı az architektúrára. A mintaeljárás architektúrán való megvalósításához a következıket kell figyelembe venni: A Posta szolgáltatást nem kell megvalósítani, mivel azt az architektúra alsó négy rétege (jobb minıségben) biztosítja számunkra. Az X hivatal és az Y hivatal szolgáltatókként jelennek meg a rendszerben. Kiss János ügyfél a rendszerben, akinek az Ügyfélkapu alapszolgáltató biztosítja a rendszerhez való hozzáférést. Az Ügyfélkapu Ügyindítás szolgáltatása biztosítja egy állampolgárnak az ügyek indítását. Az Ügyfélkapu Hivatalos levél fogadása szolgáltatása alkalmas az állampolgárok értesítésére. Célszerő mindenhol aszinkron hívásokban gondolkodni. Ha szinkron jellegő hívásra van szükség, akkor az egyszerően megtehetı azzal, hogy rögtön a hívás után várakoztatjuk a cselekményt a válaszra. Olyan szolgáltatáshívásnál, ahol választ vár a cselekmény, mindig át kell adni a következı információkat a hívott szolgáltatásnak: o annak a szolgáltatásnak a nevét, ahova a választ várjuk, o annak a cselekménynek a nevét, aki a kérést indította, o a kérés azonosítóját. Az eljárás mőködését a szolgáltatási rétegig a 13. ábra szemlélteti. Azokra a lépésekre, amelyek az állampolgár ügyfélkapura történı bejelentkezésére, illetve a leveleinek a saját hivatalos postaládájából történı kivételére (olvasására) vonatkoznak, nem térünk ki. BME Informatikai Központ 67

68 13. ábra - A mintaeljárás bemutatása a szolgáltatási rétegig Az eljárás lépéseit az 1. táblázat ismerteti. 1. táblázat - A mintaeljárás lépései a szolgáltatási rétegig Lépés Leírás 1. Kiss László meghívja az Ügyfélkapu Ügyindítás szolgáltatását, melynek átadja a következı adatokat: Indítandó szolgáltatás neve: Kérvény beadása Kérvény: K.L. kérvénye Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója 2. Az ügy kiszolgálására az Ügyfélkapun új cselekmény jön létre CS-Ü01 azonosítóval. 3. A CS-Ü01 cselekmény meghívja az X hivatal Kérvény fogadása szolgáltatását átadva neki a következı adatokat: Kérést küldı cselekmény azonosítója: CS-Ü01 Kérés azonosítója: CS-Ü01-K02 Kérvény: K.L. kérvénye Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója Állampolgár ügyfélkapu-azonosítója: K.L. ügyfélkapu azonosítója 4. Az X hivatalon új cselekmény jön létre CS-A01 azonosítóval. 5. A CS-A01 cselekmény leellenırzi, hogy a kérvény beadható-e. Ehhez meghívja az Y hivatal Egy állampolgár gyermekeinek számának lekérdezése szolgáltatását, melynek átadja a következı adatokat: Válasz szolgáltatás neve: X hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Y azonosító: K.L. Y azonosítója 6. Az Y hivatalon új cselekmény jön létre CS-N01 azonosítóval. 7. A CS-N01 cselekmény kikeresi Kiss László gyermekeinek számát, majd meghívja az X hivatal Válaszüzenet fogadása szolgáltatását, melynek átadja a következı adatokat: Kérést küldı cselekmény azonosítója: CS-A01 BME Informatikai Központ 68

69 Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 8. Az X hivatal Válaszüzenet fogadása szolgáltatása a Kérést küldı cselekmény azonosítója alapján a következı adatokat továbbítja a CS-A01 cselekményhez: Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 9. A CS-A01 cselekmény jogosnak ítéli és elfogadja a kérvényt. Az állampolgár értesítéséhez meghívja az Ügyfélkapu Levél küldése állampolgárnak szolgáltatását, melynek átadja a következı adatokat: Állampolgár ügyfélkapu-azonosítója: K.L. ügyfélkapu azonosítója Üzenet: Az Ön kérvényét elfogadtuk. 10. Az Ügyfélkapu Levél küldése állampolgárnak szolgáltatása továbbítja a kérvény elfogadásáról szóló üzenetet Kiss László személyes postaládájába Az architektúrán megvalósított mintaeljárás bemutatása az átviteli csatorna rétegig Az elızı fejezetben bemutatott eljárásban a cselekmények szolgáltatáshívásait, azaz a szolgáltatók közötti kommunikációt megoldottnak tekintettük. Annyit mondtunk róla, hogy azt az architektúra alsó négy rétege biztosítja. Ezeknek a rétegeknek a mőködését az 14. ábra szemlélteti, amely bemutatja az X hivatal és Y hivatal közötti kérés-választ megvalósító két szolgáltatáshívást egészen a csomagátviteli rétegig. Ez az elızıleg bemutatott eljárás 5., 6., 7., 8. lépése. BME Informatikai Központ 69

70 14. ábra Kérés-válasz az X hivatal és a Y hivatal között Az eljárás lépéseit a BME Informatikai Központ 70

71 2. táblázat ismerteti. BME Informatikai Központ 71

72 Lépés 5a 5b 5c 2. táblázat - A mintaeljárás lépései a csomagátviteli rétegig Leírás A CS-A01 cselekmény Kiss László gyermekeinek számának lekérdezéséhez üzenetet készít, melyet átad az X csomagküldınek a meghívandó szolgáltatás nevével (Y hivatal Egy állampolgár gyermekeinek számának lekérdezése) együtt. Az üzenet tartalma a következı: Válasz szolgáltatás neve: X hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója Az X csomagküldı csomagot készít, amely a következıket tartalmazza: Feladó: - Címzett: - Címzett szolgáltatás: Y hivatal Egy állampolgár gyermekeinek számának lekérdezése Üzenet: Válasz szolgáltatás neve: X hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója Az X csomagküldı meghívja az X csatoló send metódusát, melynek paraméterül adja a csomagot. Az X csatoló kikeresi, hogy a meghívandó szolgáltatás, melyik csatolón keresztül érhetı el ( Y csatoló ). Kitölti a csomag feladó és címzett mezıit, így a csomag a következıket tartalmazza: Feladó: X csatoló Címzett: Y csatoló Címzett szolgáltatás: Y hivatal Egy állampolgár gyermekeinek számának lekérdezése Üzenet: Válasz szolgáltatás neve: X hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója Végül a csomagot elhelyezi az X (kimenı) csomagtárába. 5d, 5e A csomagcsatorna kiveszi a csomagot az X (kimenı) csomagtárából, majd eljuttatja az Y (bejövı) csomagtárába. 5f Az Y csatoló észleli, hogy csomag érkezett a tárolóba, melyrıl értesítést küld az Y csomagfogadónak. A Y csomagfogadó meghívja az Y csatoló receive metódusát, amelyre a következı tartalmú csomagot kapja: Feladó: X csatoló Címzett: Y csatoló Címzett szolgáltatás: Y hivatal Egy állampolgár gyermekeinek számának lekérdezése Üzenet: Válasz szolgáltatás neve: X hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója 5g A Y csomagfogadó továbbítja a címzett szolgáltatásnak (Y hivatal Egy állampolgár gyermekeinek számának lekérdezése) az üzenetet, amely a következı: Válasz szolgáltatás neve: X hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója 6 Az Y hivatalon új cselekmény jön létre CS-N01 azonosítóval. BME Informatikai Központ 72

73 7a 7b A CS-N01 cselekmény Kiss László gyermekeinek számának megválaszolásához üzenetet készít, melyet átad az Y csomagküldınek a meghívandó szolgáltatás nevével (X hivatal Válaszüzenet fogadása) együtt. Az üzenet tartalma a következı: Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 Az Y csomagküldı csomagot készít, amely a következıket tartalmazza: Feladó: - Címzett: - Címzett szolgáltatás: X hivatal Válaszüzenet fogadása Üzenet: Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 Az Y csomagküldı meghívja az Y csatoló send metódusát, melynek paraméterül adja a csomagot. 7c Az Y csatoló kikeresi, hogy a meghívandó szolgáltatás, melyik csatolón keresztül érhetı el (X csatoló). Kitölti a csomag feladó és címzett mezıit, így a csomag a következıket tartalmazza: Feladó: Y csatoló Címzett: X csatoló Címzett szolgáltatás: X hivatal Válaszüzenet fogadása Üzenet: Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 Végül a csomagot elhelyezi az Y (kimenı) csomagtárába. 7d, 7e A csomagcsatorna kiveszi a csomagot az Y (kimenı) csomagtárából, majd eljuttatja a X (bejövı) csomagtárába. 7f Az X csatoló észleli, hogy csomag érkezett a tárolóba, melyrıl értesítést küld az X csomagfogadónak. Az X csomagfogadó meghívja az X csatoló receive metódusát, amelyre a következı tartalmú csomagot kapja: Feladó: Y csatoló Címzett: X csatoló Címzett szolgáltatás: X hivatal Válaszüzenet fogadása Üzenet: Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 7g Az X csomagfogadó továbbítja a címzett szolgáltatásnak (X hivatal Válaszüzenet fogadása) az üzenetet, amely a következı: Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 8 Az X hivatal Válaszüzenet fogadása szolgáltatása a Kérést küldı cselekmény azonosítója alapján a következı adatokat továbbítja a CS-A01 cselekményhez: Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 Az elızıleg bemutatott lépéssor mintát mutat az eljárás összes többi szolgáltatáshívásának megvalósítására is. A mintaeljárás végrehajtásakor szerephez jutó összes elem megjelenítésére az 15. ábra szolgál. BME Informatikai Központ 73

74 15. ábra - Az eljárás végrehajtásában részt vevı összes elem Megoldott problémák: A hagyományos Postán keresztül történı üzenetváltások nagyon lelassítják az eljárást. Az üzenetváltások biztonsága nehezen garantálható. Felmerülı problémák: Kiss László aláírást könnyő hamisítani. Az Y hivatal a K.L. Y hivatalbeli azonosító alapján tudja megválaszolni, hogy Kiss Lászlónak hány gyermeke van. Ezt az azonosítót nem szabadna megtudnia az X hivatalnak az adatvédelmi törvények alapján. BME Informatikai Központ 74

75 Az X hivatalt semmi sem gátolja abban, hogy Kiss László felhatalmazása nélkül, akár többször is lekérdezze gyermekei számát (akár más ügyekben) A mintaeljárás megvalósítása a hazai adatvédelmi törvények figyelembevételével Az elızı fejezetben több olyan problémát is megneveztünk, amelyekre még nem adtunk megoldást a mintaeljárás architektúrán történt megvalósításával. Ezek a következık: Kiss László aláírást könnyő hamisítani. Az Y hivatal a K.L. Y hivatalbeli azonosító alapján tudja megválaszolni, hogy Kiss Lászlónak hány gyermeke van. Ezt az azonosítót nem szabadna megtudnia az X hivatalnak az adatvédelmi törvények alapján. Az X hivatalt semmi sem gátolja abban, hogy Kiss László felhatalmazása nélkül, akár többször is lekérdezze gyermekei számát (akár más ügyekben). A feladatok megoldásához igénybe vesszük az architektúra Tokenszolgáltató és Hitelesítı alapszolgáltatásait. Az eljárást a 16. ábra szemlélteti. 16. ábra - A mintaeljárás a hazai adatvédelmi törvények figyelembevételével Az eljárás lépéseit a 3. táblázat ismerteti. BME Informatikai Központ 75

76 3. táblázat A mintaeljárás lépései az adatvédelmi törvények figyelembevételével Lépés Leírás 1. Kiss László meghívja az Ügyfélkapu Ügyindítás szolgáltatását, melynek átadja a következı adatokat: Indítandó szolgáltatás neve: Kérvény beadása Kérvény: K.L. kérvénye digitálisan aláírva Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója digitálisan aláírva 2. Az ügy kiszolgálására az Ügyfélkapun új cselekmény jön létre CS-Ü01 azonosítóval. 3. A CS-Ü01 meghívja a Tokenszolgáltató Token készítés szolgáltatását, melynek a következı adatokat adja át: Válasz szolgáltatás neve: Ügyfélkapu Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-Ü01 Kérés azonosítója: CS-Ü01-K01 Titkosítandó adat: K.L. Y hivatalbeli azonosítója digitálisan aláírva Idıkorlát: 6 óra Publikus kulcs: Az Y hivatal publikus kulcsa 4. A Tokenszolgáltatón új cselekmény jön létre CS-T01 azonosítóval. 5. A CS-T01 az idıkorláttal együtt titkosítja Kiss László Y hivatalbeli azonosítóját, majd meghívja az Ügyfélkapu Válaszüzenet fogadása szolgáltatását, melynek a következı adatokat adja át: Kérést küldı cselekmény azonosítója: CS-Ü01 Kérés azonosítója: CS-Ü01-K01 Titkosított adat: K.L. Y hivatalbeli azonosítója digitálisan aláírva, a Tokenszolgáltatóval tikosítva 6. Az Ügyfélkapu Válaszüzenet fogadása szolgáltatása a Kérést küldı cselekmény azonosítója alapján a következı adatokat továbbítja a CS-Ü01 cselekményhez: Kérés azonosítója: CS-Ü01-K01 Titkosított adat: K.L. Y hivatalbeli azonosítója digitálisan aláírva, a Tokenszolgáltatóval tikosítva 7. A CS-Ü01 cselekmény azonosítja a kérésazonosító alapján a választ, majd meghívja az X hivatal Kérvény fogadása szolgáltatását átadva neki a következı adatokat: Kérést küldı cselekmény azonosítója: CS-Ü01 Kérés azonosítója: CS-Ü01-K02 Kérvény: K.L. kérvénye digitálisan aláírva Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója digitálisan aláírva, a Tokenszolgáltatóval tikosítva Állampolgár ügyfélkapu-azonosítója: K.L. ügyfélkapu azonosítója az ügyfélkapu által titkosítva Állampolgár publikus kulcsa: K.L. publikus kulcsa 8. Az X hivatalon új cselekmény jön létre CS-A01 azonosítóval. 9. A CS-A01 cselekmény leellenırizteti, hogy a kapott Kérvény hiteles-e. Ehhez meghívja a Hitelesítı Hitelesség ellenırzés szolgáltatását, melynek átadja a következı adatokat: Válasz szolgáltatás neve: X hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K01 Ellenırzendı adat: K.L. kérvénye digitálisan aláírva Publikus kulcs: K.L. publikus kulcsa 10. A Hitelesítın új cselekmény jön létre CS-H01 azonosítóval. 11. A CS-H01 hitelesnek minısíti a kérvényt. Meghívja az X hivatal Válaszüzenet fogadása szolgáltatását, melynek átadja a következı adatokat: Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K01 Hiteles: Igen 12. Az X hivatal Válaszüzenet fogadása szolgáltatása a Kérést küldı cselekmény azonosítója alapján a következı adatokat továbbítja az CS-A01 cselekményhez: Kérés azonosítója: CS-A01-K01 BME Informatikai Központ 76

77 Hiteles: Igen 13. A CS-A01 cselekmény leellenırzi, hogy a kérvény beadható-e. Ehhez meghívja az Y hivatal Egy állampolgár gyermekeinek számának lekérdezése szolgáltatását, melynek átadja a következı adatokat: Válasz szolgáltatás neve: X hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Állampolgár Y hivatalbeli azonosítója: K.L. Y hivatalbeli azonosítója digitálisan aláírva, a Tokenszolgáltatóval tikosítva Állampolgár publikus kulcsa: K.L. publikus kulcsa 14. Az Y hivatalon új cselekmény jön létre CS-N01 azonosítóval. 15. A CS-N01 cselekmény meghívja a Tokenszolgáltató Token ellenırzés szolgáltatását a K.L Y hivatalbeli azonosító kititkosításához, melynek a következı adatokat adja át: Válasz szolgáltatás neve: Y hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-N01 Kérés azonosítója: CS-N01-K01 Kititkosítandó adat: K.L. Y hivatalbeli azonosítója digitálisan aláírva, a Tokenszolgáltatóval tikosítva Publikus kulcs: Y hivatal publikus kulcsa 16. A Token szolgáltatón új cselekmény jön létre CS-T02 azonosítóval. 17. A CS-T02 kititkosítja a T1 adatot, majd meghívja a Y hivatal Válaszüzenet fogadása szolgáltatását, melynek átadja a következı adatokat: Kérést küldı cselekmény azonosítója: CS-N01 Kérés azonosítója: CS-N01-K01 Kititkosított adat: K.L. Y hivatalbeli azonosítója digitálisan aláírva 18. A Y hivatal Válaszüzenet fogadása szolgáltatása a Kérést küldı cselekmény azonosítója alapján a következı adatokat továbbítja a CS-N01 cselekményhez: Kérés azonosítója: CS-N01-K01 Kititkosított adat: K.L. Y hivatalbeli azonosítója digitálisan aláírva 19. A CS-N01 cselekmény lellenırizteti, hogy a kapott K.L. Y hivatalbeli azonosító hiteles-e. Ehhez meghívja a Hitelesítı Hitelesség ellenırzés szolgáltatását, melynek átadja a következı adatokat: Válasz szolgáltatás neve: Y hivatal Válaszüzenet fogadása Kérést küldı cselekmény azonosítója: CS-N01 Kérés azonosítója: CS-N01-K02 Ellenırzendı adat: K.L. Y hivatalbeli azonosítója digitálisan aláírva Publikus kulcs: K.L. publikus kulcsa 20. A Hitelesítın új cselekmény jön létre CS-H02 azonosítóval. 21. A CS-H02 hitelesnek minısíti a K.L Y hivatalbeli azonosítót. Meghívja a Y hivatal Válaszüzenet fogadása szolgáltatását, melynek átadja a következı adatokat: Kérést küldı cselekmény azonosítója: CS-N01 Kérés azonosítója: CS-N01-K02 Hiteles: Igen 22. A Y hivatal Válaszüzenet fogadása szolgáltatása a Kérést küldı cselekmény azonosítója alapján a következı adatokat továbbítja az CS-N01 cselekményhez: Kérés azonosítója: CS-N01-K02 Hiteles: Igen 23. A CS-N01 cselekmény kikeresi Kiss László gyermekeinek számát, majd meghívja az X hivatal Válaszüzenet fogadása szolgáltatását, melynek átadja a következı adatokat: Kérést küldı cselekmény azonosítója: CS-A01 Kérés azonosítója: CS-A01-K02 Gyermekek száma: Az X hivatal Válaszüzenet fogadása szolgáltatása a Kérést küldı cselekmény azonosítója alapján a következı adatokat továbbítja a CS-A01 cselekményhez: Kérés azonosítója: CS-A01-K02 Gyermekek száma: 2 BME Informatikai Központ 77

78 25. A CS-A01 cselekmény jogosnak ítéli és elfogadja a kérvényt. Az állampolgár értesítéséhez meghívja az Ügyfélkapu Levél küldése állampolgárnak szolgáltatását, melynek átadja a következı adatokat: Állampolgár ügyfélkapu-azonosítója: K.L. ügyfélkapu azonosítója az ügyfélkapu által titkosítva Üzenet: Az Ön kérvényét elfogadtuk. 26. Az Ügyfélkapu Levél küldése állampolgárnak szolgáltatása továbbítja a kérvény elfogadásáról szóló üzenetet Kiss László személyes postaládájába. 7. Fejlesztési eszközök és technológiák Jelen fejezet ismerteti a projekt során megvizsgált fontosabb SOA eszközöket, technológiákat és termékeket A vizsgált SOA eszközök Web-szolgáltatás API-k A WS-* protokollok nem API, hanem üzenetszinten szabványosak, emiatt a különbözı gyártók különbözı API-kat és implementációkat dolgoztak ki a szabványok támogatására. Ebben a szakaszban a.net és a Java világban elérhetı a fontosabb API-k tulajdonságait tekintjük át. Egyéb környezetek (pl. PHP) is rendelkeznek web-szolgáltatás API-val, azonban ezek tárgyalásától eltekintünk Windows Communication Foundation (WCF) A Windows Communication Foundation [17] (a továbbiakban WCF) réteges csatornamodellen alapuló kommunikációt valósít meg. A csatornaszerkezetet többszintő factory tervezési minta szerint lehet példányosítani, így szükség esetén több ugyanolyan típusú csatornapéldány is létrehozható. Ezeknek nincs közös állapotuk, így több szálon futtathatók. A rétegszerkezet három típusú réteget különböztet meg, mindegyik lecserélhetı egy saját változatra. A legalsó mindig egy transzportréteg, amely az üzenet átviteléért felelıs. A.NET keretrendszerben a következık vannak implementálva: HTTP, HTTPS, MSMQ, TCP, neves csıvezetékek és Peer-to-Peer. A transzportréteg felett mindig egy kódoló/dekódoló réteg található, ez transzformál a magas absztrakciós szintő objektumstruktúra és a vezetéken átvitt üzenetreprezentáció között. Jelenleg a szöveges XML, az MTOM és a bináris kódolás van implementálva. Az elsı kettı interoperábilis más platformokkal, az utolsó csak.net-en belül mőködik, de sokkal hatékonyabb, mint az elıbbiek. A kötelezıen megadandó transzport és kódoló/dekódoló réteg felett opcionálisan egyéb üzenetfeldolgozó rétegek is szerepelhetnek. Ezek felelısek az egyes WS-* protokollok implementálásáért, de itt is készíthetı saját megoldás. Az egyes rétegek tetszılegesen összeválogathatók, így egy új csatorna (pl. JMS) implementálásakor is felhasználhatók azok a rétegek, amelyek a WS-* protokollokat implementálják. BME Informatikai Központ 78

79 Alkalmazásszinten az osztályokat és interfészeket a megfelelı.net attribútumokkal kell ellátni, valamint egy konfigurációs fájlban le kell írni, hogy a hívásokat milyen rétegszerkezeten keresztül kell továbbítani illetve fogadni. Ennek köszönhetıen a protokoll változásakor elegendı a konfigurációs fájlon módosítani, a programkód változatlan maradhat Java API for XML-based RPC (JAX-RPC) A Java API for XML-based RPC [27] (a továbbiakban JAX-RPC) specifikáció azt definiálja, hogy a forráskód portolhatóságának megırzése mellett hogyan lehet Java hívásokat SOAP hívásokká leképezni, valamint a normál Java osztályok miképpen alakíthatók át WSDL-lé. Az osztályokhoz ún. deployment metaadatok is tartoznak, amelyek alapján a szolgáltatás alkalmazásszerverre történı telepítésekor létrejönnek a gyártóspecifikus csomagolóosztályok, hogy az adott implementáció futtatni tudja a szolgáltatásokat. Az üzenetek alkalmazásszintő transzformálásához ún. Handler-eket lehet definiálni, amelyek az üzenet elküldése elıtt illetve vétele után futnak le, így módosíthatnak az üzenet szerkezetén. Azonban ez csak SOAP szinten támogatott, magasabb absztrakciós szintő üzenetreprezentáció nem áll rendelkezésre. Csak a HTTP feletti SOAP binding van specifikálva, amely erısen korlátozza a bıvíthetıséget és a portolhatóságot. A JAX-RPC további hátránya a WS-* szabványok támogatásának hiánya, ezt minden gyártónak saját magának kell API szinten definiálnia és implementálnia, amelynek eredményeként a konfigurációs fájlok teljesen eltérı felépítésőek lettek. Ez pedig a portolhatóságot nagymértékben akadályozza. A programkódban JAX-RPC esetén egy osztályról nem dönthetı el, hogy az egy szolgáltatás vagy egy normál Java osztály. A deployment metaadatokban van leírva, hogy melyik osztályhoz kell a megfelelı csomagolókat generálni Java API for XML-based Web-Services (JAX-WS) A Java API for XML-based Web-Services [28] (a továbbiakban JAX-WS) specifikáció a JAX-RPC 2.0-ás változata új néven. Javítottak a Java típusok és az XML típusok közti megfeleltetésen, ezt a Java Architecture for XML Binding [JaxbJsr] (a továbbiakban JAXB) definiálja, amely már az összetettebb típusokat is képes kezelni. Alkalmazásszinten a szolgáltatásokat implementáló osztályokat a deployment metaadatok mellett Java annotációkkal is el lehet látni (sıt érdemes így tenni), ezáltal könnyebben paraméterezhetı a WSDL leképzés. A WSDL-ek konfigurációs fájlként is szolgálhatnak, azonban néhány paraméter továbbra is gyártóspecifikus maradt (pl. tanúsítványok megadása). A JAX-WS egyik célja az is, hogy jobban szétválassza az XML üzenetreprezentációt a transzportrétegtıl, így a HTTP-n kívül más átviteli csatornák támogatása egyszerőbbé válik, azonban ezeket a JAX-WS nem specifikálja. A WS-* szabványok támogatása továbbra is az ún. Handler-ekre hárul. Ezek kiválasztása és sorrendje kliensoldalon csak programkód szinten specifikált, szerveroldalon ezt a feladatot a deployment metaadatok látják el. A JAX-WS ez utóbbira csak egy ajánlást ad [30], amely továbbra is csak a HTTP vagy a HTTPS feletti SOAP-ot támogatja. Minden egyéb WS-* szabványra specifikus beállítás gyártófüggı konfigurációkat eredményez. Ezt ugyan igyekeznek csökkenteni (pl. az MTOM kódolás része a JAX-WS-nek, a WS-Addressing BME Informatikai Központ 79

80 támogatás a 2.1-es verzióba bekerült), azonban a teljes WS-* protokollhalmaz lefedése még távolinak tőnik SOA eszközök Az alábbiakban a jelentısebb gyártók SOA eszközeinek fontosabb tulajdonságai kerülnek bemutatásra, melyeket az 1. táblázat foglal össze. Ezen kívül az egyes eszközökre specifikus, telepítéskor és fejlesztéskor felmerülı problémák és megoldásuk is megtalálható ebben a szakaszban. 4. táblázat - A fontosabb gyártók SOA eszközeinek fıbb tulajdonságai Eszköz.NET 3.0 OpenESB Oracle SOA Suite IBM WebSphere Gyártó Microsoft Sun Oracle IBM Fejlesztıkörnyezet Visual Studio Netbeans JDeveloper IBM RAD, WID Alkalmazásszerver IIS GlassFish Oracle AS IBM WebSphere WS API WCF JAX-RPC, JAX- WS JAX-RPC, JAX- WS WS-* támogatás igen igen a 11g verzióban igen BPEL támogatás WF vagy BizTalk igen igen igen JAX-RPC, JAX- WS Microsoft:.NET 3.0 A Microsoft a.net 3.0-ás [31] verziójában mutatta be a web-szolgáltatások készítéséhez kifejlesztett Windows Communication Foundation-t [32], és az üzleti folyamatokat megvalósító Windows Workflow Foundation-t (a továbbiakban WF). Ez utóbbi egy külön letölthetı kiegészítéssel BPEL futtatására is alkalmas [33], azonban ez még csak egy eléggé instabil elızetes változat. A jelenleg BPEL támogatással rendelkezı BizTalk szerver átírása WF alapúra folyamatban van. A WCF támogatja a legtöbb WS-* szabványt, könnyen bıvíthetı, így viszonylag egyszerően lehet új rétegeket írni a csatorna modelljébe. A WCF és a WF egymással kombinálhatók is, így üzleti folyamatok esetében is alkalmazhatók a WS-* protokollok. Fejlesztıkörnyezetnek a Visual Studio 2008, a szolgáltatások futtatásához az Internet Information Services (a továbbiakban IIS) szerver használható Sun: OpenESB A Sun által támogatott nyílt forráskódú fejlesztés az OpenESB [35], melynek alkalmazásszervere a GlassFish [36]. A JAX-WS típusú web-szolgáltatások referencia implementációja a Metro [37][Metro], a GlassFish egyik komponense, amely már a JDK 6- nak is része. Az OpenESB felügyeleti funkciókat és BPEL futtatási lehetıséget is biztosít. Külön figyelmet fordítanak a WS-* szabványok alapján a WCF-fel történı együttmőködésre a WSIT (Web Services Interoperability Technologies) [38] [39] keretében, amely ugyancsak a Metro projekt része. Ennek köszönhetıen a legtöbb WS-* szabvány támogatott. A webszolgáltatások és a BPEL folyamatok megvalósításához a Netbeans fejlesztıkörnyezet használható; ebben könnyen paraméterezhetık az alkalmazott WS-* protokollok is. BME Informatikai Központ 80

81 Oracle: SOA Suite Az Oracle SOA Suite [40] környezet tartalmaz egy alkalmazásszervert web-szolgáltatások és a BPEL folyamatok futtatásához, valamint különbözı felügyeleti funkciókat biztosít a webszolgáltatások tesztelésére, és a futó BPEL folyamatok állapotának követésére, megjelenítésére. Az Oracle JDeveloper 10g-vel [42] egyszerően lehet JAX-WS típusú webszolgáltatásokat készíteni, a BPEL folyamatok grafikus és XML tervezıje közötti kétirányú szinkronizáció pedig nagyban javítja a fejlesztés hatékonyságát. A 10g verzió csak a WS- ReliableMessaging és a WS-Security protokollokat támogatja, de a készülı 11g változat melynek elızetes verziója letölthetı már képes lesz a többi WS-* protokoll kezelésére is IBM: WebSphere Az IBM a WebSphere [43] alkalmazásszerverre építi SOA termékeit. Ez alkalmas webszolgáltatások és BPEL folyamatok futtatására, valamint kiterjedt menedzsment funkcionalitással rendelkezik. BPEL folyamatok fejlesztésére a WebSphere Integration Developer, JAX-RPC és JAX-WS típusú web-szolgálasok készítésére a Rational Application Developer használható. A WS-* szabványok támogatásához egy külön patch-et kell feltelepíteni További SOA eszközök A fentieken kívül a következı eszközök képezik vizsgálataink tárgyát: a) Red Hat: JBoss b) BEA: WebLogic c) Axis2 d) Sun: Composite Application Platform Suite 6 e) IONA: FUSE f) Sonic Software: Sonic ESB Jelen rendszerterv elkészültéig ez utóbbi rendszerek vizsgálatára még nem került sor, így értékelhetı gyakorlati tapasztalatunk még nincs Várható bıvítések kezelése Bevezetés A SOA és ESB rendszerek fejlesztésére a keretrendszerekbe a gyártó cégek általában fejlesztı eszközöket is integrálnak. Ez az integráció általában abban nyilvánul meg, hogy az erre a célra kidolgozott felületeken a gyártó által készített architektúrának megfelelı komponenseket kiválasztani, összekötni, valamint a komponenseket és összekötéseket paraméterezni lehet. Az eddig szerzett tapasztalatokból az látszik, hogy a különbözı gyártók által készített megvalósítások inkább több, mint kevesebb munkával interoperábilissá tehetık, viszont ugyanez közel sem mondható el a fejlesztési módszerekrıl. Ugyanazon alkalmazás kifejlesztése teljesen eltérhet különbözı szállítók termékeire történı fejlesztéskor. BME Informatikai Központ 81

82 A közös fejlesztési cél indokolja egy közös fejlesztési technológiai platform létrehozását. Ennek alapjaként az MDA elvet javasoljuk. A fejlesztési folyamatban azonosítani kell az alkalmazásfüggı és alkalmazásfüggetlen, valamint a keretrendszer-függı és keretrendszerfüggetlen részeket. Ezek alapján olyan modelleket és termékeket kell kifejleszteni, amelyek segítségével az eszközökbe betölthetı forráskódok minél nagyobb része automatikusan elıállítható. Ebben a fejezetben röviden áttekintjük a fejlesztés során történı modellezést segítı elvek alapjait (MDA, AOP). A modellekbıl az MDA elveinek megfelelıen elıször eszközfüggetlen kódokat célszerő elıállítani, majd aspektusok szövésével ezekbıl létrehozhatók az eszközspecifikus kódok is. El kell készíteni a megfelelı kódgenerátort is, amely ezt a feladatot el tudja látni. A tanszéken kifejlesztett kódgenerátor keretrendszer erre alkalmas. Két eszköz példáján bemutatjuk azt is, hogy a kódgenerátor miként támogatja a fejlesztést Modell-vezérelt architektúra Ez a szakasz [50] és [51] alapján röviden összefoglalja a modell-vezérelt architektúra (a késıbbiekben: MDA Model Driven Architecture) alapelveit és definiálja a használt fogalmakat. A modell (model) olyan elemek halmaza, amelyek valamely fizikai, absztrakt vagy hipotetikus világot írnak le. A hatékony modellezés kulcsai az absztakció és az osztályozás. Az absztrakció (abstraction) az adott környezet számára érdektelen információk figyelmen kívül hagyása. Az osztályozás (classification) közös tulajdonsággal rendelkezı fontos információk csoportosítása. Az MDA középpontjában a különbözı absztrakciós szintő modellek létrehozása áll és azok összekapcsolása úgy, hogy azok egy implementációt alkossanak. A modellek közül néhány független a szoftver platformoktól míg mások specifikusak egy adott platformra. A platform (platform) a futtatási környezet specifikálása modellek egy halmazára. Platformok például a Java és a.net; illetve a különbözı operációs rendszerek, például Windows és Linux. A platform specifikációjának kell, hogy legyen implementációja, vagyis legalább egy megvalósítása. A metamodell (metamodel) egy modellezési nyelv modellje. Megadja a modellek egy családjának struktúráját, szemantikáját és kényszereit. Például egy UML (Unified Modelling Language) modellt az UML metamodell ír le [54]. Meghatározza az UML modellek szerkezetét, azt, hogy milyen elemeket tartalmazhatnak illetve ezen elemek tulajdonságait. Azonban nem fogalmaz meg feltételeket arról, hogy a modellek hogyan vannak tárolva és hogyan szerkeszthetık. Ezektıl az információktól az UML metamodell elvonatkoztat, mivel ezek az adott absztrakciós szinten nem lényegesek. Az UML metamodellt az OMG (Object Management Group) által szabványosított MOF (MetaObject Facility) meta-metamodell írja le [53]. A MOF definiálja azt is, hogy a különbözı modellekhez milyen módon lehet hozzáférni, valamint hogyan lehet azokat eszközök között cserélni. Erre szolgál az XML Metadata Interchange (XMI) [55] formátum. Általában az UML-t alkalmazzák tervezéshez, mivel szabványosított és a legtöbb eszköz ezt támogatja. Azonban az UML sok esetben nem biztosít elegendı szemantikát vagy megfelelı jelölésrendszert a modellezéshez (például gráfok vagy fák ábrázolásához). Ebben az esetben új nyelveket kell definiálni, amelyek egy adott problématerület feladatainak megoldására alkalmasak. Ezeket domain specifikus nyelveknek (domain-specific language DSL) nevezzük. A MOF általában megfelelı alapul szolgál az ilyen típusú nyelvek definiálásához. BME Informatikai Központ 82

83 A modellek szemantikus kapcsolatban állhatnak más modellekkel is, például, ha modellek egy halmaza egy adott rendszert ír le, különbözı absztrakciós szinteken. Kívánatos dolog az, hogy a magasabb absztrakciós szinttıl az alacsonyabb felé haladva az egyes modellek automatikusan elıállíthatóak legyenek. Egy modellek közti leképzés (mapping) egy vagy több modellt (a források) vár bemeneti paraméterként, kimenetként pedig egyetlen modellt (a cél) állít elı. A transzformáció szabályait a leképzési függvényen (mapping function) belül a leképzési szabályok (mapping rule) adják meg. Maga a leképzés a leképzési függvény alkalmazását jelenti. A leképzési szabályok a metamodell szintjén úgy vannak megfogalmazva, hogy azok minden olyan forrásmodellre alkalmazhatók, amelyek megfelelnek az adott metamodellnek. Bizonyos esetekben a leképzés többféleképpen is megtörténhet. Ahhoz, hogy választani lehessen a különbözı variációk közül, többletinformációra van szükség. Ezt a többletinformációt a markerek (marker) írják le, amelyek a modell egyszerő kiterjesztései. Elegendı információt biztosítanak a transzformációhoz anélkül, hogy beszennyeznék a modellt. A markerek a leképzésnél új bemenetként jelentkeznek. Egy leképzés több különbözı markert használhat és egy marker több leképzés során is felhasználható. Létezhetnek globális markerek is, amelyek nemcsak néhány egyedi modellelemhez kötıdnek. A markerek a leképzésre specifikusak, így nem épülhetnek be a modellbe, különben a modell is specifikus lesz a leképzésre. A markereket a marker modell (marker model) definiálja, amely leírja a markerek típusait, struktúráját és szemantikáját. Egy leképzı függvény meghatározza azokat a marker modelleket, amelyek marker típusaira a forrás modellek esetén szüksége van. Egy leképzı függvény több marker modellt is használhat egyetlen forrásmodellhez, és a marker modellek más transzformációk során is újrahasznosíthatók. 17. ábra A markerek hatása a PIM-bıl PSM-re történı leképzés során ([50] 19. oldal, 2-5. ábra) BME Informatikai Központ 83

84 A leképzések során tehát a különbözı markerek alkalmazása különbözı platformspecifikus modellekhez (PSM Platform Specific Model) vezet (17. ábra). A leképzések bemenete a jelöletlen platformfüggetlen modell (PIM Platform Independent Model), valamint a markerek. A példában az A és B célplatformokra kell a modelleket elkészíteni. A markerek nem közvetlenül a PIM-be épülnek be, így lehetıvé teszik azt, hogy az különbözı PSM-ekre leképezhetı legyen attól függıen, mely markereket választjuk ki. Az elkészült modellek általában nem teljesek, így módosításra szorulnak. Erre szolgál a modell kidolgozása. A modell kidolgozása (model elaboration) azt jelenti, hogy a modell generálás után módosítható. Általában ez abból áll, hogy implementációs kódot adunk a modellhez, de jelentheti magának a generált modellnek a szerkesztését is. Ha a célmodell generálására újra sor kerül, akkor biztosítani kell, hogy a hozzáadott kódot ne írja felül az újragenerált kód. Ezt a legegyszerőbben védett területekkel lehet elérni: ha a forrásmodell egy része védett, akkor a leképzı függvénynek meg kell próbálnia megırizni a manuális kódrészeket. A manuálisan bevitt változások felismerése és azok megırzése a kulcskérdés ezen a területen. A modellek visszafejtése (reverse engineering) és kétirányú szinkronizációja is fontos kérdés. Hasznos lehet egy egyszeri absztraháló leképzés (abstracting mapping) alkalmazása, amely a részletes modellekbıl kigyőjti a változásokat és beviszi azokat az absztrakt modellekbe, hogy azután egy még részletesebb modelleket lehessen generálni. A modellek lehetnek futtathatók is, ami azt jelenti, hogy úgy viselkednek, mint a kész kód, de abban különböznek tıle, hogy össze kell ıket szıni más modellekkel. A futtatható modellek (executable model) tehát minden olyan dolgot tartalmaznak, amely egy adott funkcionalitás megvalósításához szükséges. A modellek összeszövését a modell fordító (model compiler) végzi. Ha minden egyes modell teljesen elkészült, a szövést lefuttatva egy mőködıképes kész rendszert kapunk. Azonban a futtatható modelleknek függetlennek kell lennie a szoftver platformtól, mivel csak így biztosítható azok hordozhatósága. Tehát a modell platformfüggı kódrészletekkel történı kibıvítése nem tekinthetı futtatható modellnek, hiszen az a modell csak az adott platformon lesz futtatható. A futtatható modellekre jó példa a futtatható UML (executable UML). Ez egy profile, amely az UML egy jól megválasztott részhalmazára futtathatósági szemantikát definiál. A részhalmaz számítási szempontból teljes, tehát egy futtatható modell ténylegesen végrehajtható. A futtatható UML a viselkedést definiálja anélkül, hogy megadná az implementációt. A futtatható modellek nagy elınye, hogy azok közvetlenül tesztelhetık. Az MDA folyamat (MDA process) arra ad választ, hogy hogyan jutunk el a magas absztrakciós szintő modelltıl a ténylegesen futtatható kódig. Ez magában foglalja a modellek és a leképzı függvények kiválasztását, amelyeket összeállítva megkapjuk azt a folyamatot, amelyet végre kell hajtani az MDA projekten. A leképezések azon sorozatát, amelyet a magas absztakciós szinttıl az alacsony absztrakciós szint felé haladva alkalmazni kell, leképzési láncnak (mapping chain) nevezzük. Az MDA folyamat elkészítését általában kétféle megközelítés kombinálásával lehet leghatékonyabban elérni. Az egyik arra koncentrál, hogy megtaláljuk a megfelelı absztrakciós szinteket az egyes modellek számára. A másik a leképzési lánc hosszára vonatkozik: meg kell találni az optimális mérető leképzéseket. Ezáltal a leképzı függvények egyszerősödnek és újrahasznosíthatóvá válnak, sıt az egymástól független leképzések tetszıleges sorrendben is végrehajthatók. Az apróbb leképzések során úgynevezett köztes modellek (intermediate model) keletkeznek, míg végül eljutunk a végleges célmodellig. BME Informatikai Központ 84

85 Egy hatékony megközelítés az, ha a rendszert különbözı problématartományokra (problem domain) osztjuk fel. Ezután az egyes témákat tartománydiagramokon (domain chart) ábrázolhatjuk, amelyek az egyes tartományokat és a köztük lévı összeköttetéseket (leképzı függvények, markerek és marker modellek) jelenítik meg. A tartománydiagram képezi az MDA folyamat alapját. Ha elkészült az MDA folyamat, végre lehet hajtani. Ehhez formalizálni kell az egyes problématartományokhoz tartozó tudást, majd el kell készíteni azok implementációját. A tudás formalizálása magában foglalja az adott problématerület számára fontos követelmények összegyőjtését, a megfelelı absztrakciók elvégzését, majd azok formális kifejezését egy modellben. Az MDA az elkészült modell helyességének teszteléséhez nyújt segítséget, amely általában a modell futtatásával történik. Ahogy az egyes modellek egyre jobban összeállnak, a következı lépésként specifikálni és ellenırizni kell a leképzı függvényeket, el kell készíteni a marker modelleket és végül transzformálni kell a modelleket. Ha a modellek el vannak látva markerekkel és a leképzı függvények teljesek, akkor a formalizált tudásból elıállíthatók más modellek, vagy maga a forráskód, amely a rendszer implementációját képezi A MOF és a négy metaszint Ez a szakasz a [53], [50] és [51] alapján röviden ismerteti a MOF négyszintő architektúráját. A metamodell egy modellezési nyelv modellje. Megadja az adott modellezési nyelv elemeinek struktúráját, szemantikáját és kényszereit. Mivel ez a metamodell is egy modellezési nyelv, ezért ennek is van metamodellje, így több metaszint is létezik. A MOF (MetaObject Facility) (1. táblázat) architektúra négy metaszintbıl (metarétegbıl) áll: M3, M2, M1 és M0 (MOF). 5. táblázat - A négyrétegő metamodell-architektúra Metaszint Leírás Elemek M3 A MOF meta-metamodell MOF: Class, Property, Association stb. M2 M1 M0 A MOF által leírt metamodellek: a MOF elemeinek példányaiból állnak Az M2 réteg metamodelljei által leírt modellek: az M2-es metamodellek elemeinek példányai Objektumok és adatok: az M1 réteg elemeinek példányai UML: Class, Property, Association, State, Activity stb. illetve az egyéb domain specifikus nyelvek elemei Szemely nevő osztály (Class), Nev nevő attribútum (Property) stb. Kis János névvel rendelkezı Szemely típusú objektum stb. Az M0 réteg az alkalmazás adatait tartalmazza, például objektumokat vagy egy relációs adatbázis sorait. Az M1 rétegbe tartoznak például az osztályok illetve a relációs adatbázisok tábladefiníciói. Ezen a metaszinten történik az alkalmazás modellezése. Az M2 szint a modellezı nyelvek szintje, ide tartoznak az UML metamodell illetve más domainspecifikus nyelvek elemei. Ezen a szinten mőködnek a modellezı eszközök. Az M3 réteg a modellezı nyelvek metamodellje, ebben van leírva az UML és ezt lehet felhasználni a különbözı domainspecifikus nyelvek definiálásához. Az M3 réteg önleíró, vagyis egyben önmaga metamodellje is, ez tehát a legfelsı metaszint. Az M3 szint csak a legegyszerőbb koncepciókat tartalmazza, amelyek alkalmasak a különbözı metamodellek leírására. Ezeket a koncepciókat szabványosította az OMG a MOF definiálásával. A MOF lényegében az UML egy részhalmazának tekinthetı. BME Informatikai Központ 85

86 A metaszintek számának azonban nem kötelezı négynek lennie. Valójában a lényeg az egyes metaszintek egymáshoz való viszonya, vagyis annak a kifejezése, hogy egy adott réteg az alatta lévırıl mond valamit. Ezek alapján tetszılegesen sok metaszint definiálható úgy, hogy minden egyes szint az alatta lévı metamodellje Aspektus-orientált programozás Ez a szakasz az [57] alapján összefoglalja az aspektus-orientált programozás (Aspect Oriented Programming AOP) alapelveit. A programok forráskódjában a tényleges mőködést megvalósító funkciók mellett egyéb olyan kódokra is szükség van, amelyek feladata nem a tényleges funkcionalitás megvalósítása. Ilyen például a kivételkezelés, a naplózás, a szinkronizáció, a perzisztencia stb. Az AOP terminológiája ezeket az alapvetı funkcionalitáson túlmutató követelményeket vonatkozásoknak (concern), konkrét megvalósításukat pedig aspektusnak (aspect) nevezi. Bár az egyes vonatkozások logikailag jól elkülönülı egységet alkotnak, a problémát az jelenti, hogy a tényleges funkcionalitás és az egyes aspektusok összefonódva jelennek meg a programkódban, az aspektusok elvágják (cross cut) a kódot. Szétválasztásukra a mai programnyelvek sajnos nem nyújtanak támogatást. Az AOP célja, hogy az összefonódó aspektusok és a rendszer funkcionalitásának szétválasztását a lehetı legjobban segítse. Ennek lényege, hogy az egyes vonatkozásokat külön-külön lehessen definiálni, az egyes leírások automatikus összefőzésével pedig elıállítható legyen a ténylegesen mőködı rendszer. Ezt az összefőzést az aspektusszövı (aspect weaver) végzi. Ha az összefésülés futási idıben történik, akkor a szövés dinamikus, különben a szövés statikus. Mivel a mai programnyelvek nem támogatják a programkód futásidıben történı változtatását, ezért a ma alkalmazott aspektusszövık általában statikus összefésülést végeznek. A dinamikus aspektusszövést segíthetik a reflexiót támogató programnyelvek, de ennek alkalmazása nyilvánvalóan a hatékonyság rovására megy. Ahhoz, hogy az aspektusszövı a kód összeállítását el tudja végezni, olyan pontokat kell kijelölni a forráskódban, amelyek mentén az egyes aspektusok kódjai összefésülhetık. Ezeket a pontokat kapcsolódási pontoknak (join point) nevezzük. A meglévı forráskódok különbözı aspektusokkal történı bıvítése általában nehezebb feladat, mint egy új rendszer esetén, ahol a tervezésnél eleve az aspektus-orientált paradigmát is figyelembe veszik. Meglévı Java kódok bıvítését segíti például az AspectJ nevő eszköz. Az általam javasolt kódgenerátor keretrendszer azonban elsısorban az újonnan tervezett rendszereket támogatja aspektusszövés szempontjából. Az egyes vonatkozások szétválasztása (separation of concerns) egyszerőbb feladat, ha azok függetlenek egymástól, vagyis merılegesek (orthogonal) egymásra. Ha azonban az egyes aspektusok között függıségek vannak, akkor komoly problémákba ütközünk mind az aspektusok definiálásánál, mind azok összefésülésénél. Ebben az esetben a cél általában a függés minimalizálása Kódgenerátor-támogatást igénylı komponensek az architektúrában Várhatóan a leggyakoribb fejlesztési feladat egy új szolgáltatás elkészítése lesz, így célszerő ezt kódgenerátorral támogatni. Ehhez olyan megoldást kell találni, amely egy eszközfüggetlen magas absztrakciós szintő modellbıl (pl. UML) indul ki. Egy kódgenerátor ebbıl a modellbıl elıször elıállítja az eszközfüggetlen XSD, WSDL és BPEL kódokat, majd ezeket komplett BME Informatikai Központ 86

87 projektekbe szervezi, amelyek már közvetlenül megnyithatók az egyes eszközökben. Az elıállított kódnak tartalmaznia kell a szolgáltatások megvalósításához illetve azok meghívásához szükséges elemeket úgy, hogy bármely két eszköz között is történjék a kommunikáció, az mőködıképes legyen. Ezek a feladatok az eszközök alapos vizsgálata alapján szerzett tapasztalatokkal megvalósíthatók. Támogatást igényelnek a csatolók és a csomagküldık illetve -fogadók is, bár ezek létrehozására ritkábban van szükség. Amennyiben lehetséges, célszerő ezeket úgy megvalósítani, hogy bárhol alkalmazhatóak legyenek, így egy új szolgáltató felvétele esetén újrahasznosíthatók. Ha erre nincs lehetıség, akkor a kódgenerátor által megvalósított támogatás nagyban megkönnyítheti a munkát. Ehhez meg kell találni a már kialakított komponensekben elıforduló mintákat, el kell készíteni ezek egy alkalmas modelljét, majd létrehozni a fejlesztést segítı kódgenerátort. Lényeges követelmény, hogy az egyes komponensek csak megfelelı tesztelés után helyezhetık üzembe. Ezt nagyban segíti az, ha a kódgenerátor már bizonyítottan helyes kódrészleteket készít, így azokat már nem szükséges újabb alapos teszteknek alávetni. A generátor ezen kívül felhasználható maguknak a funkcionális és nemfunkcionális teszteseteknek az elıállítására is A fejlesztés menete Az alábbiakban a már említett magasszintő modellbıl kiinduló eszközspecifikus kódokat elıállító generátorra épülı fejlesztés kerül ismertetésre. 18. ábra - A fejlesztés menete BME Informatikai Központ 87

88 A fejlesztés menetét a 18. ábra - A fejlesztés menete18. ábra szemlélteti. Új szolgáltatás készítéséhez UML-ben (vagy más domain-specifikus nyelven) le kell írni a szolgáltatás interfészét. A modellt kiexportálva a modellezı eszközbıl kapjuk a modell XMI változatát. Ezt egy kódgenerátor segítségével lehet feldolgozni, majd a kívánt programkódokat elıállítani. A kódgenerátor két részbıl épül fel: egy platformfüggetlen (PIM) és egy platformfüggı (PSM) rész. Itt a platformfüggetlenség SOA-eszközfüggetlenséget jelent. A PIM kódgenerátor szabványos XSD, WSDL és BPEL kódokat állít elı, a PSM kódgenerátor ezeket felhasználva/transzformálva akár az egyes SOA-eszközök saját kódgenerátorait is meghívva elkészíti az eszközökben közvetlenül felhasználható kódokat, akár komplett projekteket is. A PSM kódgenerátor képes arra is, hogy a korábban már módosított fájlokból átemelje az újragenerált kódba a programozó által készített elemeket. Minderre a tanszéken kifejlesztett kódgenerátor keretrendszer alkalmas. Az alábbiakban bemutatjuk, hogy a kódgenerátor miként tudja támogatni például a.net-tel és az OpenESB-vel történı fejlesztést. A kódgenerátor természetesen alkalmas a más eszközökkel való fejlesztés segítésére is. A példákban két segédeszköz fog szerepelni: SvcUtil és wsimport. Elıbbi a.net keretrendszer része, utóbbi a WSIT-vel együtt érkezik. Mindkettı feladata, hogy egy WSDLbıl elıállítsa a kliensoldali proxy-kat, amelyekkel a WSDL-ben leírt szolgáltatás meghívható. Az eszközök elınye, hogy melléktermékként elıállítják magának a szolgáltatásnak a C# illetve Java interfészét, amelyet implementálva a szerveroldali szolgáltatás is elkészíthetı Szolgáltatás készítése.net esetén 19. ábra - Szolgáltatás készítése.net-ben Jelmagyarázat: kék automatikusan generálható, piros manuálisan kell megírni A kékkel jelölt elemeket a generátor állítja elı. A Service.wsdl a PIM generátor terméke, a Service.svc a PSM generátoré. Az SvcUtil-t is a PSM generátor hívja meg, automatikusan, amely elıállítja az IService interfészt (IService.cs) és a web.config konfigurációs fájlt. A szerverben az IService interfészt implementálva egyedül a Service osztályt (Service.cs) kell BME Informatikai Központ 88

89 manuálisan elkészíteni ahhoz, hogy egy telepíthetı szolgáltatást kapjunk. Ebben kell megvalósítani a legacy rendszerhez való hozzáférést, pl. egy tárolt eljárás meghívását egy adatbázison. Ez azonban már a jól megszokott módon történik. Tanúsítványok hozzárendeléséhez, és az egyéb viselkedések finomhangolásához szükség lehet a web.config manuális módosítására is. A kódgenerátornak alkalmasnak kell lennie ahhoz, hogy ezeket a változásokat egy esetleges újrageneráláskor átemelje az új kódba. Az ábra felsı részén a tevékenység fordítási idejő leírása (a forráskódok) találhatók. Az alsó rész a tevékenységek lefordított, közvetlenül futtatható leírását jelöli. Itt található maga a szolgáltatás is, amely factory-ként létrehozza a tevékenység példányait, a kéréseket kiszolgáló cselekményeket Szolgáltatás készítése OpenESB esetén 20. ábra - Szolgáltatás készítése OpenESB-ben Jelmagyarázat: kék automatikusan generálható, piros manuálisan kell megírni A kékkel jelölt elemeket a generátor állítja elı. A Service.wsdl a PIM generátor terméke, a Service-client.xml és a többi *.xml konfigurációs fájl a PSM generátoré. Az wsimport-ot is a PSM generátor hívja meg, automatikusan, amely elıállítja az IService interfészt (IService.java). A szerverben az IService interfészt implementálva egyedül a Service osztályt (Service.java) kell manuálisan elkészíteni ahhoz, hogy egy telepíthetı szolgáltatást kapjunk. Ebben kell megvalósítani a legacy rendszerhez való hozzáférést, pl. egy tárolt eljárás meghívását egy adatbázison. Ez azonban már a jól megszokott módon történik. Tanúsítványok hozzárendeléséhez, és az egyéb viselkedések finomhangolásához szükség lehet a konfigurációs fájlok manuális módosítására is. A kódgenerátornak alkalmasnak kell lennie ahhoz, hogy ezeket a változásokat egy esetleges újrageneráláskor átemelje az új kódba. Az ábra felsı részén a tevékenység fordítási idejő leírása (a forráskódok) találhatók. Az alsó rész a tevékenységek lefordított, közvetlenül futtatható leírását jelöli. Itt található maga a szolgáltatás is, amely factory-ként létrehozza a tevékenység példányait, a kéréseket kiszolgáló cselekményeket. BME Informatikai Központ 89

90 Szolgáltatás meghívása.net-bıl 21. ábra - Kliens készítése.net-ben Jelmagyarázat: kék automatikusan generálható Kliens készítéséhez a Service.wsdl-re van szükség. Ebbıl az SvcUtil (a PSM kódgenerátor részeként) elıállítja a szükséges konfigurációs fájlt (app.config), a szolgáltatás C# interfészét (IService.cs) és egy proxy osztályt (ServiceClient.cs), amelyek segítségével a szolgáltatás közvetlenül meghívható, így az akár egy másik szolgáltatás implementációjának részeként közbülsı lépésként is felhasználható Szolgáltatás meghívása OpenESB-bıl 22. ábra - Kliens készítése OpenESB-ben Jelmagyarázat: kék automatikusan generálható Kliens készítéséhez a Service.wsdl-re és egy Service-client.xml nevő konfigurációs fájlra van szükség. Ebbıl a wsimport (a PSM kódgenerátor részeként) elıállítja a szükséges konfigurációs fájlokat (*.xml), a szolgáltatás Java interfészét (IService.java) és egy proxy osztályt (ServiceClient.java), amelyek segítségével a szolgáltatás közvetlenül meghívható, így az akár egy másik szolgáltatás implementációjának részeként közbülsı lépésként is felhasználható Modell az integrációra Az eszközök kipróbálása során szerzett tapasztalatainkat ez a szakasz foglalja össze. Egy eszközkörnyezeten belül a csatlakozást szolgáló interfész és konfiguráció teljesen egységes, de általában termékfüggı. Ez az interfész elrejti az implementáció részleteit, alkalmazásszinten nem szükséges azzal törıdni, hogy a hívások milyen formában és milyen módon jutnak el a céljukhoz. A gyártók a kommunikációra egyedi protokollokat fejlesztettek ki, ezért a különbözı SOA eszközök közvetlenül nem kapcsolhatók össze. Az összekapcsolás jelenleg a legkönnyebben a WS-* szabványok alapján végezhetı el. BME Informatikai Központ 90