A MAGYAR E-KÖZIGAZGATÁSI ARCHITEKTÚRA

Átírás

1 A MAGYAR E-KÖZIGAZGATÁSI ARCHITEKTÚRA 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: 2

3 Metaadat-táblázat Megnevezés Cím (dc:title) Kulcsszó (dc:subject) Leírás (dc:description) Típus (dc:type) Forrás (dc:source) Kapcsolat (dc:relation) Terület (dc:coverage) Létrehozó (dc:creator) Kiadó (dc:publisher) Résztvevı (dc:contributor) Jogok (dc:rights) Dátum (dc:date) Formátum (dc:format) Azonosító (dc:identifier) Nyelv (dc:language) Verzió (dc:version) Státusz (State) Fájlnév (FileName) Méret (Size) Ár (Price) Felhasználási jogok (UserRights) Leírás A magyar e-közigazgatási architektúra szolgáltatásorientált architektúra; architektúra; A dokumentum a szolgáltató állam által a közeljövıben kialakítandó ügyfélközpontú és ügyfélbarát elektronikus közigazgatási szolgáltatások megvalósításához szükséges informatikai rendszer felépítésére tesz javaslatot. Tárgyalja az e-közigazgatás szereplıinek kapcsolódási rendszerét, az e-közigazgatási rendszer tipikus komponenseit, az ügyfelek és szolgáltatók kapcsolódási módjait, az egységes kapcsolatrendszert biztosító e-közigazgatási szolgáltatási sín csatlakozási felületének leírását és a csatlakozás adminisztratív feltételeit. szöveg Magyarország e-közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal BME Informatikai Központ magyar V3 végleges EKK_ekozig_magyar_kozig_rendszer_architektura_081203_V3.doc 3

4 Verziókövetési táblázat A dokumentum neve A magyar e-közigazgatási architektúra 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 V3 Összes oldalszám 57 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 Annotált tartalomjegyzék V MeH-nek átadott verzió V MeH-nek átadott verzió 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észeként indult 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 az alprojekt egyik terméke. 2. Bevezetés (Preamble) A dokumentum tárgyalja az e-közigazgatás szereplıinek kapcsolódási rendszerét, az e-közigazgatási rendszer tipikus komponenseit, az ügyfelek és szolgáltatók kapcsolódási módjait, az egységes kapcsolatrendszert biztosító e-közigazgatási szolgáltatási sín csatlakozási felületének leírását és a csatlakozás adminisztratív feltételeit. 3. Alkalmazási terület (Scope) Elektronikus közigazgatás 4. Rendelkezı hivatkozások (References) 5. Fogalom-meghatározások (Definitions) 6. A szabvány egyedi tartalma (UniqueContent) 7. Bibliográfia 8. Rövidítésgyőjtemény 9. Fogalomtár 10. Ábrák 11. Képek 12. Fogalmak 13. Verzió 14. Mellékletek (Appendix) 5

6 Tartalomjegyzék 1. Bevezetés Definíciók, fogalmak A magyar e-közigazgatási rendszer és környezete Az e-közigazgatási rendszer jellemzıi Jogi környezet Elfogadott fejlesztési projektek Problémák Ügyintézési modellek Szolgáltatásorientált architektúra (SOA) Bevezetés Web-szolgáltatás szabványok SOAP és WSDL WS-* szabványok Transzport protokollok XML szabványok Üzenetkezeléssel kapcsolatos protokollok Biztonsági protokollok Megbízhatósági protokollok Tranzakciók Metaadatok Business Process Execution Language (BPEL) Nemfunkcionális követelmények Réteg modell A csomagtovábbító közmő Szolgáltatók E-közigazgatási szolgáltatási sín A sín szerepe az architektúrában A szemantikai interoperabilitás feltételei és alapelvei Az e-közigazgatási szolgáltatási sín alapszolgáltatásai Alapszolgáltatások Szolgáltatáskatalógus Tokenszolgáltató Hitelesítésszolgáltató E-tár Ügyfélkapu Naplózási szolgáltatás Szolgáltatás-adminisztráció Alapfogalmak Új szolgáltatás csatlakoztatása létezı csatolóhoz Új szolgáltatás felületének megjelenítése az Ügyfélkapun Meglevı szolgáltatás törlése Meglevı szolgáltatás módosítása Szolgáltatók regisztrálása és törlése Új külsı folyamat regisztrálása Címkezelés Szolgáltatás-felügyelet Alapfogalmak Alapfeladatok Összetett folyamatok felügyelete Biztonsági kérdések Az állampolgárokkal kapcsolatos biztonság Belépés azonosítás

7 Adatvédelmi jogok érvényesítése meghatalmazással A szolgáltatási szintő biztonság Üzenet-titkosítás Hitelesítés tanúsítványkezelés Szolgáltató-azonosítás Az e-közigazgatási közmő biztonsága Regisztrált csomagküldés és a közmőhasználat naplózása Fejlesztési eszközök és technológiák Elterjedt SOA eszközök Web-szolgáltatás API-k Windows Communication Foundation (WCF) Java API for XML-based RPC (JAX-RPC) Java API for XML-based Web-Services (JAX-WS) SOA eszközök Microsoft:.NET Sun: OpenESB Oracle: SOA Suite IBM: WebSphere További SOA eszközök Várható bıvítések kezelése Bevezetés Kódgenerátor-támogatást igénylı komponensek az architektúrában A fejlesztés menete Irodalomjegyzék

8 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. A második munkaszakaszban elkészült a rendszerterv, valamint annotált tartalomjegyzék az architektúra és sín specifikáció, a keretrendszer, a fejlesztési útmutató és a kapcsolódó oktatási anyagok leírására. Jelen (harmadik) munkaszakaszban elkészültek az elıbb említett anyagok is. Jelen dokumentum A magyar e-közigazgatási architektúra leírását tartalmazza. Célja, hogy áttekintı leírást adjon az architektúra felépítésérıl, üzemeltetésérıl, az architektúra szereplıinek felelısségérıl és lehetıségeirıl. 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. Az architektúra leírása megadja a szakrendszerek és állampolgárok együttmőködésére javasolt, akár jelentıs bıvítések és változások rugalmas követésére is alkalmas szolgáltatásorientált architektúra átfogó képét. A dokumentum részletezi az architektúrában definiált alapszolgáltatásokat, szolgáltatások indításának, új szakrendszer csatlakoztatásának módját, az ügyek intézését lehetıvé tevı folyamatok létrehozásához szükséges teendık és követelmények részleteit. Meghatározza az architketúra 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. Az architektúra dokumentáció felépítése: A Bevezetés c. fejezet röviden vázolja az architektúra kialakításának körülményeit, a figyelembe vett szempontokat, és a dokumentum szerepét. A Definíciók fejezet ismerteti a dokumentációban elıforduló szakkifejezések szabatos definicióját, amivel az esetleges félreértések számát kívánjuk minimalizálni. Az A magyar e-közigazgatási rendszer és környezete c. fejezet ismerteti az e-közigazgatási rendszer jellemzıit, az architektúra használatának, alkalmazásának jogi hátterét, az elfogadott fejlesztési projekteket, mint a késıbbi szereplık bázisát, valamint felveti az architektúra használatával kapcsolatban felmerülı problémákat. A Szolgáltatásorientált architektúra c. fejezet ismerteti a fogalom definícióját, a fogalomhoz kapcsolódó technikai szabványokat, a folyamatok leírására és végrehajtására alkalmas BPEL nyelvet, a nemfunkcionális követelményeket, végül az architektúra rétegmodelljét. Az E-közigazgatási sín c. fejezet röviden áttekinti a sín felépítését. A sín részletes leírása megtalálható A magyar e-közigazgatási szolgáltatási sín 8

