A MAGYAR E-KÖZIGAZGATÁSI ARCHITEKTÚRA 1
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
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) 2008. 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
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 2009.09.21. 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 V1 2008.07.30. Annotált tartalomjegyzék V2 2008.09.22 MeH-nek átadott verzió V3 2008.12.10. MeH-nek átadott verzió 4
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
Tartalomjegyzék 1. Bevezetés... 10 2. Definíciók, fogalmak... 12 3. A magyar e-közigazgatási rendszer és környezete... 14 3.1. Az e-közigazgatási rendszer jellemzıi... 14 3.2. Jogi környezet... 15 3.3. Elfogadott fejlesztési projektek... 16 3.4. Problémák... 17 3.5. Ügyintézési modellek... 17 4. Szolgáltatásorientált architektúra (SOA)... 20 4.1. Bevezetés... 20 4.2. Web-szolgáltatás szabványok... 21 4.2.1. SOAP és WSDL... 22 4.2.2. WS-* szabványok... 23 4.2.3. Transzport protokollok... 23 4.2.4. XML szabványok... 23 4.2.5. Üzenetkezeléssel kapcsolatos protokollok... 23 4.2.6. Biztonsági protokollok... 24 4.2.7. Megbízhatósági protokollok... 25 4.2.8. Tranzakciók... 25 4.2.9. Metaadatok... 25 4.3. Business Process Execution Language (BPEL)... 26 4.4. Nemfunkcionális követelmények... 27 4.5. Réteg modell... 30 4.5.1. A csomagtovábbító közmő... 34 4.5.2. Szolgáltatók... 34 5. E-közigazgatási szolgáltatási sín... 35 5.1. A sín szerepe az architektúrában... 35 5.2. A szemantikai interoperabilitás feltételei és alapelvei... 35 6. Az e-közigazgatási szolgáltatási sín alapszolgáltatásai... 37 6.1. Alapszolgáltatások... 37 6.1.1. Szolgáltatáskatalógus... 37 6.1.2. Tokenszolgáltató... 37 6.1.3. Hitelesítésszolgáltató... 38 6.1.4. E-tár... 38 6.1.5. Ügyfélkapu... 38 6.1.6. Naplózási szolgáltatás... 39 7. Szolgáltatás-adminisztráció... 40 7.1. Alapfogalmak... 40 7.2. Új szolgáltatás csatlakoztatása létezı csatolóhoz... 40 7.3. Új szolgáltatás felületének megjelenítése az Ügyfélkapun... 41 7.4. Meglevı szolgáltatás törlése... 41 7.5. Meglevı szolgáltatás módosítása... 41 7.6. Szolgáltatók regisztrálása és törlése... 42 7.7. Új külsı folyamat regisztrálása... 42 7.8. Címkezelés... 43 8. Szolgáltatás-felügyelet... 44 8.1. Alapfogalmak... 44 8.2. Alapfeladatok... 44 8.3. Összetett folyamatok felügyelete... 45 9. Biztonsági kérdések... 46 9.1. Az állampolgárokkal kapcsolatos biztonság... 46 9.1.1. Belépés azonosítás... 46 6
9.1.2. Adatvédelmi jogok érvényesítése meghatalmazással... 47 9.2. A szolgáltatási szintő biztonság... 47 9.2.1. Üzenet-titkosítás... 47 9.2.2. Hitelesítés tanúsítványkezelés... 48 9.2.3. Szolgáltató-azonosítás... 48 9.3. Az e-közigazgatási közmő biztonsága... 48 9.3.1. Regisztrált csomagküldés és a közmőhasználat naplózása... 48 10. Fejlesztési eszközök és technológiák... 50 10.1. Elterjedt SOA eszközök... 50 10.1.1. Web-szolgáltatás API-k... 50 10.1.1.1. Windows Communication Foundation (WCF)... 50 10.1.1.2. Java API for XML-based RPC (JAX-RPC)... 50 10.1.1.3. Java API for XML-based Web-Services (JAX-WS)... 51 10.1.2. SOA eszközök... 52 10.1.2.1. Microsoft:.NET 3.0... 52 10.1.2.2. Sun: OpenESB... 52 10.1.2.3. Oracle: SOA Suite... 52 10.1.2.4. IBM: WebSphere... 53 10.1.2.5. További SOA eszközök... 53 10.2. Várható bıvítések kezelése... 53 10.2.1. Bevezetés... 53 10.2.2. Kódgenerátor-támogatást igénylı komponensek az architektúrában... 54 10.2.3. A fejlesztés menete... 54 11. Irodalomjegyzék... 56 7
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
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
1. Bevezetés A magyar e-közigazgatás fejlesztése sok évtizedes, folyamatos feladat. Kezdıdött valamikor az 1960-70-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 2007-2013 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
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
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
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
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. 3.1. 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 e-mail 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
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. 3.2. Jogi környezet Az elektronikus ügyintézés jogi keretei Magyarországon lényegében adottak, mert 2005. 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ó 2004. é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: 2004. é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 2001. évi XXXV. törvény Az elektronikus aláírásról 15
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. 3.3. 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
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. 3.5. Ü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
ü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
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
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
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 2007. 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
4.2.1. 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
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. 4.2.2. 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. 4.2.3. 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. 4.2.4. 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. 4.2.5. Ü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
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á. 4.2.6. 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
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. 4.2.7. 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. 4.2.8. 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. 4.2.9. 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