9 c. dokumentumban. Az E-közigazgatási szolgáltatási sín alapszolgáltatásai c. fejezet felsorolja és ismerteti a szolgáltatások nyújtásához és a folyamatok végrehajtásához szükséges segédszolgáltatások funkcióit és az alapszolgáltatások elérésének részleteit. A Szolgáltatásadminisztráció és a Szolgáltatás-felügyelet c. fejezetek ismertetik a szolgáltatásnyújtással kapcsolatos teendıket, új szolgáltató belépését, a folyamatok és szolgáltatások felügyeletét, monitorozását, valamint a felmerülı hibák felderítésének módjait. A Biztonsági kérdések c. fejezet az e-közigazgatás biztonsági kérdéseit mutatja be a felmerülı problémák kategorizálásával, elemzésével, valamint a megoldások bemutatásával. A Fejlesztési eszközök és technológiák röviden ismerteti a fontosabb SOA gyártók termékeit, elemzi képességeiket, és megadja, hogy a várható bıvítések milyen technológiai támogatással végezhetık el. A dokumentumot irodalomjegyzék zárja. 9

10 1. Bevezetés A magyar e-közigazgatás fejlesztése sok évtizedes, folyamatos feladat. Kezdıdött valamikor az es években, és a végét egyelıre nem látjuk. Minden idıszaknak megvannak a speciális fejlesztési feladatai, a fejlesztési célokat és prioritásokat az 1990-es évek óta periodikusan karbantartott stratégia fogalmazza meg. Jelen dokumentum készítésekor a fejlesztés számára kedvezı lehetıségeket kínál az Új Magyarország Fejlesztési Terv (ÚMFT), amelyik a idıszakra fogalmaz meg nemzeti fejlesztési célokat és feladatokat, amelyek megvalósítását az Európai Únió is jelentıs forrásokkal támogatja. Az ÚMFT egyik fontos célkitőzése az államreform, amelynek megvalósítása két operatív program keretében történik. Az Államreform Operatív Program (ÁROP) a társadalmi, szervezeti és humán szempontokra, míg az Elektronikus Közigazgatás Operatív Program (EKOP) a szolgáltatások minıségének és elérhetıségének, és ezzel a közigazgatás hatékonyságát és eredményességét fokozó technológiai fejlesztésekre koncentrál. Az EKOP keretében több kiemelt projekt indult a közigazgatás egyes szakrendszereinek fejlesztésére. Annak érdekében, hogy ezek a fejlesztések mind az állampolgárok, mind a közigazgatásban dolgozók számára az életüket, munkájukat egyszerősítı, testreszabott, megbízható, tértıl és idıtıl függetlenül elérhetı szolgáltatásokat eredményezzenek, ki kell alakítani az e-közigazgatás egységes képet mutató rendszerét, meg kell oldani a magyar e-közigazgatás régi problémáját, a szakrendszerek zökkenımentes együttmőködését (integrált backoffice szolgáltatások). A magyar közigazgatás kialakult struktúrájában a világban nem egyedülállóan a szakrendszerek (minisztériumok, jelentısebb háttérintézmények, stb.) nagy önállósággal mőködnek, így fejlesztéseiket is önállóan bonyolítják. Az integrált backoffice kialakításához ezért szükségessé vált a fejlesztési követelmények egységesítése és annak az architektúrának a kidolgozása, amelyik biztosítani tudja a szakrendszerek önállóságának megtartása mellett azok zökkenımentes együttmőködését. Jelen dokumentum ennek az architektúrának az elsı változatát írja le. A tervezés során az alapfeladat, azaz a szakrendszerek összekapcsolhatóságának megoldása mellett további szempontokat is figyelembe vettünk: Az állampolgárok új szemlélető kiszolgálása megnöveli a szakrendszerek közötti kapcsolatok számát, és az adatforgalmat Fel kell készülni új szereplık bekapcsolódására (önkormányzatok, közszolgáltatók, EU intézmények, vállalkozások, stb.) Az e-közigazgatásnak 7x24 órás üzemben, minél nagyobb területi lefedettséggel kell rendelkezésre állnia. A jogi környezet változásainak dinamikája megmarad (pl. a párhuzamosan zajló államreform miatt is), a változásokhoz való gyors alkalmazkodás fontos A szakrendszerek önállósága maradjon meg, közöttük minél lazább csatolás alakuljon ki, minél kevesebbet kelljen tudniuk egymásról Legyen mód a fejlesztések fokozatos, lépésenkénti végrehajtására Az e-közigazgatáshoz tartozik tágabb értelemben a számítógépes ügyintézésen túl az információ-szolgáltatás (közigazgatási portál) és a telefonos ügyintézés lehetısége is, ezek azonban nem kerültek fókuszba az elemzések során. 10

11 Az architektúra tervezésekor figyelembe vettük a technológiai lehetıségeket és az e- kormányzati fejlesztések nemzetközi trendjeit. Ezek alapján választottuk a szolgáltatásorientált architektúrát és a szolgáltatási sín kialakítását, amelyek a nemzetközi irodalom Service Oriented Architecture (SOA) és Enterprise Service Bus (ESB) fogalmainak mintáját követik. Az architektúra alapján végzett fejlesztésekhez számos szállító kínál szoftvercsomagokat. Az egyes szállítók SOA és ESB modelljei azonban jelentısen eltérhetnek egymástól, így a különbözı SOA és ESB csomagok együttmőködése sem triviális. Az architektúra kidolgozása során kísérleteket végeztünk különbözı SOA és ESB csomagokkal, és az architektúra rétegeit igyekeztünk úgy definiálni, hogy azok a különbözı szállítók rendszereivel megvalósíthatók legyenek. Az architektúra alkalmasságát kísérleti rendszer létrehozásával, és azon egyszerő közigazgatási pilot alkalmazás elkészítésével is vizsgáltuk. A kedvezı tapasztalatok ellenére nem gondolhatjuk, hogy a dokumentum lezárt, végleges specifikáció. Már az év végére tervezzük a további kísérletek tapasztalatai alapján továbbfejlesztett következı verzió (v1) kiadását, és arra számíthatunk, hogy az éles rendszerek kifejlesztése során hasonlóan a követelménytár más dokumentumaihoz további módosítások válnak indokolttá. Jelen dokumentum célja tehát, hogy megadja a magyar e-közigazgatási architektúra leírását, aminek alapján a jelentısebb fejlesztések tervezhetık. A dokumentum az e-közigazgatás szereplıinek kapcsolódási rendszerét, az e-közigazgatási rendszer tipikus komponenseit, az ügyfelek és szolgáltatók kapcsolódási módjait, az egységes kapcsolatrendszert biztosító e-közigazgatási szolgáltatási sín csatlakozási felületének leírását, a csatlakozás adminisztratív feltételeit tárgyalja. A sín technikai specifikációját a A magyar e-közigazgatási szolgáltatási sín c. dokumentum tartalmazza. 11

12 2. Definíciók, fogalmak Állapotfüggetlenség Ha a szolgáltatást ugyanazon paraméterekkel, változatlan környezetben többször végrehajtjuk, minden alkalommal ugyanazon eredményt fogjuk kapni. Aszinkron szolgáltatáskérés 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. Cluster A cluster közös felügyelet alatt álló csomagcsatornát, csomagtárakat és csatolókat jelent. 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. Cselekmény réteg Az e-közigazgatási architektúra egyik rétege, amely tartalmazza a cselekményeket. Cselekmény Egy tevékenység konkrét végrehajtása. Az eljárás egy eleme. A tevékenység példánya. Csomag A közmő által átvitt XML dokumentum, amely pontosan egy üzenetet tartalmaz. Leginkább a MessageQueue rendszerek által használt üzenet fogalomnak felel meg. Csomagátviteli réteg Az e-közigazgatási architektúra egyik rétege, feladata a megbízható csomagszállítás. Csomagfogadó Az e-közigazgatási architektúra egyik rétege, feladata a beérkezı csomagok kibontása és az üzenetek megfelelı szolgáltatáshoz történı továbbítása. Csomagküldı Az e-közigazgatási architektúra egyik rétege, feladata a kimenı üzenetek becsomagolása, majd a csomagok közmőhozzáférési réteghez való továbbítása. Csomagoló réteg Az e-közigazgatási architektúra egyik rétege, amely tartalmazza a csomagküldıt és a csomagfogadót. A szolgáltató implementálja. Csomagtároló réteg Feladata a csomagok perzisztenciájának biztosítása. 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. Eljárás Egy ügy végrehajtása kapcsán végzett cselekmények összessége. Az ügy példánya. Folyamat Egy eljárás szinonímája. Lehet belsı (az ügygazda által végrehajtott) vagy külsı (a folyamat-tár által végrehajtott) Folyamat-tár Az architektúra egy kiemelt szereplıje, amely lehetıvé teszi folyamatok végrehajtását akkor, amikor a folyamat gazdája nem tudja a végrehajtás szigorú követelményeit teljesíteni. 12

13 Garantáltság Csomag vagy üzenet nem veszhet el átvitel közben. Hitelesség az üzenet vagy csomag feladója egyértelmően azonosítható Koreográfia Egy összetett ügyben a közremőködı szolgáltatások a bennük foglalt szabályok és a közöttük áramló üzenetek alapján járnak el, és adják tovább a vezérlést. Nincs kitüntetett, vezénylı szolgáltatás. Közigazgatási szolgáltatási sín A csomagtovábbító közmő és a csomagoló réteg együttes neve. Közmő-hozzáférési réteg Az e-közigazgatási architektúra egyik rétege, feladata a közmőre csatlakozás tetszıleges technológiával történı megvalósítása. Interfésze: SSocket. Amikor a csomagot átadja a csomagfogadónak, akkor a feladót a kézbesítés tényérıl értesíti, ezáltal biztosítja a vételi letagadhatatlanságot. Lépés A tevékenység végrehajtása során végzett oszthatatlan primitív aktus. Letagadhatatlanság az üzenet vagy csomag átvevıje, ha az üzenetet vagy csomagot átvette, nem tudja letagadni az átvétel tényét. Orkesztráció Egy összetett ügyben az ügy lefolyását egy kitüntetett felügyelı vezényli. Perzisztencia a rendszer újraindítása után is megmaradnak az át nem vett csomagok 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. Szolgáltatási réteg Az e-közigazgatási architektúra egyik rétege, amely tartalmazza a szolgáltatásokat megvalósító elemeket. Szolgáltató A szolgáltatás megvalósulásáért, a szolgáltatás által specifikált tevékenység végrehajtásáért és eredményéért felelıs. Egy szolgáltató több szolgáltatást is nyújthat. Tevékenység Az ügy egy vagy több lépésbıl álló eleme. A tevékenység felelıse egyértelmően meghatározható. Ü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. Ü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. Nem szabad összekeverni a MessageQueue rendszerek üzenet fogalmával! 13

14 3. A magyar e-közigazgatási rendszer és környezete Az e-közigazgatási rendszer kiterjed valamennyi közigazgatási funkciót ellátó szervezet azon számítástechnikai eszközeire, amelyek a funkciók ellátásában valamilyen módon részt vesznek, vagy azt támogatják Az e-közigazgatási rendszer jellemzıi Az e-közigazgatási rendszer fı funkciótípusai: Nyilvántartások vezetése Információszolgáltatás igazgatási feladatok ellátásához Információszolgáltatás az állampolgárok számára Elektronikus ügyintézés A közigazgatás részint földrajzilag tagolt (központi igazgatás, önkormányzatok, közigazgatási hivatalok), részint funkcionálisan, intézmények szerint (miniszteriális tagozódás, háttérintézmények). 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 [1], ezen belül is a központi elektronikus szolgáltató rendszer (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). 33 hazai kormányzati, 26 EU-s szervezet és 8 közszolgáltató vállalat nyújt elektronikusan elérhetı szolgáltatásokat ezen az infrestruktúrán. 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. 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 a szakrendszerek felé az alábbi szolgáltatásokat nyújtja [2]: 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ı 14

15 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 Jogi környezet 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 [6]. Az 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 15

16 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 Már az ÁROP és EKOP projektek tervezése során felmerült a jogi környezet módosításának igénye. Jelenleg folyamatban van a Ket. módosítása és az elektronikus közszolgáltatásról szóló törvény elıkészítése 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 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. 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 16

17 3.4. Problémák 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. 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 Ügyintézési modellek A nemzetközi példák, így az EU értékelési rendszere is, hangsúlyozzák az e-közigazgatás területén szükséges szemléletváltást, a testreszabott állampolgári szolgáltatások középpontba állítását. Az állampolgár tipikus élethelyzetei olyan összetett szolgáltatásokat igényelnek, amelyek több szakrendszert érintenek. Vegyük példaként az anyasági támogatás iránti kérelmet. A mai papír alapú gyakorlat szerint a kérelem egy őrlap kitöltése és a megfelelı igazolás (terhesgondozáson való megfelelı számú részvétel) csatolása után adható be a Magyar Államkincstárhoz (MÁK). A beadáskor be kell mutatni az igénylı személyazonosításra alkalmas igazolványát, lakcímkártyáját, a gyermek születési anyakönyvi kivonatát, az igénylı TAJ-számát igazoló hatósági igazolványt, valamint a gyermek TAJ-számát igazoló hatósági igazolványt, azaz ezeket az igénylınek be kell szereznie a megfelelı hatóságoktól. A mai jellegzetes elektronikus ügyintézési felfogás szerint: az ügyfél belép az ügyfélkapun (ezzel azonosította magát), kiválasztja az anyasági támogatás ügyet. Megjelenik egy őrlap (gyakorlatilag a papír alapúval azonos), amelyiket kitölt, megadja a személyi számát, a TAJszámát, a gyermek TAJ-számát, valamint alkalmas elektronikus dokumentum formájában a terhesgondozási igazolást és a gyermek anyakönyvi kivonatát. Az utóbbi kettıt tárolhatja az 17

18 ügyféltárában, ahonnan ilyenkor elıveheti. Egy jelölınégyzeten bejelölheti, hogy felhatalmazza a MÁK-ot az ügy intézéséhez szükséges adatok beszerzésére, illetve ellenırzésére a megfelelı nyilvántartásokból. Ezt követıen a kérelmet útjára bocsátja, és az bekerül az ügyfélkapu MÁK hivatali tárjába. Onnan a MÁK kiveszi, amikor ráér, és megkezdi a feldolgozást. Jó esetben az ügyfél egy idı után visszajelzést kap, hogy a kérelem elfogadva. Ezt akkor veszi észre, ha legközelebb belép az ügyfélkapun, és megnézi az érkezett üzeneteit. Kevésbé jó esetben arról kap értesítést, hogy a kérelme hibás, pl. a megadott TAJszámhoz más nevő gyermek tartozik. Az sem lehetetlen, hogy hosszú ideig nem történik semmi, egy idıre el is felejti az ügyet, majd eszébe jut, és elkezdhet reklamálni a MÁK-nál (jó esetben ezt is megteheti elektronikusan). Az elektronikus ügyintézés ügyfélbarát modellje szerint: az ügyfél belép az ügyfélkapun (ezzel azonosította magát), kiválasztja az anyasági támogatás ügyet. Ezzel elindít egy szolgáltatási folyamatot, amelyik az ı nevében, az ı elektronikus ügynökeként mőködik. Megjelenik egy kérdıív, amelyik azt tartalmazza, hogy kéri-e az ügy elintézéséhez szükséges adatok összeszedését a megfelelı nyilvántartásokból. Amennyiben válasza igen, a folyamat a különbözı nyilvántartásokból (szolgáltatáshívásokkal) lekéri az ügyfél adatait, és megjelenít egy kitöltött kérelmet, amelyik ellenırzötten a nyilvántartások aktuális értékeit tartalmazza, tehát nem lehet hibás, illetve, ha az ügyfél hibát talál, az nyilvántartási hiba, és célszerő kezdeményeznie a javítást. Ha van olyan csatolandó dokumentum, amelyikben szereplı adat nem érhetı el nyilvántartásból, azt az ügyféltárból csatolja (pl. a terhesgondozási igazolás, amíg errıl nincs elektronikus nyilvántartás). A rendben talált kérelmet a rendszer továbbítja a MÁK-hoz. A folyamatnak még nincs vége, hiszen erre az ügyfélnek egy határidın belül választ kell kapnia. A szolgáltatási folyamat tehát a határidıig, vagy a válasz megérkezéséig várakozik. Ha a határidı telik le elıbb, automatikusan újabb érdeklıdı üzenetet küld a MÁKnak és egyidejőleg az ügyfélnek. Az ügyfél beállíthatja, hogy a számára érkezı üzenetekrıl SMS-ben is értesítést kapjon. A jövı ideális e-közigazgatási rendszerében a nyilvántartások egyre inkább átveszik az igazolások szerepét. Ha minden nyilvántartás folyamatosan (7x24 óra) elérhetı megfelelı sávszélességgel minden ellenırzésre jogosult hatóság és minden ügyfél számára, akkor az azonosításra alkalmas dokumentumon túl az igazolások elveszítik jelentıségüket, de szerepük legalább is korlátozottabbá válik. A lehetséges, megmaradó szerepek: történetiség tárolása, ha a nyilvántartás nem tárol történetiséget (pl. mi volt a nevem 15 éve) redundancia, a nyilvántartások adatvesztése esetére visszaállítási lehetıség Nem várható, hogy az ügyfélbarát, illetve a jövı idealizált modellje a közeljövıben uralkodóvá válik. Ennek egyrészt technikai (sávszélesség, tár- és számítási kapacitás, lefedettség) korlátai vannak, másrészt jogi aggályok felvetése várható. Mindazonáltal a fejlıdés és a fejlesztések iránya ez. Jogi aggályok felmerülése tapasztalatunk szerint egyrészt adatvédelem tekintetében, másrészt a folyamatvezérlés hatáskörelvonásként történı értelmezése tekintetében várható. Az adatvédelmi aggályokkal szembe az ügyfél önrendelkezési joga állítható. Az ügyfélen kívül minden adatot csak a kezelésre jogosultak ismerhetnek meg, és minden adatkezelés az ügyfél kérésére történik. Várható, hogy ezeknek a megoldásoknak a kényelme vonzó lesz az állampolgárok számára. 18

19 A hatáskörelvonás kérdésének felvetése pedig azon a félreértésen alapul, hogy egy ügymenetet vezérlı folyamat, amelyik nem az ügygazda rendszerén fut, az ügygazda hatóságtól független döntéseket hozhat. Természetes, hogy ha van ügygazda, akkor a folyamat kidolgozása, leírása az ı feladata. Mindazokon a pontokon, ahol emberi döntés szükséges, a folyamat emberi döntést vár el (más kérdés, hogy ésszerően elég sok döntés automatizálható lenne a közigazgatásban, de erre csak az ügygazda hatóság egyetértésével van lehetıség). A folyamatot az ügygazda futtathatja saját rendszerén, ha az erre technikailag alkalmas, vagy átadhatja futtatásra (üzemeltetésre) megfelelı szerzıdéses konstrukcióban (SLA) arra alkalmas szolgáltatónak, tipikusan a KR-nek. Az architektúra kialakításakor arra törekedtünk, hogy legyen alkalmas a bemutatott modellek bármelyikének megvalósítására, és így arra is, hogy a jövı rendszere fokozatos fejlesztés eredményeként alakuljon ki. 19

20 4. Szolgáltatásorientált architektúra (SOA) 4.1. Bevezetés 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 hajtanak végre. 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. 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. 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 é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 érdekében szükséges az üzenetek formájának szabványosítása. Erre jelen dokumentum a késıbb részletezett webszolgáltatás (WebService, WS) szabványokat írja elı. Ennek egyenes következménye, hogy az 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. 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 20

21 történı csatlakozás lényege, hogy a meglevı funkciók és a sín közötti kapcsolatot a 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. Az eddig bemutatott modell lényegében megfelel az OASIS SOA definíciójában leírt architektúrának. Az OASIS definíciója szerint a Service Oriented Architecture (SOA) [9] 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 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 [10] 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 web-szolgáltatásoknak az e-közigazgatási architektúrában történı alkalmazásának elınyei, hogy elterjedt, jól definiált szabványokon alapulnak széles körben támogatottak az architketúra alkalmazása során felmerülı feladatok és problémák mindegyikére kínálnak megoldást a hazai és nemzetközi üzleti és közigazgatási trendek a mind szélesebb körő alkalmazásukat mutatják, így biztos alapot nyújtanak a jövıbeni külsı rendszerekhez (üzleti szféra, nemzetközi, európai uniós kormányzati együttmőködések) 4.2. Web-szolgáltatás szabványok Ez a szakasz a fontosabb WS-* szabványokat (1. ábra) ismerteti M. L. Bustamante összefoglalója [11] és a WSIT Tutorial [12] alapján. Az innoq weblapján [13] 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. 21

22 SOAP és WSDL 1. ábra - A fontosabb WS szabványok A SOAP (Simple Object Access Protocol) [10] 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) [14]. 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 22

23 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). 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 porttypeot á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. 23

24 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 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 XMLbı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ı 24

25 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) [15] 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 [16]. 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 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. 25

26 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 [17] és M. B. Juric könyve alapján [18]. A BPEL az üzleti folyamatok leírására szolgáló szabványos programnyelv, 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. 26

27 4.4. 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 27

28 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: 28

29 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 29

30 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 Réteg modell A közigazgatási architektúra magasszintő mőködését szemlélteti a fenti ábra. Az állampolgár bejelentkezik az ügyfélkapura, ahol megtekintheti a személyes e-tárjában levı dokumentumokat, megnézheti személyes, közigazgatási ügyekben kapott leveleit, illetve ügyet választhat. A kiválasztott ügy indításakor egy szakrendszerhez fordul az ügyfélkapu az állampolgár nevében. A szakrendszer vagy maga futtatja az ügyet intézı folyamatot (ekkor belsı folyamatról beszélünk), vagy, ha erre nincs lehetısége, akkor a folyamat-tárban regisztrált folyamatot (külsı folyamat) fogja elindítani. Fontos kiemelni, hogy ez utóbbi eset sem jár hatáskörelvonással, mert a folyamat specifikálása, megvalósítása, és a folyamat futtatása közben felmerülı döntések meghozatala mind megmarad a szakrendszer hatáskörében, pusztán a folyamat informatikai szintő futtatása kerül a folyamat-tárhoz. Egy folyamat, akár belsı, akár külsı, tetszıleges bonyolultságú lehet. A folyamat futása során elképzelhetı, hogy más szakrendszerek szolgáltatásait is igénybe kell venni. Ehhez azonban a megfelelı jogosultságokat meg kell szerezni. A szolgáltatások elérése az e-közigazgatási közmővön keresztül lehetséges. Minden érintett szakrendszer és egyéb szolgáltató erre a közmőre csatlakozik. A közmő használatával kapcsolatos feladatok, új rendszerek csatlakoztatása, kommunikáció-felügyelet egy erre a célra létrehozott szervezet, az e-közigazgatási Szolgáltatási Felügyelet (röviden Felügyelet) hatáskörébe tartozik. A közigazgatási architektúra alapvetıen egy rétegelt modell szerint épül fel. A rétegek funkcióinak és a rétegek közötti kapcsolatoknak (interfészek) a kialakítása a szabványokat, ajánlásokat követi. Az interfész-specifikációk betartása esetén egy réteg cseréje a többi réteget nem érinti. 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 30

31 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 biztosítja, hogy egy üzenet pontosan egyszer filozófiá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. A rétegek közötti vertikális és horizontális kapcsolatokat szemlélteti a 2. ábra: 31

32 Közmő rétegei Szolgáltató rétegei 2. ábra Rétegek kapcsolatai A rétegek részletes felépítését a 3. ábra mutatja be: 32

33 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 3. á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. 33

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

35 5. E-közigazgatási szolgáltatási sín 5.1. A sín szerepe az architektúrában 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.). 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 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. 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. 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 szemantikai interoperabilitás feltételei és alapelvei Az e-közigazgatási interoperabilitás széles értelemben a közigazgatási szervezetek azon képessége, hogy együtt tudnak mőködni egymással. Mőszaki szinten két vagy több különbözı közigazgatási IKT rendszer vagy komponens azon képessége, hogy értelmes módon és problémamentesen tudnak információt cserélni, és a cserélt információt felhasználni. A szemantikai interoperabilitás arra törekszik, hogy a különbözı alkalmazások pontosan megértsék az egymásnak átadott információk jelentését. Ennek többnyelvő környezetben különösen nagy jelentısége van. A szemantikai interoperabilitással szemben a következı követelményeket támasztjuk: 35

36 alapadatok egyezısége közös ontológia létrehozásával az egyes szakrendszerek és más szereplık által közösen, egyik szakrendszerhez sem hozzárendelhetı módon használt fogalmak egyértelmő, szabatos leírása és ennek szabványos adatformátuma dedikált közös ontológia-tárban kezelendı. Az ehhez a tárhoz való hozzáférés olvasás esetén korlátlan, módosítást az arra felhatalmazott szervezet(ek) kezdeményezhetnek. alapadatok módosítása felügyelt és nyilvános: a globális ontológia-tárban található alapadat-leírások módosítása csak indokolt esetben, az összes szereplı értesítésével valósítható meg. domén-specifikus adatok átfordíthatósága Elıfordulhat, hogy bizonyos adatok domén- vagy szakrendszer-specifikusak. Az ilyen adatok leírása az adott doméngazda, szakrendszer felelıssége. Amennyiben az adatleírást más doménben, szakrendszerben is igénybe veszik, akkor a módosítás csak az érintett szakrendszerek bevonásával történhet. Amennyiben a doménspecifikus adat több szakrendszerben is sajátként szerepel, akkor feltéve, hogy az adatleírás nem tehetı át az alapadatok leírásai közé a közös ontológia-tárba meg kell teremteni annak a módját, hogy a különbözı, szakrendszerspecifikus adatformátumok hogyan fordíthatók át egymásba. Mindenképpen erısen javasolt, hogy a több szakrendszerben is sajátként kezelt adatokat a közös ontológiatárba helyezzék, és a szakrendszerek az új, közös formátum használatára térjenek át, akár amódon, hogy a többi szakrendszerrel való kommunikáció során a belsı formátumot a közös formátumra alakítják és viszont. ontológia lokális és globális menedzselése Az ontológiák kezelése a rendszer teljes élettartamán átívelı folyamat. Emiatt a folyamatos karbantartás, az új adatok felvétele, régiek törlése szabályozott módon kell történjen. Ehhez vagy az érintett szakrendszerben, vagy a közös ontológia-tár esetében egy dedikált ontológia-kezelı szervezetet kell létrehozni, és a menedzsment feladatok ellátásával megbízni. Ezeken a szervezetek és ontológiák kihagyásával nem szabad adatformátumot és -leírást jóváhagyni és használatba helyezni. 36

37 6. Az e-közigazgatási szolgáltatási sín alapszolgáltatásai 6.1. Alapszolgáltatások 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. A szolgáltatáskatalógus az Univerzális Leírás, Keresés és Integráció (Universal Description, Discovery and Integration, UDDI) version 3 szabványnak megfelelıen használható. A UDDI a következı három komponensbıl áll: White Pages egyedi azonosítók alapján történı címkeresés és magaszintő leíráskeresés; Yellow Pages szabványos elnevezéseken és kategóriákon alapuló címkeresés; Green Pages a szolgáltatások technikai leírásai. A három komponens segítségével az architektúrában megtalálható szolgáltatások katalogizálása, nyilvántartása és kereshetısége szabványos módon biztosítható 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. A tokenszolgáltató a WS-Trust 1.3 szabványnak megfelelı interfészen keresztül érhetı el: Névtér: Tipikus prefix: wst Specifikáció helye: Fogalmak: Requestor (kérı) Olyan programozott kliens, amely valamilyen információt vagy szolgáltatást kíván elérni 37

38 Subject (tárgy) Az entitás, akinek a nevében a Requestor eljár Claims (állítások) A Subject-rıl tett kijelentések Security Token Egy adatstruktúra Claim-ek összefogására Security Token Service (STS) Olyan web-szolgáltatás, amely kibocsátja és menedzseli a Security Token-eket Funkcionalitás: Issue Security Token: token kibocsátásának kérése Renew Security Token: token megújítása (idıkorlát miatt) Cancel Security Token: token megszüntetése (STS is visszavonhatja) Validate Security Token: token ellenırzése A tipikus lépések használat során: a) az STS authentikálja a requestor-t, pl. transport security+jelszó, tanúsítvány, vagy másik STS által kibocsátott claim-ek alapján b) az STS egy tokent (benne claim-ek) bocsát ki a requestor számára c) a requestor igénybe veszi a szolgáltatást csatolva a tokent (benne a claim-eket) d) a szolgáltatás ellenırzi tokent és a claim-eket e) a szolgáltatás kiszolgálja a requestor-t Hitelesítésszolgáltató Megadja, hogy egy adott tanúsítvány érvényes-e az adott idıpontban. A hitelesítésszolgáltató az Online Tanúsítvány Állapot Protokoll (Online Certificate Status Protocol, OCSP) által megadott módon érhetı el (RFC 2560). Az OCSP X.509-es digitális tanúsítványok érvényességének ellenırzésére lett definiálva. A szolgáltatás egy adott tanúsítványról eldönti, hogy megfelelı, visszavont vagy ismeretlen állapotú-e 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 38

39 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 Naplózási szolgáltatás Lehetıvé teszi, hogy a szolgáltatók a mőködésükkel kapcsolatos információkat naplóbejegyzések formájában mások számára elérhetıen, szabványos módon rögzítsék. A szolgáltatás által nyújtott funkciók: szolgáltatásnyújtás megkezdésének rögzítése szolgáltatás kérésének rögzítése szolgáltatás indításának rögzítése szolgáltatás leállításának rögzítése 39

40 7. Szolgáltatás-adminisztráció 7.1. Alapfogalmak A szolgáltatás-adminisztráció mindazon feladatokat magában foglalja, amelyek ahhoz szükségesek, hogy az e-közigazgatási SOA architektúrán üzemszerően lehessen szolgáltatásokat nyújtani. Ezeket a feladatokat egy dedikált szervezet hatáskörében kell végrehajtani. Ezt a szervezetet a továbbiakban Felügyeletnek fogjuk nevezni. Az alábbiakban az architektúrával kapcsolatos adminisztratív feladatok kibontása szerepel, minden lépéshez megadva, hogy az adott lépés végrehajtása kinek a feladata. A továbbiakban z egyes lépések felelıseire az alábbi jelöléseket alkalmaztuk: [S] Szolgáltató: egy vagy több szolgáltatás nyújtója, ügygazda [F] Felügyelet: az adminisztratív és felügyeleti feladatokat ellátó szervezet [U] Ügyfélkapu: az e-közigazgatás állampolgárok által elérhetı felülete, amely elvégzi az állampolgár beléptetését, azonosítását, és lehetıvé teszi, hogy az állampolgár ügyet indítson és megtekintse az e-közigazgatás szereplıitıl beérkezı üzeneteit, leveleit. [T] Folyamat-tár: azon folyamatok, ügyek végrehajtója, amelyek vagy nincsenek szakrendszerhez rendelve, vagy olyan szakrendszerhez tartoznak, amely nem képes a megbízható végrehajtásra 7.2. Ú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 Felügyeletnek: a) szolgáltatásleíró b) dokumentáció c) szolgáltatás címe d) verzió e) régi verzió érvényességi ideje f) igénybe vett más szolgáltatások g) választott csatoló neve [F] A szolgáltatás funkcionális és nem funkcionális tesztje a csatolón keresztül [F] A kérelem elbírálása [S+B] A szolgáltatás véglegesítése [F] A szolgáltatásleíró, a dokumentáció és a szolgáltatás címének regisztrálása a szolgáltatáskatalógusban 40

41 [S] A többi szereplı értesítése az új szolgáltatásról 7.3. Ú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 7.4. Meglevı szolgáltatás törlése [S] Törlendı szolgáltatás megnevezése a Felügyelet felé [F] Törlendı szolgáltatás kivezetése a o szolgáltatáskatalógusból o tokenszolgáltatótól [F] Ügyfélkapu értesítése a szolgáltatás megszüntetésérıl [U] Szolgáltatás kivezetése az ügyfélkapu felületérıl 7.5. Meglevı szolgáltatás módosítása [S] A szolgáltatás új interfészének definiálása, dokumentálása [S] A szolgáltatás módosított változatának elkészítése [S] A szolgáltatás módosított változatának tesztelése, auditja [S] A következık elküldése a Felügyeletnek: a) szolgáltatásleíró b) dokumentáció c) szolgáltatás címe d) verzió e) régi verzió érvényességi ideje f) igénybe vett más szolgáltatások [F] A szolgáltatás funkcionális és nem funkcionális tesztje a csatolón keresztül [F] A kérelem elbírálása [S+B] A szolgáltatásmódosítás véglegesítése [F] 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 a szolgáltatás módosulásáról 41

42 7.6. Szolgáltatók regisztrálása és törlése Új szolgáltató regisztrálásához a következı lépéseket kell végrehajtani: [S] Szolgáltató (szakrendszer) adatainak (név, kontakt személy elérhetısége, stb megadása [F] Szolgáltató (szakrendszer) adatainak ellenırzése [F] Szolgáltató (szakrendszer) regisztrációs azonosítójának elıállítása, adatokhoz rendelése Meglevı szolgáltató regisztrációjának törlésekor a következı lépéseket kell végrehajtani: [S] Szolgáltató kérvénye a regisztráció törléséhez [F] Kérvény elbírálása [F] A szolgáltató csatlakozóinak törlése a sínadminisztrációnál Új külsı folyamat regisztrálása A közigazgatási ügyek végrehajtását az e-közigazgatási architektúrában (tipikusan BPEL) folyamatok futtatásával kell megoldani. Ehhez azonban a következı feltételeket kell a ügygazdának biztosítania: megbízható, folyamatos (7/24) rendelkezésreállás perzisztencia biztosítása folyamat-követés támogatása Amennyiben az ügygazda ezeket a feltételeket biztosítja, a folyamat futtatását saját informatikai rendszerén belül is megvalósíthatja. Ha azonban e feltételek nem teljesülnek, akkor a folyamatot egy, az architektúrában biztosított, dedikált folyamat-tárban kell elhelyezni, amely a fenti feltételek mellett fogja a folyamatot szükség szerint futtatni. Az ilyen folyamatokat külsı folyamatoknak nevezzük. Fontos kiemelni, hogy ez utóbbi eset sem jár hatáskörelvonással, hiszen a folyamat specifikálása, megvalósítása, és a folyamat futtatása közben felmerülı döntések meghozatala mind megmarad az ügygazda hatáskörében, pusztán a folyamat informatikai szintő futtatása kerül a folyamat-tárhoz. A külsı folyamatok regisztrálásához a következı lépéseket kell megtenni: [S] Folyamat létrehozása a szokott módon [S] Folyamat auditálása és tesztelése a szokott módon [S-F] Folyamat átadása-átvétele az ügygazdától a folyamat-tárba [S-F] A folyamat ügygazda-hatáskört igénylı részeinek konfigurálása [F] A folyamat második auditálása és tesztelése a folyamat-tárban [F] Folyamat élesítése 42

43 7.8. Címkezelés A rendszerben az alábbi módon képezzük a szolgáltatások címeit: gsb://[cluster name]/[queue name]/[local URL] Ahol: [Cluster name]: a cluster neve [Queue name]: a cluster-en belüli Queue neve [Local URL]: a célszereplı saját URL része, ez tetszıleges felépítéső lehet Például: gsb://kr1.gov.hu/apeh1/eva/javitas A címkezeléssel kapcsolatos feladatok a következık: A Cluster nevét a cluster létrehozásakor a Felügyelet adja meg. A Queue nevét a szolgáltató csatolójának regisztrációjakor a Felügyelet adja meg. A Local URL-t a szolgáltató választja, a számára leginkább megfelelı módon. A szolgáltatások címeit a korábban leírt lépések során a szolgáltatáskatalógusban regisztráltatni kell. 43

44 8. Szolgáltatás-felügyelet 8.1. Alapfogalmak A szolgáltatás-felügyelet mindazon feladatokat magában foglalja, amelyek a szolgáltatási architektúra mőködése során üzemszerően felmerülnek. Ezek kezeléséhez dedikált szervezetet kell létrehozni, amelyet a következıkben Felügyeletnek fogunk nevezni Alapfeladatok Alapszolgáltatások állapota Minden alapszolgáltatáshoz felügyelni kell a szolgáltatás állapotát: o fut o karbantartás alatt o teszt üzemmódban o leállítva az állapot történetét, idıbeli jellemzıit a szolgáltatás verziókövetését a szolgáltatás futási jellemzıit: o feldolgozási sebesség o a szolgáltatás csatolójának puffer-terheltsége o hány egyidejő kérés fut o adott idıszak alatt hány kérés futott be az éppen kiszolgálása alatt levı vagy kiszolgált kérések jellemzıit o kiszolgálás ideje o kiszolgálás eredménye: sikeres, elutasított, hibás Szolgáltatások állapota Minden szolgáltatáshoz felügyelni kell a szolgáltatás állapotát: o fut o karbantartás alatt o teszt üzemmódban o leállítva az állapot történetét, idıbeli jellemzıit a szolgáltatás verziókövetését a szolgáltatás futási jellemzıit: o feldolgozási sebesség o a szolgáltatás csatolójának puffer-terheltsége o hány egyidejő kérés fut o adott idıszak alatt hány kérés futott be az éppen kiszolgálása alatt levı vagy kiszolgált kérések jellemzıit 44

45 o kiszolgálás ideje o kiszolgálás eredménye: sikeres, elutasított, hibás Szolgáltatók állapota Az egyes szolgáltatókhoz az általuk nyújtott szolgáltatások adatainak kumulált értékei. Szolgáltatónál futó szolgáltatások állapotai összegezve (hány darab fut, stb) Szolgáltatónál futó szolgáltatások kihasználtsága 8.3. Összetett folyamatok felügyelete Összetett folyamatok esetén, amikor a folyamatban több szolgáltatás sorrendi vagy párhuzamos futása szükséges egy adott feladat ellátásához, további feladatok elvégzésére lehet szükség. Ezek: Összetett folyamat állapotának követése o melyik szolgáltatás(ok)nál tart a folyamat o mennyi idı telt el a folyamat indítása óta o melyik szolgáltatásnál mennyi idıre volt szükség o milyen eredménnyel futottak a már elvégzett szolgáltatások: siker, hiba, visszautasítás Összetett folyamat futásának befolyásolása o alternatív szolgáltatás megadása o futó folyamat felfüggesztése o felfüggesztett folyamat folytatása o futó vagy felfüggesztett folyamat megszüntetése Összetett folyamatok statisztikai elemzése o melyik szolgáltatásnál milyen idıadatok születtek átlagos várakozás átlagos végrehajtás ezek szórása o egyéb statisztikai adatok győjtése, feldolgozása 45

46 9. Biztonsági kérdések Az architektúra alkalmazása során felmerülnek biztonsággal kapcsolatos kérdések is. Ezeket a kérdéseket több nézıpontból és az architektúra különbözı szintjein kell vizsgálni és megválaszolni. A biztonsággal kapcsolatos kérdések a következı csoportokba oszthatók: állampolgárok személyiségi és adatvédelmi jogait érintı kérdések szolgáltatások nyújtása és igénybevétele során felmerülı biztonsági kérdések az e-közigazgatási közmő használata és mőködése közben felmerülı kérdések Az alábbi alfejezetekben a fenti csoportosítás szerint ismertetjük a biztonsággal kapcsolatos megoldásokat Az állampolgárokkal kapcsolatos biztonság Belépés azonosítás Az állampolgár az e-közigazgatás szolgáltatásaihoz valamilyen jól definiált interfészen (ami jelenleg az ügyfélkapu, de késıbb bıvülhet más jellegő kapcsolattal, pl. mobil-telefonos, stb) keresztül férhet hozzá. A hozzáférés biztonsági szempontból kétfajta lehet. Az egyik fajta hozzáférésre anonim belépéssel van lehetıség, amikor is tipikusan általános lekérdezéseket végezhet (pl. hivatalok nyitvatartása, közigazgatási határidık, stb). Ez azokban az esetekben fordul elı, amikor az állampolgár azonosítására a szolgáltatás nyújtásához nincs szükség. A másik fajta hozzáférés során az állampolgárnak azonosítania kell magát, ez a jelenlegi ügyfélkapun azonosító-jelszó páros megadásával történik. Az alkalmazott technológia azonban tetszıleges lehet, ami fontos, hogy az azonosítással egybekötött beléptetés eredményeként az állampolgár személyazonossága adott szigorúság mellett egyértelmően ellenırizhetı legyen. Ezt követıen olyan szolgáltatásokhoz is hozzáférhet, amelyek anonim módon nem voltak elérhetık, például lekérdezheti, hogy kapott-e a közigazgatástól levelet, vagy saját nevében (esetleg meghatalmazással) ügyet indíthat, stb. Az e-közigazgatási architektúra szükség esetén lehetıvé tudja tenni, hogy különbözı súlyú ügyek indításához különbözı erısségő azonosításra legyen szükség. Fontos azonban hangsúlyozni, hogy az architektúra egyik deklarált célja, hogy az állampolgár számára megkönnyítse a közügyek intézését. Emiatt törekedni kell arra, hogy az állampolgárt a szükséges biztonsági erısség megtartásával a lehetı legkevesebb alkalommal kelljen azonosításra kérni, számára az ügyek intézését minél zökkenımentesebben kell biztosítani. 46

47 Adatvédelmi jogok érvényesítése meghatalmazással A közigazgatásban vannak ügyek, amelyek végrehajtásához több szakrendszerben fellelhetı információ együttes meglétére van szükség. A hatályos adatvédelmi törvény nem teszi lehetıvé, hogy a szakrendszerek közös azonosítóval tárolják az állampolgárok adatait, illetve a szakrendszerek közötti adatmozgatáshoz több feltétel (törvényi meghatalmazás, célhozkötöttség, stb) szükséges. Másik oldalról viszont a közigazgatás törvényi kötelezettsége, hogy azokat az adatokat, amelyekre egy ügy során szükség van, és amelyeket valamely szakrendszer tárol az állampolgár terhelése nélkül a szakrendszereknek kell egymás között átadniuk. A fenti feltételek teljesítéséhez szükség van arra, hogy (1) az állampolgár meghatalmazást adjon és adhasson az ügyben érintett szakrendszereknek a szükséges adatok átadására, valamint hogy (2) a felhatalmazás csak valóban az érintett ügyben lehessen felhasználható, egyik szakrendszer se tudjon a használatával visszaélni. Erre a feladatra az e-közigazgatási architektúrához hasonló rendszerekben ún. tokenszolgáltatót használnak. A tokenszolgáltató lehetıvé teszi olyan (tipikusan rövid lejáratú) tokenek kibocsátását, amelyek különbözı azonosítókat és paramétereket tartalmazhatnak egy adott szolgáltatás igénybe vételéhez. Az állampolgár az ügyfélkapun meghatalmazást adhat az ügy kapcsán adatai összegyőjtéséhez, melynek alapján a tokenszolgáltató rövid lejáratú tokeneket készíthet az egyes szakrendszerek számára. Igény esetén egy megfelelı formátumú meghatalmazás is lehet token, ebben az esetben a tokenszolgáltató lehet maga az állampolgár vagy lehet akár az ügyfélkapu is, amely a meghatalmazást összeállította. A tokenszolgáltató teszi lehetıvé, hogy egy B szakrendszer az állampolgár felhatalmazása alapján olyan, az állampolgár azonosítóit és paramétereit tartalmazó tokeneket kaphasson, amelyekkel az A szakrendszerben az állampolgár adatai fellelhetık, illetve konkrét kérdések eldönthetık egy adott ügy kapcsán. A token tartalmát csak A tudja kibontani, B számára az nem értelmezhetı, így nem ismerheti meg az abban lévı azonosítókat. Ezt a tokent B szakrendszer felhasználhatja az általa végrehajtott ügy során, de késıbb ugyanezzel a tokennel semmilyen más ügyben nem tud A szakrendszertıl az állampolgárt érintı adatot megkapni A szolgáltatási szintő biztonság Üzenet-titkosítás Az e-közigazgatás mőködése során elengedhetetlenül szükséges, hogy a szolgáltatások igénybevétele során történı üzenetváltások titkosítottak legyenek. Ezt az architektúrában szolgáltatási szinten kell tudni megoldani, mert minden egyes szolgáltatás esetén más-más titkosítási erısségre lehet igény. Az architektúra az üzenetek formátumának a SOAP 1.2-t írja elı, amelyhez létezik titkosítási szabvány (XML encryption). Ez lehetıvé teszi az üzenetszintő titkosítást, amellyel megoldható, hogy a szolgáltatótól kikerülı üzenetekbıl a 47

48 célszolgáltatón kívül senki más (sem más szakrendszer, sem a közmő, sem egyéb, az üzenetváltást figyelı szervezetek) ne tudjon érzékeny információt kiolvasni Hitelesítés tanúsítványkezelés Az architektúra használata során, és a közigazgatás ügyeinek intézése során is szükség van arra, hogy az ügyekben részt vevı szereplık minden esetben egyértelmően tanúsíthassák, hogy egy adott dokumentum vagy üzenet hiteles. Erre szolgál az architektúra hitelesítésszolgáltatása, amely szabványos módon kezeli a tanúsítványokat, amelyek kiadhatók, visszavonhatók és érvényességük ellenırizhetı Szolgáltató-azonosítás Szolgáltatások igénybevétele során felmerül annak az igénye, hogy mind az igénybe vevı, mind a szolgáltatást nyújtó azonosítható legyen. Az e-közigazgatási architektúrában minden szolgáltatónak egyedi azonosítóval kell rendelkeznie, amit minden szereplı (más szakrendszerek, a közmő, a felügyeleti szervek) ellenırizni tud, és ami lehetıvé teszi, hogy az elküldött vagy megkapott üzenetek feladója illetve fogadója azonosítható legyen. Ezenkívül lehetıvé teszi azt is, hogy sem üzenet elküldése, sem üzenet megkapása ne legyen letagadható. A szolgáltatóknak saját felelısségi körükben kell ellenırizniük, hogy egy adott szolgáltatásuk igénybevételére az igénybevevınek van-e felhatalmazása vagy sem. A SOAP 1.2 szabványú üzenetek kiegészíthetık a XML digital signature szabványban megadott elemekkel, amelyek az üzenetekhez olyan aláírást illesztenek, amelyek lehetetlenné teszik az aláírt üzenetek tartalmának és aláírásának illetéktelen megváltoztatását Az e-közigazgatási közmő biztonsága Regisztrált csomagküldés és a közmőhasználat naplózása A közmő biztonságát két oldalról védi az architektúra. Egyfelıl a közmőhöz csak regisztrált rendszerek kapcsolódhatnak, akik rendelkeznek a fent ismertetett azonosítókkal. A regisztrált rendszerek a közmőhöz csatolt bármely szolgáltatást elérhetik. A közmő ellenırzi, hogy egy, a közmővet igénybe vevınek megvan-e a közmőhöz csatlakozást lehetıvé tevı jogosítványa, vagyis az azonosítója regisztrálva lett-e. Annak az ellenırzése azonban a szolgáltatást nyújtó felelıssége, hogy egy adott szolgáltatás igénybevételére van-e a szolgáltatást igénybe vevınek joga. A közmő a naplózási szolgáltatás segítségével teszi lehetıvé, hogy a csomagok átvitelével kapcsolatos információk (melyik rendszer melyik szolgáltatást vette igénybe, milyen azonosítójú csomaggal. stb.) rögzítésre kerüljenek, és késıbb visszakereshetık legyenek. A naplózás során a csomagok üzenettartalmát nem rögzítik, csak egy, a tartalom alapján generált 48

49 kódot, ami a tartalom ismeretében egyértelmően elıállítható, de a kódból a tartalom nem állítható vissza. Ezzel megvalósítható, hogy mind az üzenetátvétel, mind az üzenetküldés letagadhatatlan legyen. Egy üzenet vagy csomag alapján ugyanis könnyen ellenırizhetı, hogy ezt a kérdéses szereplı küldte illetve kapta-e meg. A naplózás lehetıvé teszi azt is, hogy ha bármelyik szereplı olyan üzenetet küld, olyan szolgáltatást vesz igénybe, amihez nincs joga, akkor az esetrıl naplóbejegyzés készüljön, ami késıbb bizonyító erejő lehet. 49

50 10. Fejlesztési eszközök és technológiák Elterjedt 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 [11] (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. 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 [19] (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 50

51 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 [20] (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 [21], 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 támogatás a 2.1-es verzióba bekerült), azonban a teljes WS-* protokollhalmaz lefedése még távolinak tőnik. 51

52 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 alábbi 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. 1. 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 [22] verziójában mutatta be a web-szolgáltatások készítéséhez kifejlesztett Windows Communication Foundation-t [23], é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 [24], 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 [25], melynek alkalmazásszervere a GlassFish [26]. A JAX-WS típusú web-szolgáltatások referencia implementációja a Metro [27][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) [28] [12] 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 Oracle: SOA Suite Az Oracle SOA Suite [30] 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 [31] egyszerően lehet JAX-WS típusú web- 52

53 szolgá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 [32] 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. 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 53

54 segítségével az eszközökbe betölthetı forráskódok minél nagyobb része automatikusan elıállítható 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 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. 54

55 4. ábra - A fejlesztés menete A fejlesztés menetét az 4. á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 az architektúra részét képezı keretrendszer és komponenstár alkalmas. 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átor képes arra, hogy ezeket a változásokat egy esetleges újrageneráláskor átemelje az új kódba. 55